FIF Consolidated Audit Trail (CAT) Working Group Response to Proposed RFP Concepts Document

Date: January 18, 2013

2

1 Executive Summary ............................................................................................................................... 3

2 Implementation and Analysis Timeline ................................................................................................. 7

3 CAT-Reporter-ID: LEI Approach ............................................................................................................. 9

4 CAT Customer-ID: Firm-designated Customer Identifier Approach ................................................... 12

5 Order-ID and Daisy Chain Approach .................................................................................................. 17

6 Average Price Processing and Allocation Model ................................................................................. 20

7 Representative Orders ........................................................................................................................ 26

7.1 Riskless Principal ......................................................................................................................... 32

8 Error Correction Timeframe ................................................................................................................ 34

9 Options ................................................................................................................................................ 37

10 Use Cases – CAT User Perspective .................................................................................................. 40

11 Use Cases – CAT Reporter Perspective ........................................................................................... 41

12 Additional Topics for Consideration ............................................................................................... 43

12.1 Symbology ................................................................................................................................... 43

12.2 FIX Protocol ................................................................................................................................. 44

12.3 Allocation of securities in primary market transactions ............................................................. 44

12.4 Amendments/Exception Processing ........................................................................................... 44

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 documents2 were published by the SROs on January 16, 2013, including an update to the December 5, 2012 Concepts Document3. These documents have not yet been reviewed by FIF. FIF has commented to the Securities and Exchange Commission (SEC) in 2010 and 20124 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 requirements5. 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 (www.fif.com) 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, 2013 3 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, 2010. 5 FIF Consolidated Audit Trail Working Group: Order Audit Trail Functionality November 29, 2012

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 Approach6 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, 2012.

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

6

from the current OATS five (5) business days to a 40 hour period7 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 cases8 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 Scenarios9 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,

2013. 8 Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.2-5

9 OATS Reporting Technical Specification, dated December 11, 2012, Sections 4.4 and 4.5

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

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 Plan12, 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. 34-67457 Final Rule, Consolidated Audit Trail, Section a.1.ix.A.xi – xii, p. 332 11

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. 34-67457 Final Rule, Consolidated Audit Trail, p. 87, Footnote 236

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 17442 for LEIs to provide unambiguous identification of

13

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail a.1.vii. (p.331) 14

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section j.2, Definitions, p. 348

10

counterparties engaged in financial transactions, including elements for reference data attributes. The global launch is targeted for March 2013. 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

MPID: ABCD MPID: EFGH

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 ….

ABCD [LEI ZNHTL602WODTKMPF1Z48]

routed Ord O1 to EFGH [CRD 5678]

Firm A Firm B

CAT

ID Registration

Order Info

Ord O1

ID Registration

Order Info1

2 2

1

3

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

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

LEI: ZNHTL602WODTKMPF1Z48 LEI: VTOUP9FCHUXIINML4787

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 VTOUP9FCHUXIINML4787

LEI ZNHTL602WODTKMPF1Z48

routed Ord O1 to

LEI VTOUP9FCHUXIINML4787

Firm A Firm B

CAT

ID Registration

Order Info

Ord O1

ID Registration

Order Info1

2 2

1

3

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.

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 firm-designated 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 220.1 through 220.19).”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).18

15

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section, j.3, Definitions, p. 348 16

http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=4d14767b8885d7efd945c593910df914&rgn=div8&view=text&node=17:3.0.1.1.1.2.95.331&idno=17, 240.15c3-3 17

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section, j.5, Definitions, p. 348 18

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section, j.4, Definitions, p. 348

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, 2012. 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

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 firm-designated 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 firm-designated 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 Firm-designated 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.

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 firm-designated 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 firm-designated 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 firm-

designated 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.

16

Diagram 3. Firm-designated Customer-ID Definition Process

BD 1 New Customers

BD 1 Existing Customers

BD 1 New Account Opening Process

BD 1 Existing Customer Database

• 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

BD 2 New Account Opening Process

BD 2 Existing Customer Database

Add Sufficient Customer Information

Initial Account Setup

Modify/Delete Account Info

BD 2 New Customers

BD 2 Existing Customers

Initial Account Setup

Modify/Delete Account Info

Add Sufficient Customer Information

Daily Updates ofModify/Delete

Daily Updates ofModify/Delete

Appending firm-designated identifier on Order Origination

CAT Processor(Customer Process)

CAT User (SRO/SEC)

CAT User (SRO/SEC)

CAT User (SRO/SEC)

Order Origination Event Enriched with CAT Customer ID(s)

Customer Data Population Process

