Date: January 18, FIF Consolidated Audit Trail (CAT) Working Group Response to Proposed RFP Concepts Document

Transcription

1 Date: January 18, 2013 FIF Consolidated Audit Trail (CAT) Working Group Response to Proposed RFP Concepts Document

2 1 Executive Summary Implementation and Analysis Timeline CAT-Reporter-ID: LEI Approach CAT Customer-ID: Firm-designated Customer Identifier Approach Order-ID and Daisy Chain Approach Average Price Processing and Allocation Model Representative Orders Riskless Principal Error Correction Timeframe Options Use Cases CAT User Perspective Use Cases CAT Reporter Perspective Additional Topics for Consideration Symbology FIX Protocol Allocation of securities in primary market transactions Amendments/Exception Processing

3 1 Executive Summary Introduction The Financial Information Forum (FIF) 1 welcomes the opportunity to provide industry feedback to the SROs on the Proposed RFP Concepts Document, dated December 5, 2012 ( Concepts Document ). The scope of FIF s review and comments focuses on the RFP process/timeline to define a NMS Plan and the operational/technical aspects of the Concepts Document and associated SEC Rule 613. Two documents 2 were published by the SROs on January 16, 2013, including an update to the December 5, 2012 Concepts Document 3. These documents have not yet been reviewed by FIF. FIF has commented to the Securities and Exchange Commission (SEC) in 2010 and on topics which are expanded in this document, including the need for a requirements and cost/benefit analysis process that includes broad industry participation. FIF has provided comments to the SROs over the past several months on the Customer-ID Model, the Allocation Processing Model, as well as a review of OATS to identify CAT Reporting functional requirements 5. After further discussions with the FIF membership, this document expands on feedback previously shared with the SROs. The document relates the RFP Concepts to current business processes highlighting any concerns or issues identified by FIF with the RFP Concepts. The reference point for many of the comments relating to equity securities reporting is OATS Reporting as it is the current regulatory reporting system for the equities market. Given the diversity of order, execution and allocation processes in place today across the broker-dealer communities, the consolidated audit trail must be flexible in data and linkage requirements to accurately capture these divergent business processes. General feedback is provided on the overall schedule and how best to ensure broad-based industry participation throughout the RFP process, NMS plan creation and specification definition. FIF believes that a cooperative and collaborative approach between SROs and the industry throughout the process will result in more efficient, less costly and more comprehensive implementation of a consolidated audit trail. The costs to the industry for implementation of SEC Rule 613 cannot be over-emphasized; that cost must constantly be measured against the benefits to be afforded. Involvement of the industry throughout this process will ensure a balanced approach. Implementation and Analysis Timeline 1 FIF ( was formed in 1996 to provide a centralized source of information on the implementation issues that impact the financial technology industry across the order lifecycle. Our participants include trading and back office service bureaus, broker dealers, market data vendors and exchanges. Through topic oriented working groups, FIF participants focus on critical issues and productive solutions to technology developments, regulatory initiatives, and other industry changes. 2 Proposed RFP Concepts Document, updated January 16, 2013 Consolidated Audit Trail (CAT) National Market System (NMS) Plan, Information for CAT Bidders, January 16, One change in the Proposed RFP Concepts Document, updated January 16, 2013 improved the milestone for CAT communications of errors CAT Reporters by 20 hours. This update is noted in Section 8, Error Correction Timeframe but does not change any FIF Recommendation. 4 FIF Comment Letter II on Proposed Rule 613 to SEC, March 2, 2012; FIF Comment Letter I on Proposed Rule 613 to SEC, August 12, FIF Consolidated Audit Trail Working Group: Order Audit Trail Functionality November 29,

4 Critical details that must be part of the RFP are not discussed in the Concepts Document. It is our understanding that the SROs intend to publish additional information on requirements. Adequate time to capture feedback from the industry on these elements should be provided prior to final issuance of the RFP. Given the aggressive timeline outlined in the Concepts Document, FIF believes that it is critical for the industry to work collaboratively with the SROs to ensure that the CAT Processor definition meets SEC Rule 613 requirements in a cost effective manner. To aid the SROs and the eventual CAT Processor, FIF offers to be a resource to review, comment, answer questions, provide data, etc. on proposals being considered. A more collaborative model is required to achieve better results that address the extraordinary impact and costs to the broker-dealer and investor community. FIF recommends consideration of implementation concepts, including phased implementation and feasibility studies in order to reduce the overall risk in implementing the NMS Plan required by SEC Rule 613 and improve the overall quality and effectiveness of the final solution. CAT Reporter-ID The adoption of the Legal Entity Identifier (LEI) as the international standard for identification of global corporate entities creates an opportunity to transition to the use of this standard in the CAT definition for Reporter-ID. A phased approach could be used that allows optional use of the LEI initially, with transition to LEI as the standard for CAT Reporter-ID coincident with the widespread adoption of LEI throughout the industry. During the initial phase, publication of mapping tables of a firm s LEI, CRD and other exchange participant identifiers would be useful to allow for a common cross-identifier reference for the entire industry. CAT Customer-ID FIF must emphasize that the cost of adding a customer identifier to order reporting will introduce significant cost and change to the broker-dealer community. While FIF and its members understand that this information is required by Rule 613, there will be considerable system modifications and business process changes required to implement this aspect of the Rule. FIF prefers the SRO Alternate Approach 6 to allow use of a firm s designated identifier for the CAT customer identifier, and not require that a CAT unique Customer-ID be returned to the firm during the customer definition process for use in CAT reporting. While the SRO Alternate Approach outlined in the Concepts Document refers to account number, FIF recommends a more general approach, allowing a firm to specify a firm-designated identifier, unique within each firm, that would be translated by the CAT Processor to a CAT Customer-ID. Order-ID and the Daisy Chain Approach The single Order-ID approach is infeasible for a variety of reasons including information leakage as well as the fundamental impracticality of imposing this model on existing business processes. FIF believes that the introduction by the SROs of the Daisy Chain to link together related order events is a useful concept that should be used instead of a single order-id through the lifecycle of an order. In addition, the daisy chain approach could be extended for use not just between firms but also within a firm (for internal routes). Linking Order-IDs may not be sufficient for all complex scenarios including allocations as discussed in more detail later in this document. 6 Proposed RFP Concepts Document, dated December 5,

5 Average Price Processing and the Allocation Model Because of different processing models used across firms for average price processing and allocations, FIF proposes that the CAT allocation report (for activity that takes place in the middle and back office applications) allow flexibility in specifying identifying information that would allow the CAT to link back to the Customer-ID associated with the order. At a minimum, the firm s designated identifier (assuming the SRO Alternative Approach to Customer-ID is adopted) would be supplied on the CAT Allocation report. Because firm designated identifiers will also be supplied on Order Reports, these identifiers could be linked back to the same CAT Customer-ID (through the CAT customer definition process). Thus, the CAT Processor would have linkages among all of a customer s orders, executions and allocations for a single day, although there may not always be sufficient linkage information to relate a specific order, execution and allocation for a customer within that day. FIF would like to understand if this would be sufficient for auditing purposes to fulfill the SEC Rule 613 intent. If that is the case, additional linkage concepts should not be required. If additional linkages are required and the cost/benefit analysis justifies these added linkages, then FIF believes that linking based on Order-ID is not feasible in some trading scenarios because the relationships between orders and executions and then executions and allocations represent a myriad of one to many, many to one and many to many relationships. In addition, many firm processing systems are split among front, middle and back office applications, which often are comprised of multiple independent vendor-provided systems. Due to this split of functionality, data regarding orders, executions and allocations are compartmentalized as the process flows across these systems. Consequently, complete data regarding orders, executions and allocations are not available across all three logical systems (front office, middle office and back office systems). The concepts introduced with the RFP need to address these relationships. Orders can be related to executions, and executions can be related to allocations, but only through introduction of another concept Ticketing. Through this link, orders can be related to allocations. If specific linkages are required between orders, executions and allocations and the cost/benefit analysis is justified, then FIF recommends the introduction of a Ticket ID to facilitate this enhanced linkage. Representative Orders FIF believes that it is important for the SROs to understand that not every representative order can be linked to a customer order because it is the execution of the representative order that determines how that execution will, or will not, be used to fill any particular client order. If representative order linkage is required, FIF believes that the SROs should explore linking between representative order executions and the resultant client fill. Therefore, the linkage, and resultant reporting, would occur when representative order executions are used to fill particular client orders. Establishing this type of execution linkage would require a new reporting paradigm, and new CAT reporting concepts that may not be justified given a more extensive cost benefit analysis. When representative orders are handled in a riskless principal capacity, it is recommended that these orders and executions be handled as described for representative orders. Error Correction Timeframe FIF supports the goal of identification of reporting errors and the swift correction of those errors to produce an accurate audit trail of business transactions. However, to shrink the error repair window 5

6 from the current OATS five (5) business days to a 40 hour period 7 constitutes a significant burden to CAT Reporters and it is not evident at this point that this target can be reasonably met. For complex business transactions, it has been difficult for firms to research and repair OATS reporting errors within the current OATS window. The added scope and complexity of CAT reporting is likely to result in more intensive error correction efforts. FIF recommends consideration by the SROs of a more continuous matching and publication of errors process that allows CAT Reporters to submit error corrections to CAT as problems are resolved. The optimal window for correcting errors is difficult to predict at this point, without knowing more information on the CAT processor and the errors that will be required for the CAT Reporter to repair. It is suggested that the CAT Processor, once operational, gather statistics on the error rate and average time periods for correction. Adjustments can be made to both the CAT Processor and CAT Reporter processing to optimize these rates. As a starting point, the current five day OATS window should be maintained. Options In the absence of an OATS-like infrastructure for the options market ( i.e., OATS currently dictates order and execution regulatory reporting for the equities market) and without a proposal from the SROs on how options reporting will be handled, it is difficult for FIF to make concrete recommendations at this time for dealing with CAT options reporting. The current COATS infrastructure certainly favors the exchanges as being in a better position to report market maker orders and quotes. The sheer volume of option quotes should dictate that the exchanges be the reporter to CAT rather than every individual broker-dealer. When defining the options reporting solution, it is important to note key differences between options and equities that need to be considered including: volume of traffic, use of CMTA transactions, options expiration and extent of manual processing. Use Cases - CAT User Perspective FIF recommends that SEC Rule 613 use cases 8 should be included in the RFP with the RFP responders requested to demonstrate how their proposed solutions adequately address these scenarios and the questions included in SEC Rule 613 detailing these scenarios. The RFP responders should demonstrate a direct link between the reporting being requested of exchanges and broker/dealers through the Consolidated Audit Trail and the uses required of the audit trail. Also, the SROs and the RFP Responders need to provide the cost/benefit analysis that justifies the mandated data reporting elements and its use in either market surveillance or market reconstruction the regulatory purposes of the CAT. Use Cases - CAT Reporter Perspective FIF recommends that a more complete set of order, execution and allocation scenarios/use cases be included in the RFP as a requirements statement to the RFP bidders as to the scenarios their proposals must address. The OATS Order Reporting and Capacity Scenarios 9 should, at a minimum, be included in the RFP. The RFP bidders in their responses should demonstrate how CAT Reporting can be accomplished through their solutions with each of the scenarios provided in the RFP. In addition, the RFP bidders should be requested to add to the scenario set to provide a more complete set of use cases to further demonstrate how their solutions best address SEC Rule 613 both in completeness of the 7 This reflects the change in Error Correction timeline reflected in Proposed RFP Concepts, updated January 16, Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section III.C.2.b OATS Reporting Technical Specification, dated December 11, 2012, Sections 4.4 and 4.5 6

7 audit requirements and the flexibility of adapting to the various systems implementations throughout the industry with minimal disruption and cost. Areas for Additional Consideration While by no means exhaustive, the following areas should be explored as part of the CAT functionality requirements process: Symbology - FIF recommends consideration of a standard symbology for referencing equity securities that would include both the equity symbol and the identification of the symbol (CUSIP, ISIN, etc.). Adoption of a standard symbology would reduce reporting errors due to mismatch of symbol identifiers. The cost/benefit of adopting a standard equity securities naming convention needs to be analyzed, considering the impact on the industry. Use of the FIX Protocol: FIF recommends consideration of the Financial Information exchange ( FIX ) messaging specification when defining extensions to existing reporting interfaces, or if new interface designs are being explored. FIX provides an established semantics dictionary through the trading life cycle which is extended into the regulatory reporting requirements, thereby ensuring data completeness and minimizing misinterpretation. Leveraging FIX could result in quicker implementation times and simplify data aggregation at the SRO and CAT level. Allocations in Primary Market Transactions: Rule 613(a)(1) requires the SROs to examine the feasibility of providing information on allocations in primary market transactions as part of the Rule. The discussion of allocations in this document does not address allocations in primary market transactions. Amendments/Exception Processing FIF recommends analysis of the exception process. Amendments to allocations beyond the T+1 window, especially amendments that affect linkages to order and execution reports seriously complicate the reporting and correction process. 2 Implementation and Analysis Timeline Introduction This section addresses the overall RFP and implementation schedules and the suggestion to include steps in the plan to reduce overall risk. It is important to note that only basic concepts have been defined to date for the implementation of SEC Rule 613. Consequently, FIF comments represent initial feedback on the basic concepts in the Concepts Document. While we welcome the opportunity to comment on these concepts, we must emphasize that the feedback is preliminary. Extensive research is required at each firm to determine how SEC Rule 613 can be implemented within the firm s infrastructure and the potential cost of that implementation. To provide complete and conclusive feedback, FIF and its members request a requirements document and functional specifications in order to properly evaluate SEC Rule 613 implementation. FIF would prefer a Plan timeline that includes publication of a requirements document and functional specification allowing for industry comment/feedback before proceeding to NMS Plan submission. At a minimum, FIF would like to ensure that the Plan calendar includes the ability to modify the Plan (including implementation timelines) after the industry reviews functional specifications. SEC Rule 613 The national market system plan shall discuss the following considerations:...the process by which the plan sponsors solicited views of their members and other appropriate parties 7

8 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 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. 10 RFP Timeline FIF is concerned that without interim discussion of design proposals, the RFP will be published with little time allowed in the calendar for review and comment from the industry. Critical details that we expect to be part of the RFP are not included in the Concepts Document. Adequate time to capture feedback from the industry on these elements should be provided prior to final issuance of the RFP. FIF believes that it is critical for the industry to work with the SROs as they consult with potential CAT Processors to develop the detailed NMS Plan. 11 To aid the SROs in this effort, FIF offers to facilitate a more formal interaction framework between its members and the SRO team. This would allow for a continuous feedback mechanism for the industry to provide comment, answers to questions, data, etc. on proposals being considered. This more collaborative model would provide a mechanism for the needed industry feedback within the current RFP and NMS Plan timeline, while also improving final specifications to better meet the requirements of all parties the SEC, the SROs, the CAT Processor, and the broker-dealer community. FIF feels strongly that waiting for issuance of the NMS Plan proposal to obtain feedback from stakeholders outside of the SRO committee would significantly weaken the industry s ability to provide feedback on an initiative with tremendous operational, technical and financial implications. On a more practical note, planning for development work to comply with CAT requirements will be necessary by all CAT Reporters. Given the current SEC Rule 613 requirement of Broker-dealer reporting to commence within two years after the effectiveness of the NMS Plan 12, the bulk of the costs will likely be spent through 2015 budgets. However, early evaluations, planning and vendor support may be required in 2014 budgets. It would be very difficult for firms to estimate the SEC Rule 613 skills and expenditures required in 2014 budgets without more visibility into implementation details by September/October 2013 (assuming the SROs are granted their requested schedule extension). Implementation Timeline Significant infrastructure will need to be built by the CAT processor to implement SEC Rule 613; additionally, significant modifications will be required in the CAT Reporter s infrastructure to capture and report on the events required by SEC Rule 613 and the resulting NMS Plan. Consideration should be given to implementation practices that can reduce the industry s risks associated with this large initiative and to minimize re-work due to incomplete, incorrect or misunderstood interfaces. While it may cause some elongation of schedules, these implementation techniques generally result in overall 10 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section a.1.ix.a.xi xii, p Given the extended period of time between the RFP responses and ultimate issuance of the NMS Plan, FIF expects that the SROs will consult with the RFP respondent(s) as they refine the proposed NMS Plan. 12 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, p. 87, Footnote 236 8

9 lower implementation costs and better quality results due to less rework during implementation. Some implementation practices to consider include: 1. Feasibility studies to demonstrate that the data being requested of the CAT Reporters can be efficiently captured by the CAT Processor and can satisfy the stated use cases of the CAT Users. Also, the operational characteristics of the central repository regarding availability, scalability, reliability, security and performance should be demonstrated and tested early in the development lifecycle. 2. Industry forum and working group participation in review/feedback as proposals are being considered and specifications are being developed, providing necessary and early input to the process. Because cost/benefit analysis is required of the SROs in their NMS plan submission, 13 industry input would provide better informed estimates and better guide design decisions during the development phase. 3. A phased implementation of the Plan that benefits both the CAT Processor and the CAT Reporters. Phases could be defined by security type (e.g., NMS equities, options, fixed income, etc.), by customer type (e.g., institutional customers, retail customers), by functionality. Given the magnitude of this effort, it is critical that we consider approaches that minimize systemic risk. 4. Potentially, a Pilot program could be defined that solicits a small number of CAT Reporter firms to implement a subset of CAT reporting to demonstrate that the CAT infrastructure works within the defined operating characteristics (performance, response time, security, accuracy, etc.) and allows adequate data extraction/surveillance reporting. (Some compensation to the firms for the Pilot may be necessary). 3 CAT-Reporter-ID: LEI Approach Introduction This section discusses the CAT Reporter-ID, suggesting a phased approach to use the LEI (Legal Entity ID) for the CAT Reporter-ID. Proposed RFP Concepts The SROs are considering leveraging CRD to assign the CAT-Reporter-ID for each CAT Reporter. SEC Rule 613 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. 14 Current Business Process The US Commodities Futures Trading Commission (CFTC) has mandated the use of LEI in regulatory reporting CFR Rule 45 Swap Data Recordkeeping and Reporting Requirements, beginning in mid-2012 for dealers executing OTC derivatives transactions with their global counterparties. ISO has published standard for LEIs to provide unambiguous identification of 13 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail a.1.vii. (p.331) 14 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section j.2, Definitions, p

10 counterparties engaged in financial transactions, including elements for reference data attributes. The global launch is targeted for March Concerns/Issues with Proposed RFP Concepts- While FIF agrees that the FINRA s CRD (Central Registration Depository) represents a unique identifier and is in use today, the adoption of the Legal Entity Identifier (LEI) as the international standard for identification of global corporate entities creates an opportunity to transition to the use of this standard in the CAT definition. FIF Recommendation - FIF recommends a modification of the CAT-Reporter-ID from a CRD approach to LEI (Legal Entity Identifier). The approach would be a phased approach beginning with the ID registration similar to the CRD approach but including the LEI approach. Initial Phase: ID Registration includes registration of CAT-Reporter s LEI. Updates to ID Registration only required when there are changes to IDs. Publication of mapping tables of a firm s LEI, CRD and other exchange participant identifiers to allow for a common cross-identifier reference for use by the entire industry. Optional use of LEI instead of exchange participant identifiers. See Diagram 1 below which illustrates how this initial phase might work. Diagram 1. Initial Phase CAT- Reporter-ID with optional LEI Firm A Firm B MPID: ABCD Ord O1 MPID: EFGH ID Registration 1 Order Info Order Info 2 2 ID Registration 1 LEI ZNHTL602WODTKMPF1Z48 CRD 1234 MPID ABCD MPID 506A MPID. New Order Route Ord O1 Reporting LEI: ZNHT...48 Dest MPID: EFGH Order Rec d Ord O1 Reporting MPID: EFGH Rec d from MPID: ABCD CRD 5678 MPID EFGH MPID H927 MPID. 3 CAT ABCD [LEI ZNHTL602WODTKMPF1Z48] routed Ord O1 to EFGH [CRD 5678] Example- Phase 1: Firm A routes an order to Firm B 1. Firm A and Firm B provide all eligible market participant identifiers to the CAT. Delta changes reported to CAT as required. 2. Firm A would submit the new order using its CAT-Reporter-ID, identifying itself on the order with its LEI. It would identify the entity to which the order was routed (Firm B) using the 10

11 registered identifier of Firm B (e.g., MPID or other identifier). Firm B similarly would submit its order received report to the CAT using its CAT-Reporter-ID, identifying itself on the order with its MPID, and could identify the entity that it received the order from (Firm A) using any of the Firm A s registered identifier (LEI or MPID). 3. The CAT would link Firm A and Firm B s orders using the identifiers registered with the CAT along with CAT-Order-ID and other information to construct the order lifecycle. Subsequent Phase (when LEI is widely adopted throughout the industry): Replace unique exchange participant identifiers with the LEI standard ID registration only requires LEI Diagram 2. Subsequent Phase CAT Reporter-ID with LEI Firm A Firm B LEI: ZNHTL602WODTKMPF1Z48 Ord O1 LEI: VTOUP9FCHUXIINML4787 ID Registration ID Registration 1 Order Info Order Info LEI ZNHTL602WODTKMPF1Z48 New Order Route Ord O1 Reporting LEI: ZNHT...48 Dest LEI: VTOU...87 Order Rec d Ord O1 Reporting LEI: VTOU...87 Rec d from LEI: ZNHT...48 LEI VTOUP9FCHUXIINML CAT LEI ZNHTL602WODTKMPF1Z48 routed Ord O1 to LEI VTOUP9FCHUXIINML4787 Example Follow-on Phase: Firm A routes an order to Firm B 1. Firm A and Firm B provide their LEI to the CAT. Delta changes reported to CAT as required. 2. Firm A would submit the new order using its CAT-Reporter-ID and identifying itself on the order with its LEI. It would identify the entity to which the order was routed (Firm B) using the registered identifier (LEI) of Firm B. Firm B similarly would submit its order received report to the CAT using its CAT-Reporter-ID, identifying itself on the order with its LEI, and could identify the entity that it received the order from (Firm A) using Firm A s registered identifier (LEI). 3. The CAT would link Firm A and Firm B s orders using the identifiers registered with the CAT (LEI) with CAT-Order-ID and other information to construct the order lifecycle. The LEI is being established as the international, cross-instrument standard identifier. With support of the G20 and the Financial Stability Board, the LEI is a recognized standard that CAT should leverage. By the time of CAT implementation, it is likely that those entities reporting data to the CAT will already have an LEI. 11

12 Allowing a phase-in period where use of the LEI is optional for both firms and exchanges should ease the transition to the new ID. Eventually, all exchanges and firms should rely solely on the LEI for both exchange participant identification and CAT Reporter ID. 4 CAT Customer-ID: Firm-designated Customer Identifier Approach Introduction This section discusses CAT Customer-ID, supporting the SRO alternative approach of not requiring use of CAT Customer-ID in CAT reporting, but rather having CAT Reporters supply firmdesignated customer identifiers (unique within each firm) which can be translated by the CAT Processor to a CAT Customer-ID. Proposed RFP Concepts The SROs are considering an alternative approach to capture customer information and assign Customer-IDs that would not require broker-dealers to obtain and store a unique Customer-ID ( Customer-ID Approach ) from the CAT known as the Account Number Approach. SEC Rule 613 The term customer shall 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). 15 Note - a broker-dealer when routing orders to another firm is excluded from the definition of customer based on SEC 15c3-3: The term customer shall mean any person from whom or on whose behalf a broker or dealer has received or acquired or holds funds or securities for the account of that person. The term shall not include a broker or dealer, a municipal securities dealer, or a government securities broker or government securities dealer. The term shall, however, include another broker or dealer to the extent that broker or dealer maintains an omnibus account for the account of customers with the broker or dealer in compliance with Regulation T (12 CFR through ). 16 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. 17 Customer-ID is currently required for the Original Receipt/Origination of an order. However, the SROs have indicated a willingness to request a Plan amendment to allow for an Account Number Approach. The term customer account information shall include, but not be limited to, account number, account type, customer type, data account opened, and large trader identifier (if applicable) Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section, j.3, Definitions, p , c Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section, j.5, Definitions, p Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section, j.4, Definitions, p