BD 1 Order Origination

BD firm-designated Identifier with other Order Origination Data Fields

• BD firm-designated Identifier CAT Customer ID

• CAT Customer ID (s) on Order Origination Event

CAT Processor(Event Process)

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.

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 order-ids 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.”22

21

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

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. 34-67457 Final Rule, Consolidated Audit Trail, Section j.1, p. 348

19

Diagram 4: Aggregate Order Scenario

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 613.

Exchange

Day Order Order 5

NYSE

E 5

Day Order Client 1

Order 1

E 1

Day Order Order 6

NSDQ

E 6

Day Order Client 2

Order 2

E 2

Day Order Client 3

Order 3

E 3

Day Order

Aggregate Order

Order 4

E 5 * E 6 *

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 613 - “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. 34-67457 Final Rule, Consolidated Audit Trail, Section c.7.vi, p. 340

21

Front Office

Member Firm 1

Exchange 1

Exchange 2

Institutional

Investor 1

Order 1 for

15,000 shares IBM

II Client 1

Sub-account 11

5,000 IBM@ $25.50

Dark Pool 1

Middle Office

Member Firm 1

Ticket 1

25,000 shares IBM

@ avg price 25.50

II Client 1

Sub-account 12

10,000 IBM @ $25.50

II Client 1

Sub-account 13

3,000 IBM @ $25.50

II Client 1

Sub-account 14

2,000 IBM @ $25.50

Ii Client 1

Sub-account 15

5,000 IBM @ $25.50

Various Market

Centers

Institutional

Investor 1

Order 2 for

10,000 shares IBM

1

4

5

8

6

7

2

3

9

10

Front Office Middle Office

Diagram 5. Institutional Client Business Flow for Order, Execution and Allocation

Order 1 @ $25.60

Order 2 @ $25.35

Institutional

Investor 1

Order 3 for

7,000 shares IBM

Institutional

Investor 1

Order 4 for

6,000 shares IBM

11

Ticket 2

25,000 shares IBM

@ avg price 25.23Order 3 @ $25.25

Order 4 @ $25.20 Ii Client 1

Sub-account 21

4,000 IBM @ $25.23

Ii Client 1

Sub-account 22

4,000 IBM @ $25.23

Ii Client 1

Sub-account 23

5,000 IBM @ $25.23

4

8

13

12

14

1. 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 OR3.

12. 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 OR4.

13. 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.

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

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 post-

trade-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 firm-designated 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

24

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.

o 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.

o 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.

o 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.

25

Table 1. Current SEC Rule 613 Required Data Fields

Table 2. Proposed Data Fields for Post-Execution Allocation (Using Internal ID Approach)

CAT Field Original Receipt/Order

Origination

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) (populated by CAT Processor)

Populated by CAT Customer

Process

Populated by CAT Customer

Process

Information sufficient to identify the customer

Populated by CAT Customer

Process

Customer Account Information

Populated by CAT Customer

Process

Firm-Designated ID (instead of Account Number)

Firm Designated ID

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) ?

Date X X X X X ?

Time X X X X X ?

Material Terms of Order X X X Modifications only

Execution price and

size

?

Desk/Dept ID If routed internally

Execution Capacity X

Reported to a Plan X

Trade Cancellation Indicator

X

CAT Field Original Receipt/Order

Origination

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 identify the customer

X

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 only

Execution price and size

?

Desk/Dept ID If routed

internally

Execution Capacity X

Reported to a Plan X

Trade Cancellation

Indicator

X

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 street-side 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

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 613 - SEC Rule 613 does not specifically address representative orders, although the Commission’s adopting release includes reference to a FINRA comment letter27, ” …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.

26

http://catnmsplan.com/QuestionsforIndustryConsideration/ 27

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Footnote 393, p.145 28

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, p. 145 29

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, p. 147

28

Example 1. The BD Posts a Bid at 10.01 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 10.01 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 #

1234 10,000 share

order Buy 10.00

Customer 2 Acct #

5678 20,000 share

order Buy 10.00

Customer 3 Acct 7725

5,000 Share order Buy

10.01

BD Creates 1,000 share

Order and Posts on

Exchange A

Exchange A

Exchange B

ATS

1,000 share Post

10.01

1,000 share Post

10.01

29

Example 2. The BD Posts a Bid at 10.00 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 #

1234 10,000 share

order Buy 10.00

Customer 2 Acct #

5678 20,000 share

order Buy 10.01

Customer 3 Acct 7725

5,000 Share order Buy

10.00

Customer 4 Acct 8828

100 share Held order

Buy 10.01