13 SEC 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. Current Business Processes - Broker-dealers have a number of different identifiers used to classify firms/clients including the following: Entity id LEI Customer short name Top account number, Master account number, Counterparty account number, Retail customer account number Investment Advisor master account number Processing accounts numbers (e.g., average price processing account number) Any of these identifiers can be used within a firm to uniquely identify a customer of the firm. A general flow for defining a new customer to a Broker-dealer is to first secure the necessary information from the customer which uniquely identifies the customer to the Broker-dealer and satisfies the legal/regulatory requirements for customer identification. The information provided by the customer is stored in a Customer Information Repository by the firm. The customer is assigned a unique identifier within the firm. In addition, the customer s account structure and relationships (top account, sub-accounts, counterparty account, etc.) may be defined to the firm at this time. Once the customer definition is complete in the Customer Information Repository, then the appropriate account structure for the client/firm must be defined in each system through which the customer s orders will be processed. Large institutional clients and Investment Advisors handling many clients will often have very complex account and sub-account relationship structures that are continually being updated to reflect their ever changing business needs. The new customer definition process and any subsequent sub-account modifications is a time critical process because a new customer often wants to initiate business transactions immediately. It is most important for customer relationships to not unduly delay the customer definition process to interfere with the initial and subsequent business transactions. Customers do terminate business relationships with broker-dealers. Some firms permit the re-use of the firm s account identifiers for a customer after a specified period of time (which varies across firms). Therefore, a firm s unique identifier for a customer may be time dependent, e.g., it can represent Customer A from October 30, 2003 through June 15, 2009 and then represent Customer B from January 3, 2011 through to December 20, If a firm does re-use account numbers, and the account number is used as the firm s designated customer identifier for the CAT, then it is recommended that a Customer Definition event be defined so that a firm can notify the CAT when a firm s designated customer identifier will no longer be associated with a particular customer any longer. Concerns/Issues with the Proposed RFP Concepts FIF needs to emphasize that the cost of adding a customer identifier to order reporting will introduce significant cost and change to the broker-dealer 13

14 community. While FIF and its members understand the need for this information in order to build a consolidated audit trail, there will be considerable system modifications and business process changes required to implement this Rule. Steps must be added to the customer definition process to include notifying the CAT of new customers. This is a time-critical step because often new customers want to trade immediately and delays need to be minimized. All systems that handle order flow will need to be modified to carry/maintain the correct firm-designated customer identifier that must be included in the CAT Order Report. And lastly, the customer definitions, especially for large clients, are quite dynamic and the CAT Customer-ID modification process must be inserted into the firm s customer definition change process. Any CAT facilities or definitions that can further reduce the impact of adding a firmdesignated customer identifier to the Order Report should be explored. FIF has serious concerns regarding the implementation impact to the broker-dealers if a CAT unique Customer-ID needs to be maintained and provided in subsequent CAT reporting events, as previously shared with the SROs. 19 However, the alternative approach identified in the Concepts Document has the potential to reduce implementation impact to the Broker-dealers. The CAT customer definition process must be flexible enough to accommodate differing types of firmdesignated customer identifiers, of varying syntaxes. For example, one firm may currently identify a customer using an account number consisting of eight (8) alphanumeric digits, while another firm identifies a customer using an entity identifier consisting of fifteen (15) alphanumeric digits, including special characters. In addition, because of the ability to re-use firm-designated customer identifiers following account closings, the firm-designated customer identifier submitted to the CAT must be capable of referencing different customers depending on the period in which the customer account was opened within the firm. Each firm guarantees that a firm-designated customer identifier will be unique within the firm to identify a single customer (i.e., an LEI) within any single business day. Each firm needs the ability to define to the CAT multiple unique identifiers for one customer, i.e., multiple identifiers all relate to the same LEI. This will allow the firms to use a master account identifier for Order Reporting, but provide sub-accounts for Allocation Reporting. This would mimic the data available within the firms various systems at the points of order entry and allocations today, and reduce the impact to implement SEC Rule 613. FIF Recommendations FIF supports the alternative approach to capturing Customer IDs that would not require broker-dealers to obtain and store a unique Customer-ID from the CAT as outlined in the Concepts Document. FIF believes the SRO Account Number Approach should be renamed the Firmdesignated Customer Identifier Approach in order to acknowledge that it would be up to a broker-dealer to determine whether an Account Number or an Entity ID or some other id may be the most appropriate identifier to share with the CAT Processor. 20 The Firm-designated Customer Identifier approach would require the broker-dealer to submit sufficient information to the CAT Processor to allow for the assignment of a CAT Customer-ID that would only be available to CAT end users (i.e., the SROs and SEC). 19 FIF has referred to the Customer-ID Approach as the Two Way Approach in previous discussions with the SROs to emphasize the concerns with broker-dealers having to store and maintain the CAT Customer-ID internally. The FIF One Way Approach is similar to the Account Number Approach presented by the SROs. 20 Please note that this Firm-designated Customer Identifier Approach is identical to the One Way approach formerly shared with the SROs. 14