BD Creates 1,000 share

Order and Posts on

Exchange A

Exchange A

Exchange B

ATS

1,000 share

Post 9.99

30

Customer 1 Acct #

1234 10,000 share

order Buy 10.00

Customer 2 Acct #

5678 20,000 share

order Buy 10.00

Customer 3 Acct 7725

5,000 Share order Buy

10.00

BD Creates 1,000 share

Order and Posts on

Exchange A to Buy

10.00

Exchange A

Exchange B

ATS

1,000 share

Post

Example 3. The BD Posts a Bid at 10.00 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

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.

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 700 shares @ 25.00 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 200 shares @ 25.00 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

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

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 post-execution 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”

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;…”31

31

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section e.6, p. 345

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 days34 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+ 135 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.36

32

OATS Reporting Technical Specification, dated December 11, 2012, Section 6.2.2 Rejection Repairs, p. 181 33

OATS Reporting Technical Specification, dated December 11, 2012, Section 6.9 Firm-Generated Corrections and Deletions, p. 187 34

This reflects the change in Error Correction timeline reflected in Proposed RFP Concepts, updated January 16, 2013 35

This reflects the change in Error Correction timeline reflected in Proposed RFP Concepts, updated January 16, 2013 36

OATS Reporting Technical Specification, dated December 11, 2012, Section 8.4

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.

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 242.600(a)(46). NMS stock is defined in Rule 600(47) to mean “any NMS security other than an option.” 17 CFR 242.600(a)(46). A listed option is defined in Rule 600(a)(35) of Regulation NMS to mean “any option traded on a registered national securities exchange or automated facility of a national securities association.” 17 CFR 242.600(a)(35).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. 34-67457 Final Rule, Consolidated Audit Trail, Section c.6, p. 338 39

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Footnote 7, p. 7 40