15 In the Firm-designated Customer Identifier approach, broker-dealers agree to maintain uniqueness of firm-designated customer identifiers within their firm such that there would be no duplicate firmdesignated customer identifiers within each CAT Reporter ID. Uniqueness to a specific customer would be the firm-designated customer identifier for an effective date, allowing broker dealers to re-use firmdesignated customer identifiers. Because broker-dealers are excluded from the 15c3-3 definition of a customer, it is assumed that they do not need to be defined as a customer through the CAT Customer-ID definition process. However, for some firms, it may be advantageous to be defined through the CAT Customer-ID definition process and be able to use a firm-designated identifier, rather than MPID for CAT reporting. Broker-dealers (BDs) would supply the CAT Processor with key data points regarding their customers (name, address, account number, date of birth, tax ID/SSN, account opening date) as part of a separate customer definition process to populate a CAT Customer database. The Legal Entity Identifier (LEI) should be one of the identifiers that can be supplied by the broker-dealers to aid the CAT in uniquely identifying customers across firms. If the LEI is supplied as an identifier to the CAT when defining a Customer-ID to CAT, additional reference data elements to uniquely identify the customer should not be required, because the LEI definitions can be independently referenced by CAT. As part of the customer definition process, multiple firm-designated customer identifiers will be supplied by a broker-dealer to identify a single customer to the CAT, i.e., refer to the same LEI. The firm-designated customer identifier available at the time of CAT reporting will be supplied on the report. For example, the master account firm-designated customer identifier could be supplied on a CAT Order Report and the sub-account firm-designated customer identifier could be supplied on a CAT Allocation Report. Because some broker-dealers permit re-use of account numbers following customer account closing/purge process, the CAT Processor must have the ability to associate the same firmdesignated customer identifier with different customers. For match purposes, the identifier supplied on a CAT Order report should be qualified with the associated order date of the event. The identifier supplied on a CAT Allocation report should be qualified with the associated trade date of the associated allocation (because allocations can occur on subsequent days following an execution). Broker-dealers would need to update the data fields supplied during the customer definition process as they change providing adds/modifications/deletes as opposed to a complete refresh of a database. This would not be tied to any CAT report submission. Standards for data submission (e.g., postal address) would need to be established. Standards regarding the syntactic requirements of the firm-designated customer identifier would need to be sufficiently broad to accommodate the current and varied account numbering structures and firm-designated customer identifiers in use today across the firms. 15

16 Diagram 3. Firm-designated Customer-ID Definition Process Customer Data Population Process BD 1 New Customers Initial Account Setup BD 1 New Account Opening Process Add Sufficient Customer Information CAT Processor (Customer Process) BD 1 Existing Customers BD 2 New Customers BD 2 Existing Customers Modify/ Delete Account Info Initial Account Setup Modify/ Delete Account Info BD 1 Existing Customer Database BD 2 New Account Opening Process BD 2 Existing Customer Database Daily Updates of Modify/Delete Add Sufficient Customer Information Daily Updates of Modify/Delete Fuzzy matching across broker-dealer-provided customer information Ability to produce a list of similar customers Assign CAT Customer ID Reassign CAT Customer IDs as matching algorithms improve and additional data becomes available CAT User (SRO/SEC) Appending firm-designated identifier on Order Origination BD 1 Order Origination BD firm-designated Identifier with other Order Origination Data Fields CAT Processor (Event Process) BD firm-designated Identifier CAT Customer ID CAT Customer ID (s) on Order Origination Event Order Origination Event Enriched with CAT Customer ID(s) CAT User (SRO/SEC) CAT User (SRO/SEC) Broker-dealers must define to CAT every customer that represents a client/firm that will place an order and the beneficial owner that receives the final allocation. Broker-dealers can only identify the parties with which they trade. As has been discussed as part of OATS and EBS implementations, a broker-dealer s customer is the entity they have a direct relationship with and may not include the ultimate beneficial owner of a transaction. Even in the Firm-designated Customer Identifier approach, there would need to be a feedback loop to ensure data submitted to the CAT Customer Processor was received correctly. Intra-day messaging or file submission should be explored with feedback within an hour. The customer definition process is time-sensitive because often new customers want to immediately enter orders. The CAT Customer-ID definition process should not impede new business. A few CAT Customer-ID events could be defined (e.g., report a new customer event, report a customer modification event, etc.) with a definition of the data validation to be performed on each field. On new order report submission which currently calls for CAT Customer-ID, BDs would supply their own firm-designated customer identifier. This firm-designated customer identifier in conjunction with the effective date of the order transaction should be sufficient information for the CAT Processor to resolve to the CAT Customer-ID. No other identifying information would be required. The CAT Customer-ID would only be accessible to CAT end users. The CAT Processor would require sophisticated matching logic akin to credit bureau functionality to establish matches and identify similar customers that may be the same customer. This level of sophistication would be required even with the unique Customer ID approach. 16

17 A facility should be supported by CAT that would allow bulk loading of customer definition addition/deletions/modifications. This will facilitate the one-time changes required to support system conversions, mergers, acquisitions and similar business events. Also, the CAT should support the ability to provide a bulk download to a CAT Reporter of all the reference data definitions (e.g., CAT Customer-ID and CAT Reporter-ID information) maintained by the CAT that is associated with that CAT Reporter. 21 Some benefits that FIF can attribute to Firm-designated Customer Identifier approach for Customer-ID definition are: It eliminates the need for broker-dealers to build out systems and maintain the CAT Customer- ID. Reconciliation and correction of CAT Customer-IDs would be the responsibility of the CAT processor with no downstream impact to broker-dealer or retail customers as they are not using CAT Customer-ID in any of their systems. o As additional data and matching logic improves, assigned CAT Customer-IDs are likely to change. Having CAT Customer-ID localized within the CAT processor would allow for updates to CAT Customer-ID without requiring those changes to propagate changes across broker dealers. At initial customer set-up, firms would not have to wait for the CAT Customer-ID to come back before allowing their clients to trade. Limited distribution of CAT Customer-ID might reduce information security and privacy concerns. Customers know their personal data regarding their brokerage activity is shared with the Federal government (e.g., the IRS). However, the perception of the introduction of a new ID accessible to all broker dealers may raise additional privacy concerns. 5 Order-ID and Daisy Chain Approach Introduction This section supports the SRO proposal of using a daisy chain approach for linking orderids between firms and suggests expanding that concept to apply as well for internal routes. Proposed RFP Concepts The SROs are considering a Daisy Chain Approach such that a series of unique order identifiers assigned by CAT Reporters are linked together by the CAT to create the lifecycle of an order and assigned a single CAT-Order-ID for the lifecycle. Each CAT Reporter would generate its own unique Order ID but could pass a different identifier as the order is routed and the CAT would link related order events from all CAT Reporters involved in the life of the order Contrary to slide 14 in the Concepts Document, FIF would expect CAT Reporters to have some capabilities to download data they submit to CAT in order to better diagnose and correct errors. This would include reference data (like customer account Information) as well as order related event data. 22 Proposed RFP Concepts Document, December 5, 2012, p.26 17

18 SEC Rule 613 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 orders. 23 Current Business Processes The order process is both varied and complex to account for the myriad ways of handling an order throughout its life cycle. Following are a set of examples which demonstrate different flows between order and execution and the different data models between order and execution one to-one, one-to-many, many-to-one, many-to-many. For the Institutional Client Environment, when operating in the Agency Capacity: Orders (for a single client, single security) can be merged into a single pre-trade merged order by the front office and routed to the street for execution. Orders (including merged orders) can result in one or more executions. Single orders executed can be merged for a client to create a post-trade merged execution. Information regarding the order (single order, pre-trade merged order, or post-trade merged execution) is sent to the Middle Office via a Ticket which contains client account, total order quantity, executed quantity, average price). Based on the client s allocation instructions for the executed quantity, the firm allocates to the specified sub-accounts. Note that information about the order(s) is not known at this point in the system processing. Order information can be deduced through the ticket information. For the Institutional Client Environment, when operating in Principal Capacity: If the firm receives a client order and fills the order from the firm s inventory, then it implies that the firm acted in Principal Capacity. The client order is ticketed as described above. Note: There is no link between the between orders to fill a firm s inventory and the fills from that inventory to satisfy customer orders. We would expect that if the regulatory bodies require additional detail on the firm s inventory orders/executions, a firm would provide these details upon request, as it does today. If the firm is facilitating a client order which requires a Reg. NMS sweep, then the Reg. NMS sweep order is a representative order which is linked to the Client Account as described under Riskless Principal. Diagram 4 illustrates a business flow where multiple client orders (Orders 1,2,3) are aggregated into a single order (Order 4) and routed to the street for execution, with resulting executions (executions 5,6) used to fill aggregated Order 4. There is no linkage today between the exchange orders and firm orders due to aggregation. 23 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section j.1, p

19 Diagram 4: Aggregate Order Scenario Exchange Client 1 Day Order Order 1 E 1 NYSE Day Order Order 5 Client 2 Day Order Order 2 E 2 Client 3 Day Order Order 3 E 3 Aggregate Order Day Order Order 4 E 5 * E 6 * E 5 NSDQ Day Order Order 6 E 6 Concerns/Issues with Proposed RFP Concepts The Order-ID and Daisy Chain Approach may be an insufficient concept to handle the complexity of all of the order, execution and allocation processes used across many firms today. Representative order and riskless principal issues are discussed in Sections 7. As illustrated in Diagram 4, linkages can be provided with the client-side executions, but reporting linkages directly to the street-side executions may be problematic. The CAT Processor should have enough data regarding the entire order flow that the CAT Processor, and not the broker-dealer, could provide the linkage to the street-side executions. FIF Recommendations - FIF supports the SRO proposal of a Daisy Chain of Order-IDs as a mechanism to link related order events from all CAT Reporters involved in the life of the order. While the Concepts Document applies Daisy Chain to external routes, FIF suggests that there may be some scenarios that could benefit from also applying the Daisy Chain concept to internal routes (e.g., Aggregate Orders). More complex scenarios need to be a guideline in developing the CAT specification. Use cases are needed to validate the specification, to ensure that accurate reporting of the events is possible, and implementable within reasonable cost constraints. The reporting requirements and the linkages throughout the order flow need to be explored, especially for more complicated scenarios. Part of the analysis needs to determine if the CAT Reporter or the CAT Processor should provide linkages through all the events in the order flow lifecycle. Since there is no link between orders to fill a firm s inventory and the fills from that inventory to satisfy customer orders, FIF believes that reporting linkages would not be required by SEC Rule

20 6 Average Price Processing and Allocation Model Introduction This section describes average price processing and the allocation model and suggests flexibility in allocation reports to allow one of the following data elements sub-account (previously defined to the CAT as part of the Customer-ID definition process), order id, firm-designated customer identifier or, if needed, a new concept, Ticket ID, depending on the trading scenario. Proposed RFP Concepts Slide 29 CAT-Order-ID: Order Executed on an Average Price Basis in the Concepts Document implies that the proposed Daisy Chain approach could be used to handle average price scenarios, and indirectly, that the (chained) order-id could be supplied on the allocation report. SEC Rule 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: If the order is executed, in whole or part, the following information: The account number for any subaccounts to which the execution is allocated (in whole or part); The CAT-Reporter-ID of the clearing broker or prime broker, if applicable; and The CAT-Order-ID of any contra-side order(s). 24 Current Business Processes There is a basic average price processing order handling model one or more orders are submitted by the Institutional client or Investment Advisor, typically resulting in many executions to fill each order. Depending on client preferences, the fills can be reported back to the client for average price calculations or aggregated by the broker-dealer with an average price calculation. The executions are then allocated to the sub-accounts as specified by the client s allocation instructions. In general, the order and execution processes are handled via front office systems. The allocation process is the responsibility of middle/back office systems. These systems operate independently within the total trade flow with discreet linkages between these systems. In fact, multiple vendor-provided systems and services as well as firm-implemented systems are used to comprise the functionality associated with middle/back office systems. Information available in the front office systems regarding orders are not required to be known by the middle and back office systems. Likewise, allocation and clearing information is not required to be known by the front office systems. Typically, orders are not merged across Institutional Clients or an Institutional Client order with a Block order from an Investor Advisor for retail clients. Generally, Institutional Client Orders are worked over the day and do not hold the trader to time and price discretion (i.e., NH, Stops, benchmarks, etc.) vs. retail block orders which are held to time and price discretion. An example is shown in Diagram 5 to illustrate an order flow scenario with many to many relationships, using a Ticket Concept. 24 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section c.7.vi, p

21 Diagram 5. Institutional Client Business Flow for Order, Execution and Allocation Front Office Middle Office Institutional Investor 1 Order 1 for 15,000 shares IBM Institutional Investor 1 Order 2 for 10,000 shares IBM Institutional Investor 1 Order 3 for 7,000 shares IBM Front Office Member Firm Order $25.60 Order $25.35 Order $25.25 Order $25.20 Exchange 1 Exchange 2 Dark Pool 1 Various Market Centers Ticket 1 25,000 shares avg price Ticket 2 25,000 shares avg price Middle Office Member Firm 1 10 II Client 1 Sub-account 11 5,000 IBM@ $25.50 II Client 1 Sub-account 12 10,000 $25.50 II Client 1 Sub-account 13 3,000 $25.50 II Client 1 Sub-account 14 2,000 $25.50 Ii Client 1 Sub-account 15 5,000 $25.50 Ii Client 1 Sub-account 21 4,000 $25.23 Institutional Investor 1 Order 4 for 6,000 shares IBM Ii Client 1 Sub-account 22 4,000 $25.23 Ii Client 1 Sub-account 23 5,000 $ New Order event (OR1) created for Institutional Investor 1 for 15,000 shares of IBM. The ORs would have a unique ID, like they do today, and identify the client using a firm-designated customer identifier. 2. Various slices of Client Order (OR1) are created reflecting routes to various markets centers. While no one route is greater than 15,000 shares. Such routes will be reported to CAT and would match with New Order events reported by markets centers, like they do today. 3. The Firm will report routes when routing to external market centers, and executions when done over-the-counter. 4. Executions are received from market centers to Client Order (OR1). The fills could be split or could go entirely to one order (or could be multiple executions at different market centers at different prices). 5. Institutional Investor 1 submits another order for the same stock for 10,000 shares. New Order Event (OR2) is created. 6. The process is repeated as in Step #2. 7. The process is repeated as in Step #3. 8. The process is repeated as in Step #4. 9. OR1 and OR2 are completed and a transaction message is sent to the middle or back office with Ticket 1 containing the firm-designated customer identifier, total quantity, executed quantity and average price. This represents all of the fills of the two orders. 10. Each allocation to a subaccount would result in a Back Office Allocation CAT event (BOA1, BOA2, BOAn) that would reference Ticket 1, the sub-account, and include the quantity and price. Each execution that was accumulated for Ticket1 shall result in a Front Office Execution CAT event (EX1, EX2, ) that would reference Ticket1 as well as other execution attributes such as price, quantity and timestamp. 11. Institutional Investor 1 submits another order for the same stock for 7,000 shares. New Order Event (OR3) is created. Steps 2 thru 4 repeated for OR Institutional Investor 1 submits another order for the same stock for 6,000 shares. New Order Event (OR4) is created. Steps 6 thru 8 repeated for OR OR3 and OR4 are completed and a transaction message is sent to the middle or back office with Ticket 2 containing the firm-designated customer identifier, total quantity, executed quantity and average price. This represents all of the fills of the two orders. 14. Each allocation to a subaccount would result in a Back Office Allocation CAT event (BOA1, BOA2, BOAn) that would reference Ticket 2, identify the sub-account, and include the quantity and price. Each execution that was accumulated for Ticket1 shall result in a Front Office Execution CAT event (EX1, EX2, ) that would reference Ticket2 as well as other execution attributes such as price, quantity and timestamp. 21

22 It must be noted that the above Diagram 5 is one of many variations used across firms for managing the order, execution and allocation flow. A regulatory reporting solution must be flexible enough to accommodate the different business models used to implement the events through the order lifecycle. A second example is shown below in Diagram 6 to illustrate the allocation process with aggregated orders. The aggregated order example shown in Diagram 4 is expanded to add the allocation process. Client Orders 1,2,3 are aggregated into an Order 4 and routed to the street for execution. Executions 5 and 6 are returned to fill Order 4, which is average priced and used to fill Executions 1,2,3. Ticket 1 holds the linkages between the Allocations for Client 1 and the client-side execution 1. An Investment Advisor scenario has an allocation process as follows: o Investment Advisor places a block order in their master account o Block order results in many executions that are communicated back to the Investment Advisor o Investment Advisor allocates block order to retail client accounts o At some firms, there is no ticketing concept. No automated link exists between executions and allocations. At other firms, the ticketing process is similar to the Institutional client agency process shown on the following page. Concerns/Issues with Proposed RFP Concepts To handle average price processing and the allocation model, the Order-ID and Daisy Chain Approach are incomplete concepts to handle the complexity of these processes used across most firms today. Independent front office and middle/back office systems 22