January 7, 2005 SEC Release No. 34-50996; File No. SR-CBOE-2004-77, p.3

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 27.06 and UTP was 15.47 (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.

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 broker-dealer. 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.

40

10 Use Cases – CAT User Perspective Introduction – This section lists the use cases included in SEC Rule 613 and suggests these use cases be included in the SRO RFP. Proposed RFP Concepts – CAT User use case scenarios were not addressed in the Concepts Document. SEC Rule 613 Concepts – Included in SEC Rule 613 are six use cases detailing how the SEC envisioned usage of the CAT audit trail by regulators as guidance to the SROs in preparing the NMS plan.

Off-Line Analysis.41 Regulators are likely to frequently require the extraction of relatively small amounts of select data from the consolidated audit trail database at the central repository for their own “off-line” analyses.853 (Footnote 853: For purposes of these use-cases, an “off-line” analysis is defined to be any analysis performed by a regulator based on data that is extracted from the consolidated audit trail database, but that uses the regulator’s own analytical tools, software, and hardware) For example, a regulator may need to extract data on all orders in a particular stock, by a particular customer, on a particular day, or based on any other combination of fixed search criteria.854 (Footnote 854: Fixed search criteria are those that are based on specific pre-defined data elements that are stored in the consolidated audit trail database. In contrast, dynamic search criteria are those that are based on numerical levels, thresholds, or other combinations of mathematical formula or logic that would require some amount of additional calculations to be performed on, and derived from, pre-defined data elements already stored in the database to complete the search operation and return to the user the data that meets the requested criteria. ) Though the total data extracted may be small, the number of records that need to be searched to find such data may be enormous. Dynamic Search and Extraction.42 At times, regulators may need to identify and extract small amounts of data from the database based on dynamic search criteria that might require the database to perform calculations on stored data to meet the specified criteria. A few examples of dynamic criteria are: searching for trades with trade sizes above a certain threshold, searching for trades in securities with execution prices that change more than a certain percentage in a given period of time, and searching for orders that are canceled within a certain period of time. Analysis in Bulk Form 43- In addition to targeted analysis of select data from the consolidated audit trail database, regulators will also require the analysis of data in bulk form. For example, the Commission is likely to use consolidated audit trail data to calculate detailed statistics on order flow, order sizes, market depth and rates of cancellation, to monitor trends and inform SRO and Commission rulemaking. To satisfy the surveillance requirements of SEC Rule 613(f), regulators may want the ability to feed consolidated audit trail data into analytical “alert” programs designed to screen for potential illegal activities such as insider trading or spoofing. Surveillances might also benefit if regulators are able to link consolidated audit trail data with databases on certain types of material news events or market participants. This would allow regulators to isolate and aggregate data on trading in advance of those news events or by those participants. If preliminary analyses showed problems, the regulators could then request significant amounts of data for a more thorough and detailed follow-up analysis. In the event of a large scale market event like the May 6, 2010 “flash crash,” regulators are likely to use

41

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.1 42

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.1 43

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.2

41

consolidated audit trail data to reconstruct market events on the day of the event, including but not limited to reconstructing entire order books and trading sequences. Order Tracking and Time Sequencing 44- One of the key requirements of the consolidated audit trail is to provide regulators with a complete record of all of the events that stem from a particular order, from routing to modification, cancellation, or execution. In addition, these events must be stored by the central repository in a linked manner – using either a unique order identifier or a series of unique order identifiers, as discussed in Section III.B.1.d.iv. – so that regulators can quickly and accurately extract a time-sequenced history of each event related to an order. Database Security, Contingency Planning, and Prospects for Growth 45 - The data stored in the consolidated audit trail database will contain confidential detailed records of trade and order flow by customer. How is the data secured, not lost, accessible and can grow with the industry? Database Access of Historical Data 46- As part of an investigation or examination, regulators may need to analyze historical trades and orders in the database maintained by the central repository (though not trade and order events occurring prior to the implementation of the consolidated audit trail). Concerns/Issues with Proposed RFP Concepts – No concerns/issues are raised at this time because no Proposed RFP Concepts have been published to date on CAT User Use Cases. FIF Recommendations – FIF recommends that these use cases should be included in the RFP and the RFP responders asked to demonstrate how their proposed solution adequately addresses these scenarios as well as the questions raised in SEC Rule 613 detailing these scenarios. It provides a set of “end scenarios” that can be used to validate each of the RFP responder’s solutions. Also, there should be 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. FIF suggests that if data does not map to a CAT User use case its presence in the Plan should be justified.

11 Use Cases – CAT Reporter Perspective Introduction – This section lists a set of CAT Reporter scenarios and suggests these use cases be included in the SRO RFP. Proposed RFP Concepts – Four scenarios are provided in the Concepts Document for Order Handled on a Riskless Principal Basis, Order Routed between Exchanges, Order Executed on an Average Price Basis, and Aggregation/Disaggregation. Current Business Processes – The OATS Order Reporting and Capacity Scenarios47 include a set of business use cases that are referenced in the industry for guidance on current order audit trail regulatory reporting.

44

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.3 45

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.4 46

Securities and Exchange Commission, Rel. No. 34-67457 Final Rule, Consolidated Audit Trail, Section III.C.2.b.5 47

OATS Reporting Technical Specification, dated December 11, 2012, Sections 4.4 and 4.5

42

This document outlines many scenarios of current processes. Additionally, the following are retail scenarios that provide insight into various order, execution and allocation processes in use. 1. Financial Advisor Order - Single Allocation process:

a. FA places an order in a single Client account. b. The order results in one or many executions that are communicated back to the FA. c. If more than one execution on the order then:

i. An Average Price trade is created in the Client Account. ii. The Street Side trades are created in an ‘Average Price’ account for each execution with executed quantity and quantity and execution price.

d. If only one execution on the order then: i. The Street Side trade is directly created in Client Account with executed quantity and

execution price.

2. Financial Advisor Order - Multiple Allocation process: a. FA places an order with multiple Client accounts and their respective allocation quantity. b. The order results in one or many executions that are communicated back to the FA. c. If more than one execution on the order then:

i. An Average Price trade is created for each account on the order with allocated quantity. ii. The Street Side trades are created in an ‘Average Price’ account for each execution with

executed quantity and executed Price. d. If only one execution on the order then:

i. The execution price trade is created for each account on the order with allocated quantity. ii. The Street Side trades are created in an ‘Average Price’ account for each execution with

executed quantity and execution price. Note: At rare occasions a Financial Advisor may request a Block Order thru Trading desk. In that case the following External Money Manager Order and Allocation Process takes in effect.

3. External Money Manager - Order and Allocation Process:

a. MM sends a Block order. b. A Block Id is created for this order. c. A Trader’s facilitation account is assigned to this order. d. The Block order may result in one or more than one order to the execution venue. e. Each order carries its unique Order Id and has a link with Block Id. f. All orders results in one or many executions that are communicated back to the MM. The

notification to MM is on Block Order. g. MM sends the allocations with respective allocated quantity for the executed quantity of the

Block order. i. An Average Price trade is created for each account on the Block order with allocated quantity. ii. The Street Side trades are created in an ‘Average Price’ account for each execution with

executed quantity and executed Price. Note: The external money manager may request to combine more than one Block order thru operations before sending the allocation. In that case, a new Top Block Id is generated and a new Average price is calculated. The allocations are then done against the Top Block Order-Id. At this point, the initial Block-Id does not travel with the allocated trades through to the Back Office application.

43

Concerns/Issues with Proposed RFP Concepts – The four scenarios in the Concepts Document do not suggest how CAT Reporting would be incorporated. To adequately represent the marketplace and as a test of a proposed CAT Reporting specification, many additional order scenarios are required, especially more complex scenarios. FIF Recommendation – 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 what their proposals must address. At a minimum, the OATS Order Reporting and Capacity Scenarios48 should be included in the RFP. Additionally, the scenarios that have been described in this document should be considered for inclusion. 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 audit requirements and the flexibility of adapting to the various systems implementations throughout the industry with minimum disruption and cost.

12 Additional Topics for Consideration While not the focus of FIF discussions, the following issues were raised by FIF members that require further discussion.

12.1 Symbology The symbology for uniquely identifying NMS equity securities has been an issue facing CAT Reporters. The identifier provided for exchange listed securities is defined to be the format published by the primary listing market. Following is an example showing three securities that are listed on NYSE; they can also be traded on NASDAQ. The various symbols that are used to represent the same security on the different exchanges and regulatory reports are illustrated in Table 3. Table 3. Equity Security Symbols

Security Name NASDAQ Symbol CMS Symbol ACT Symbol CQS Symbol

Bank of America Corporation Class A Warrant expiring January 16, 2019

BAC+A BAC WSA BAC.A BAC/WS/A

John Wiley & Sons, Inc. Common Stock JW.A JW A JW.A JW/A

Wachovia Preferred Funding Cp Preferred Stock WNA- WNA PR WNA$ WNAp

Some of the rules that govern when to use which symbols are: 1. When trading on NYSE, the symbol used is the CMS symbol.

2. When trading on NASDAQ, the symbol used is the NASDAQ symbol.

3. When an OTC transaction is reported to NASDAQ/FINRA TRF (Trade Reporting Facility) in those

securities, the ACT symbol is used.

4. When subscribing to market data through a consolidated plan, the symbol used can be the CQS

symbol.

48

OATS Reporting Technical Specification, dated December 11, 2012, Sections 4.4 and 4.5

44

Note that all of the symbols are different, and even though there are some similarities in how various suffixes translate into their counterparts in other notations, the relationship among the symbols remains convoluted. It is not uncommon for an order in the same security to be sent through smart-router software, sliced and sent to numerous markets at the same time – every destination potentially using different symbology. The broker-dealer has to keep track of all symbology so that when executions come back, the executions can be accounted for in a seamless fashion. FIF Recommendations – FIF recommends that the SROs consider an improved NMS equity securities naming convention that includes both the symbol and the identification of the symbol (CUSIP, ISIN, etc.). The FIX protocol definition could be used as a guideline for this definition. Adoption of this symbology leads to more unique identification of securities and less 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.

12.2 FIX Protocol FIX and FIXML are widely used today as the de-facto messaging standard for pre-trade and trade communication as well as for U.S. regulatory reporting. Examples include ISG’s use of FIXML for LOPR (Large Options Position Report) reporting (via the OCC), CFTC use of FIXML, and FINRA TRACE reporting via FIX. The use of the FIX protocol for reporting purposes should be explored as part of the cost benefit analysis. The FIX Protocol provides a standard point of reference with industry participants and is typically used across the order lifecycle and within a firm’s order management processes. 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. The regulator can, where necessary, gain access to standardized information flows with respect to its rules in a way that simplifies both aggregation of the information (to provide a market-wide view) and to monitor compliance, while minimizing the cost of reporting obligations. Additionally, FIX is global and multi-asset class which may assist in extending CAT beyond listed options and equities.

12.3 Allocation of securities in primary market transactions The SEC 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. Additional discussions on this topic are required in order to fully understand the operational and technical implications of including this data into CAT.

12.4 Amendments/Exception Processing Additional discussions are also required to discuss exception processing and amendments to reports. For example, exception processing may be required for allocation reporting. Difficulties may arise when addressing amendments to allocations beyond the T+1 reporting period. Additionally, consideration

45

should also be given to the volume associated with options allocations and amendments to these allocations. With the linkages that will now be required between allocations, orders and executions, amendments to allocations can also impact previously reported order and execution reports. Additional exceptions/exemptions for some of this processing may be required in order to simplify reporting and correction processing. An analysis is required of exception processing including how best to handle amendments in the most cost efficient manner, while maintaining an accurate audit trail. 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.