23 (often including multiple independent vendor systems) process steps within the total trade flow with discreet linkages between those systems. Information available in the front office systems regarding orders are not required to be known by the middle and back office systems. Likewise, allocation and clearing information is not required to be known by the front office systems. Especially problematic is including Order-ID on all allocations. As illustrated in Diagram 5 above, there is not always a straight one to one relationship between an order, execution and allocation. The relationships are more complex. o Many orders can be pre-trade merged into a single order. o Multiple executions can be post-trade merged into a single average price execution o Single order or a pre-trade merged order can result in multiple executions with the street. o A Ticket has a one-to-one relationship with a single order, a pre-trade merged order or a posttrade-merged execution. o A Ticket has a one-to-many relationship with Allocations. These many-to-many relationships cannot easily be captured with the proposed CAT reporting concepts. FIF Recommendations In examining intra-firm linkage issues as they relate to average price processing, FIF would like to explore the possibility of decoupling allocations from order linkage. Initially, FIF proposed tying allocations to the Customer-ID in a manner that mirrors the actual allocation process. Since sub-account information will be supplied on CAT Allocation reports and firm-designated customer identifiers will be supplied on CAT Order reports, and because sub-accounts and firmdesignated customer identifiers can be linked back to the CAT Customer-ID, the CAT now has linkages among all of a customer s orders, executions and allocations for a single day, although there may not always be sufficient linkage information to relate a specific order, execution and allocation for a customer within that day. FIF encourage the SROs to explore if this would be sufficient for auditing purposes to fulfill the SEC Rule 613 intent. If that is the case, additional linkage concepts (like ticketing) may not be required. The cost/benefit analysis of additional linkages should be explored prior to requiring these linkages. FIF suggests that the SROs consider the following concepts as possible solutions to the issues identified. Additional analysis/investigation is required to completely define these concepts and understand the implications for implementation. There are likely different ticketing concepts implemented across the broker-dealer community. One possible scenario is discussed here. o A Ticket concept is proposed which defines the association between the executions with the allocations, and the client. The executions, of course, are already linked with the order. A Ticket ID could be specified on all the executions that got averaged for one ticket and all resulting allocation records thus linking them together. Ticketing can occur throughout the day or after close of day processing, after executions. The ticket id is not known at the time of the execution but is known at end-of-day when reporting occurs. The ticket id could be added to the execution reports at that time. This ticket linkage is widely used in Institutional scenarios but may not always be implemented today in Investment Advisor scenarios. o An alternate reporting method was suggested where a Ticket event is defined that specifies the Ticket-ID and Order-ID on the Ticket report. The Ticket-ID would also be specified on the Allocation Report, thereby providing the needed linkage between orders and allocations. This 23

24 o o o alternative method has an advantage in that allocations performed on the day following the execution would not require amendments of execution reports to include a Ticket-ID that have already been sent in to the CAT Process on the previous day. As mentioned earlier, the Ticket concept is not always used for retail scenarios and Investment Advisor scenarios. For these cases, it is proposed that the sub-accounts specified on the Allocation Report would be sufficient to link back to the Order ID for the client, instead of the execution. Asset Managers use an average price account in the Front Office for managing the multiple executions that result from a client order. An average price booking is sent to the middle/back office systems. The allocations are managed in the middle/back office systems through the average price account and client account number. The linkages, in this case, are via the average price account and the client account number; ticketing is not used. The CAT Allocation report would include Ticket ID (optionally), Order ID (optionally) and the firm s designated customer identifier (mandatory). One or more of these identifiers could be provided which would form the linkage back to original orders. Additional analysis will also be needed to determine how best to report scenarios when the order is executed by one firm but allocated by another firm, for example, with Step-Outs, Give-Ups and CMTAs. Following is a proposed update of the data fields required for the various CAT events, where Ticket ID would be added as an optional field for the Allocation event. FIF suggests that the reporting elements be flexible to allow for various scenarios. For example, in the retail scenario, ticketing is not always implemented because the relationships are more straightforward. 24

25 CAT Field Original Receipt/Order Origination Table 1. Current SEC Rule 613 Required Data Fields Routing of Order Receipt of Routed Order Order Modify/ Cancel Order Executed (Whole or Partial) Post-Execution Allocation Information Post- Execution Cancellation Customer-ID(s) X If giving instruction Information sufficient to X identify the customer Customer Account Information X Account Number X X CAT Order-ID X X X X X Of Contraside Order(s) CAT-Reporter-ID X Both the Router and Receiver Receiver and Router If giving instruction X Clearing Broker or Prime Broker Date X X X X X? Time X X X X X? Material Terms of Order X X X Modifications Execution? only price and size Desk/Dept ID If routed internally Execution Capacity X Reported to a Plan X Trade Cancellation Indicator X?? Table 2. Proposed Data Fields for Post-Execution Allocation (Using Internal ID Approach) CAT Field Customer-ID(s) (populated by CAT Processor) Information sufficient to identify the customer Customer Account Information Firm-Designated ID (instead of Account Number) Original Receipt/Order Origination Populated by CAT Customer Process Populated by CAT Customer Process Populated by CAT Customer Process Firm Designated ID Routing of Order Receipt of Routed Order Order Modify/ Cancel Order Executed (Whole or Partial) Post- Execution Allocation Information Populated by CAT Customer Process Firm- Designated ID CAT Order-ID X X X X X Order ID (make optional) CAT-Reporter-ID X Both the Router and Receiver Receiver and Router If giving instruction X Clearing Broker or Prime Broker Ticket ID (NEW) X (Optional) X (Optional) X (Optional)? Post- Execution Cancellation Date X X X X X? Time X X X X X? Material Terms of Order X X X Modifications only Desk/Dept ID Execution Capacity If routed internally Execution price and size X??? Reported to a Plan Trade Cancellation Indicator X X 25

26 As further clarification on some of the data fields required by SEC Rule 613: 1. Customer IDs FIF is recommending a Firm-designated Customer Identifier Approach with the CAT Customer-ID field being populated by the CAT Processor rather than a submission from the broker dealer. 2. Account Number - Account information available to the front office is often a parent or entity level account that is different from the sub-account allocation done as part of allocation processing. Additionally, in some institutional trading scenarios, the entity level information is tracked via an internal entity identifier that may not be associated with an account. As such, account information provided on the new order may be different from account information provided with allocations. When reporting firm-designated customer identifier information as part of the CAT Customer Definition Process, it is expected that identifying information for the entity placing the order would also appear on the sub-account allocation. This customer would be a link between the order and allocation 3. Ticket ID The Ticket represents the pool of street-side executions that are average-priced in the Front Office before being redistributed across sub-account allocations in the Middle Office. Tickets link customers, the orders and resulting executions, and are the linkage to the Middle Office for allocations, including the Ticket ID on both the Order Execution Event and the Post- Execution Allocation. The CAT Processor can establish the link between the many executions that resulted in many allocations. 4. CAT Order ID - As described above, there is not always a direct relationship between orders and allocations. It is unclear to the clearing or prime broker which orders resulted in which allocations. Adding the Ticket ID or sub-account to the CAT allocation report provides linkage back to the Order ID. The Ticket ID is also specified on the executions. The Order ID is specified on the executions. This linkage should be sufficient to achieve the SRO/SEC surveillance goals. Orders capture intent; executions and allocations capture what happened; the order executions (Ticket ID) represent the linkage between the two. As such, if additional linkages are required beyond firm-designated customer identifiers, FIF suggests that the SROs explore the optional use of Ticket ID and the firm s designated customer identifier as the links between allocations and orders as outlined in Table 2 above. As mentioned earlier in Section 5, Order-ID and Daisy Chain Approach, there needs to be further analysis regarding how (and who) would be best enabled to provide linkages among all steps in an order flow (e.g., between client and streetside executions). Additionally, there may be complications if allocations are received after T+1 or require amendments. 7 Representative Orders Introduction This section describes various representative order scenarios to demonstrate that there are not pre-trade linkages between client and representative orders, suggesting that the linkages are between client and representative executions, based on how the order is filled. Proposed RFP Concepts Representative orders are addressed in the Concepts Document specifically focusing on riskless principal. The Concepts Document offered that the Order-ID and daisy chain approaches could be applied to orders handled on a riskless principal basis. 25 Also, the following 25 Proposed RFP Concepts Document, dated December 5, 2012, p.27 26

27 question was raised by the SRO s - How can representative orders be linked to underlying customer orders, such as in riskless principal or average price scenarios? 26 SEC Rule SEC Rule 613 does not specifically address representative orders, although the Commission s adopting release includes reference to a FINRA comment letter 27, 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. 28 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. 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. 29 Current Business Processes For clarity, FIF has defined representative orders as firm-initiated orders that are ultimately used to fill orders received from clients. Three use cases are shown below (Examples 1 through 3) which demonstrate the complex order and trade flow associated with representative orders. Questions are posed in each of the three scenarios on how these typical representative order flows would be captured for CAT reporting Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Footnote 393, p Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, p Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, p

28 Example 1. The BD Posts a Bid at for 1,000 shares at two exchanges. One order for customer 3 is eligible to receive fills at the limit price and if the representative order is filled at then the fills will all go to Customer 3. The order for customer 3 should be linked to the representative order. But, if the posted order on Exchange A gets price improved and fills come back at a price of 10.00, the fills will be shared between customers 1, 2 and 3. Should the orders for customers 1, 2 and 3 be linked to the representative order or only the orders eligible to receive an allocation at the time of the post? What if no fills come back (from Exchange B)? Should the orders for customers 1, 2 and 3 be linked to the representative order, or only the order for customer 1? Diagram 7. Representative Order Use Case #1 Customer 1 Acct # ,000 share order Buy Exchange A Customer 2 Acct # ,000 share order Buy BD Creates 1,000 share Order and Posts on 1,000 share Post ATS Exchange A Customer 3 Acct ,000 Share order Buy ,000 share Post Exchange B 28

29 Example 2. The BD Posts a Bid at for 1,000 shares. At the time orders have been received from customers 1, 2 and 3. Before the posted order is filled customer 4's order is received. A fill comes back for 100 shares and is allocated to customer 4. The rest of the posted order is cancelled. What customer orders should be linked to the representative order the orders that were eligible to receive allocations when the representative order was routed or the order that received the allocation? What if the posted order had no fills what customer orders should be linked to the representative order? Diagram 8. Representative Order Use Case #2 Customer 1 Acct # ,000 share order Buy Exchange A Customer 2 Acct # ,000 share order Buy ,000 share Post 9.99 Customer 3 Acct ,000 Share order Buy BD Creates 1,000 share Order and Posts on Exchange A ATS Exchange B Customer 4 Acct share Held order Buy

30 Example 3. The BD Posts a Bid at for 1,000 shares. At the time orders have been received from customers 1, 2 and 3. Before the posted order is filled customer 3's order is cancelled (or filled). A fill comes back for 500 shares and is allocated to customers 1 and 2. The rest of the posted order is cancelled. What customer orders should be linked to the representative order the orders that were eligible to receive allocations when the representative order was routed or the order that received the allocation? What if the post is cancelled and not filled? Diagram 9. Representative Order Use Case #3 Customer 1 Acct # ,000 share order Buy Exchange A Customer 2 Acct # ,000 share order Buy Customer 3 Acct ,000 Share order Buy BD Creates 1,000 share Order and Posts on Exchange A to Buy ,000 share Post ATS Exchange B As can be seen from these three examples, there is not a pre-trade link between representative orders and client orders. Decisions on how best to fill client orders are made after executions are completed on representative orders. Linking occurs post-execution not with the client or representative order origination. There can be many representative order executions that fill one client order or multiple client orders. But there is one street-side print to one of more customer executions. Each street-side print will be split to fill one or more client orders based on the parameters of the execution and the criteria of the order. A representative order can also result in no fills at all (see Example 3 above). In this case, there is no linkage to either customer orders or customer executions. As discussed in Section 6, Average Price Processing and the Allocation Model, representative executions can also be aggregated. Today, each fill must be reported as an order execution event. A flip of a representative order execution to a customer order execution represents an internal execution and is a reportable event. Current business processes do associate the executions of the representative orders with the client orders that match the criteria for fills. Generally, surveillance reports within the firms systems are provided that detail the street-side prints with client-facing fills, for control and monitoring purposes. 30

31 Concerns/Issues with Proposed RFP Concepts Representative orders do not always have a pre-trade direct linkage to client orders. However, when representative orders are executed and those executions can satisfy a client order, the fills are applied to the client order. Potentially, executions of representative orders could be linked to client order fills. Execution links do not exist today, and to supply such links to CAT would represent new reporting for the firms. There is not a CAT concept today of an Execution Link. No linkage can be provided in the case of the representative order which does not result in a fill. As described above, the CAT reporting rules associated with representative orders would be different than the rules associated with customer orders. As such, representative orders may need to be distinguished from customer orders. Two possible methods for identifying a representative order are listed: 1. An order type can be added to an order report, with type = representative order, or 2. The Customer-ID on the representative order is blank, or specifies the internal firm-designated customer identifier of the broker-dealer. FIF Recommendation It is the consensus opinion of FIF and its members that linkage at the Order-ID level should not be required for linking between representative and client orders. The CAT Audit Trail should mirror the current business processes; the audit trail should not create a link where one doesn t exist today. There can be no accurate linkage of client orders and representative orders because the execution of the representative order determines how that execution will, or will not, be used to fill any particular client order. Therefore, the linkage would occur when representative order executions are used to fill particular client orders. There are a number of possible concepts that could be defined to handle the representative order scenarios. One proposal discussed would be to create an execution or fill report where the shares that constitute the fill are reported. If a representative order did not result in any fill then no link would be established. Additional discussion is required to fully flush out the operational issues that might arise to accommodate execution linkage. However, for the RFP, the SROs should request functionality that can accommodate additional linkages if required. To illustrate the concept of execution linkages, Diagram 10 below illustrates one scenario that could be an approach to linking representative and client orders at the execution level. In this example, a trading desk has two large algorithmic orders working throughout the day to buy a large amount of shares. At the same time, client orders can be received and made eligible to receive fills that were bound to principal orders. A customer order to buy is received note that while principal orders continue receiving fills, only the fills that are priced at 25 or better get automatically re-allocated to the customer order. A second customer order to buy is received, and while both customer orders are open, eligible fills are being split between the two. Every instance of a representative order fill being assigned to another order must be captured and assigned its own ID that shall be used for linkage. Linkage is illustrated at the bottom of the diagram: note that all customer order fills will have a link in this example, but the fills that are priced above 25 will be left as working principal orders. This also illustrates the point that in many cases representative orders are not fully representative they are being taken advantage of when needed, but they can and 31

32 in many cases do act as orders with their own purpose (in this case to accumulate a large block position for the desk). Diagram 10. Representative Order Business Flow Using Execution Linkages Another option for linking representative orders to client orders could be the use of the firm-designated customer identifier (e.g., firm account number).this may not work in all cases but may serve to increase transparency into how representative orders were generated. 7.1 Riskless Principal Current Business Processes A common use of representative orders is for riskless principal trading. FINRA defines "riskless principal" as a trade in which a member, after having received an order to buy (sell) a security, buys (sells) the security at the same price, as principal, in order to satisfy the order to buy (sell). In order to qualify for riskless principal trade reporting, the rule requires that the trades be 32

33 executed at the "same price" (exclusive of a markup or markdown, commission equivalent, or other fee). Additionally, under the rules a portion of a transaction may be deemed riskless. That is, to the extent that any of the order is offset with another principal execution at the same price, that portion is deemed riskless and should be reported only once. 30 For the Institutional Client Environment, when operating in the Riskless Principal Capacity: A representative order is generated and routed to the street for execution. o The client order is held until the best possible price is secured for the client from the street. o The resulting executions are flipped to the client strike by strike. (Potentially, the executions may be split among different client orders.) o Given the above process of creating a representative order, there are systemic link at the execution level between the representative order and the client order. The representative orders would be firm orders and therefore reportable to CAT. o In the simple case where a client order triggers the firm order (using a parent/child relationship), it may be possible to create a direct relationship between client and representative order at the order level. This simple scenario is not typical for more complex institutional flows. o The variations of handling representative orders (as discussed in Section 7, Representative Orders) also apply when executing in a riskless principal capacity. Concerns/Issues with Proposed RFP Concepts Concerns relating to representative orders documented above apply to riskless principal scenarios as well. FIF Recommendations There is a wide range of trading scenarios used across the broker-dealer community. In the more straightforward use cases, there exist more direct relationships, and therefore linkages, between client orders and any subsequent firm orders generated to satisfy the client orders. In these cases, the current CAT reporting requirements can be satisfied. However, for more complex trading scenarios, the relationship between client orders and any subsequent firm orders are more indirect and would require new reporting concepts, in the form of execution linkages, to establish the audit trail as required by SEC Rule 613. FIF recommends that the CAT reporting requirements model this diversity allowing flexibility in how events are reported to accommodate current business processes. When representative orders are handled in a riskless principal capacity, it is recommended that these orders and executions be handled as described in Section 7, Representative Orders. There would be no pre-trade linkage known between customer orders and representative orders but there is a postexecution linkage established between the representative order execution and the resulting fill of the customer order from that execution. A report could possibly be created to provide an audit trail of that link. 30 FINRA 99-65, Approves Rules Changes to NASD Trade Reporting Rules for Riskless Principal Transactions in NASDAQ and OTC Securities 33

34 8 Error Correction Timeframe Introduction This section suggests alternative error correction timeframes to better match the current OATS error correction timeframe and to reflect the reality of the time required to fix complex trade problems. Proposed RFP Concepts The timeline milestones for Data Validation and Error Handling in the Concepts Document indicated a one day (24 hour period) time period for re-submission of error corrections by the CAT Reporters to the CAT. 8:00 AM ET T+1 Initial Data Submission by CAT Reporters to CAT 8:00 AM ET T+2 Communication of errors by CAT to CAT Reporters 8:00 AM ET T+3 Resubmission of Errors Due by CAT Reporters to CAT 8:00 AM ET T+4 Reprocessing of Error Corrections by CAT to CAT Reporters 8:00 AM ET T+5 Data Ready for Regulators In the Proposed RFP Concepts document, updated January 16, 2013, the timeline milestones were changed as shown, indicating now a 40 hour period for re-submission of error corrections by the CAT Reporters to the CAT. 8:00 AM ET T+1 Initial Data Submission by CAT Reporters to CAT 12:00 PM ET T+1 Initial Validation, Life Cycle Linkage, Communication of errors by CAT to CAT Reporters 8:00 AM ET T+3 Resubmission of Errors Due by CAT Reporters to CAT 8:00 AM ET T+4 Reprocessing of Error Corrections by CAT to CAT Reporters 8:00 AM ET T+5 Data Ready for Regulators SEC Rule 613 The national market system plan submitted pursuant to this section shall: 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: 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; 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; Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section e.6, p

35 Current Business Processes The current OATS cut-off for business transaction reporting within a day is currently 4:00PM ET, representing the definition of day one (T). The current OATS Error Handling procedures dictate the following error correction rules: All ROE (Reportable Order Event) rejections that require repair must be researched and repaired by the firm within five OATS Business Days from the date when the Context Rejections are available. 32 All accepted New Order and Cancel/Replace Reports that have a Time in Force Code of GTC, GTD or GTM must be corrected within two years, or as soon as possible, after they are accepted by OATS; all other accepted order reports must be corrected with 5 business days after OATS accepts the original New Order or Cancel/Replace Report. 33 Concerns/Issues with Proposed RFP Concepts To shrink the error repair window from five (5) business days to less than two (2) business days 34 constitutes a significant burden to the CAT Reporters and it is not evident at this point that this target can be reasonably met. For complex business transactions, it has been difficult for firms to research and repair OATS reporting errors within the current 5 business day window. CAT reporting further expands the reporting scope suggesting that even 5 business days may be too small a window for CAT error correction. The CAT definition of end of day for cut-off of business transaction reporting within a day has not yet been published. Assuming that the current OATS deadline of 4:00PM ET is maintained, then allocation information is not available to the firms until after this deadline, and by definition, into the T+1 business day. Allocation reporting to CAT would then occur by T+2 business day. Based on the timeline provided, the assumption is that the CAT matching process would be performed during T+1 and T+ 4, but it would be useful to include the proposed CAT timeline for match processing to better understand the CAT Data Validation process. This means that the T communication of errors by CAT to the CAT Reporters would not include Allocation Reports associated with orders and executions reported to the CAT in T+1. The CAT data validation and matching process has yet to be defined so the errors to be identified by CAT can only be speculated based on the current OATS error definitions. FIF Recommendations FIF supports the goal of identification of reporting errors and the swift correction of those errors to produce an accurate audit trail of business transactions. However, at a minimum, the current OATS Error Handling timelines should be adopted, with initial flexibility on error correction guidelines, as noted below. The OATS timeline allows all ROE (Reportable Order Event) rejections that require repair to be repaired by the firm within five OATS Business Days from the date of the original submission OATS Reporting Technical Specification, dated December 11, 2012, Section Rejection Repairs, p OATS Reporting Technical Specification, dated December 11, 2012, Section 6.9 Firm-Generated Corrections and Deletions, p This reflects the change in Error Correction timeline reflected in Proposed RFP Concepts, updated January 16, This reflects the change in Error Correction timeline reflected in Proposed RFP Concepts, updated January 16, OATS Reporting Technical Specification, dated December 11, 2012, Section

36 To better align with the staggered reporting of data to CAT due to Allocation Reports, and the error investigation required for complex transactions, FIF recommends consideration by the SROs of a more continuous matching and publication of errors process that allow: 1. CAT incorporation of Allocation Reports into its data validation and match criteria process as the reports are received one day following the related order and execution reports. E.g., errors associated with allocation reports should be repaired within five days from the date of the allocation report, not the original order report. 2. CAT Reporters can submit error corrections to CAT as problems are resolved, within a broader time period than 5 days. 3. The CAT Processor provide a facility to allow the CAT reporters to re-submit corrected reports pro-actively, even if they were not informed of an error. 4. A more pro-active publishing strategy should be pursued for communications with CAT Reporters especially regarding the error notification and correction process. This could include a Web-based service that allows viewing of the CAT data and error notification as well as submission of repairs. I.e., what data is visible to the CAT processor and what caused the break or issue. 37 Having this type of service will reduce the dependency to first test repairs through the CAT DEV/QA environment to verify that the trade correction also corrects the reporting issue before submission to CAT Production. File transmissions of error notifications as well as error corrections should also be supported. 5. Linkage breaks (e.g. a reject is received for part #5 of a 10 part client order) should not be grounds to cause subsequent events (parts 6 through 10) to be rejected. The broken linkage could be repaired without having to resubmit all subsequent activity only that which was affected. 6. There is no experience on the timeframe needed for repairing errors reported on options, and on the underlying securities for these options. It is expected that a larger repair window than 5 days may be needed. 7. Guidelines could be established for the correction of a high percentage of errors within the first few days of errors being reported by the CAT, but allow correction of the more complex transactions to be reported back to CAT as the problems are resolved. This also facilitates incorporation of error corrections by other firms that resolve errors identified by another CAT Reporter. The optimal window for correcting errors is difficult to predict at this point, without knowing more information on the CAT processor and the errors that CAT Reporters will be required to repair. It is suggested that the CAT Processor, once operational, gather statistics on the error rate and average time periods for correction. Adjustments can be made to both the CAT Processor and CAT Reporter processing to optimize these rates. The CAT Processor can then set guidelines to the CAT Reporters on target error correction time periods that is acceptable to the regulators and attainable for the CAT Reporters. At a minimum the current five day OATS window should be maintained until additional data can be gathered. 37 Contrary to slide 14 in the Concepts Document, FIF would expect CAT Reporters to have some capabilities to download data they submit to CAT in order to better diagnose and correct errors. This would include reference data (like customer account Information) as well as order related event data. 36

37 9 Options Introduction This section defines RFP considerations that are unique to options and any unique considerations when reporting on options activity. Proposed RFP Concepts There are no unique concepts defined to date for SEC Rule 613 reporting of options. SEC Rule 613 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. 38 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 (a)(46). NMS stock is defined in Rule 600(47) to mean any NMS security other than an option. 17 CFR (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 (a)(35). 39 Current Business Processes Currently, options reporting for regulatory and surveillance purposes is performed via COATS, Consolidated Options Audit Trail System. COATS bears no resemblance to OATS. COATS implementation is performed by the options exchanges with no reporting requirements for broker-dealers. Data is collected by the exchanges on quotes, orders, executions, complex orders. For manual activity, the transaction must be systematized (i.e., entered into the system), contemporaneously upon receipt and prior to representation. 40 Only executions are reported on a daily basis; other data is made available by the exchanges to the SEC at their request. COATS does not include order origination time and is unlikely to be a model for CAT for options. General trading scenarios for options include: 1. Trades that the firm both executes themselves (generally electronically) and clears. 2. Trades that the firm executes and clears, but the execution is done with an external broker (floor or upstairs broker). 3. Trading volume that the firm does not execute but CMTAs in from another broker. 4. Trading volume that the firm executes and CMTAs to another broker a. Where CMTA instructions are provided on the order b. Where CMTA instructions are provided post-trade 38 Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Section c.6, p Securities and Exchange Commission, Rel. No Final Rule, Consolidated Audit Trail, Footnote 7, p January 7, 2005 SEC Release No ; File No. SR-CBOE , p.3 37

38 SROs have indicated that they anticipate that related option and equity transactions (e.g., complex orders) would need to be linked in CAT. The treatment of complex orders at some firms is such that they treat a complex order as a single order that goes to the exchange. For these firms, creating a new order for the equity leg would be akin to creating a phantom order. It is also important to note that complex orders are described differently across the options exchanges which may also pose issues for CAT reporting. Volumes associated with options quotes and orders are significantly greater than with equities processing, and the trend continues to grow in this space. FIF Capacity Working Group has reported that there continues to be growth in traffic in the options marketplace. The November 2012 OPRA 1 second peak message rate is 5 million messages/second (Diagram 12) with a peak daily message ceiling of 26.8 billion messages beginning in January 2013 (Diagram 13). Diagram 12. OPRA Peak 1 second rates Diagram 13. OPRA Daily Messages In addition, the difference between the quote to trade ratio in the equities and options markets is significant. In November 2012, the CTA ratio was and UTP was (Diagram 14). For OPRA the quote to trade ratio in November 2012 was 5,660 (Diagram 15). Any reporting requirement and the resulting solution for options must include volume in the analysis so that the solution does not represent an undue burden on the industry while still delivering the required audit trails to satisfy the regulators. 38

39 Diagram 14. Equity SIP Quote to Trade Ratio Diagram 15. OPRA Quote to Trade Ratio Diagram 14. OPRA Quote to Trade Ratio There are three other areas where the options market differs from the equity market, and may influence the reporting strategy to be proposed: 1. The extent of manual processing (e.g., phone to floor, etc.), 2. Options expiration events (e.g., how to handle trades allocated on expired contracts), 3. Volume of allocation amendments (See Section 13.4, Amendments). Concerns with Proposed RFP Concepts - No concerns can be raised because no information has been provided to date on CAT reporting for options. FIF Recommendations In the absence of an OATS-like infrastructure that currently dictates order and execution reporting for the equities market and without a proposal from the SROs on how options reporting will be handled, it is difficult for FIF to make concrete recommendations at this time for dealing with CAT options reporting. The current COATS infrastructure certainly favors the exchanges as being in a better position to report market maker orders and quotes. The sheer volume of option quotes should dictate that the exchanges should be the reporter to CAT rather than every individual brokerdealer. Any options reporting solution must take into account the current and projected quote, order and execution traffic in the options marketplace to ensure that it will not place an undue burden on cost or performance for the CAT reporters. Also, as mentioned earlier, it is imperative that any options reporting solution exhibits flexibility in its reporting requirements to accommodate the diversity of options trading scenarios that are employed across the industry. FIF assumes that post-trade events (e.g., trades as a result of exercise or assignment) are out of the scope for CAT reporting. 39