diff --git a/spider/assets/js/search.js b/spider/assets/js/search.js index 89081bc..97ed89b 100644 --- a/spider/assets/js/search.js +++ b/spider/assets/js/search.js @@ -2,8 +2,8 @@ if (document.getElementById('q')) { /* global instantsearch */ var search = instantsearch({ - appId: '95DVATT6CT', - apiKey: '351c572afbb661b6120c8ec22ccda01e', + appId: 'PH1RESW6XC', + apiKey: '53d499dea359bf7e18c269df37553e95', indexName: 'dev_SPIDER', urlSync: {} }); diff --git a/spider/files/data000001.html b/spider/files/data000001.html index eca9cde..392556a 100644 --- a/spider/files/data000001.html +++ b/spider/files/data000001.html @@ -30,6 +30,7 @@
This document contains interpretive guidance for Industry Member CAT Reporters with respect to how the Technical Specifications must be implemented. As such, any changes to this document are subject to the same review and approval process by the Operating Committee, pursuant to the CAT NMS Plan, as the Technical Specifications.
This document represents a phased approach to industry reporting. Please note that a proposed amendment to the CAT NMS Plan will be filed with the Securities and Exchange Commission ("Commission") to reflect the phased approach for the Industry member CAT reporting described in the Technical Specifications. The proposed amendment will be subject to the approval of the Commission.
Revision / Change Process
+pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Introduction
@@ -66,7 +67,10 @@ • The creation of a New Order (Principal)
• The route to an exchange as an Order Route event
Note that the execution will be reported by the exchange, Broker 1 does not need to report the fill received.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Customer Order Routed to Exchange as Agent
@@ -79,7 +83,10 @@ • New Order event for the customer order
• Order Route event for routing the customer order to the exchange
In this scenario, since the execution is passed back directly to the customer, no Order Fulfillment event is required to be reported.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Customer Order Fulfilled on Average Price Basis
@@ -93,7 +100,11 @@ • New Order event for the representative order created from the average price account
• Order Route event for each representative order, or portion of the representative order, routed to the exchange
• Order Fulfillment event to report the average price given to the customer
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Routed between Two Industry Members and Subsequently Executed
@@ -102,13 +113,18 @@ This scenario illustrates the reporting requirement when an order is routed from one Industry Member to another.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Order event for the customer order
• Order Route event for routing the customer order to Broker 2
For this scenario, Industry Member Broker 2 is required to report the following events:
• Order Accepted event for the received client order from Broker 1
• Order Route event for routing the client order to the exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Split and Routed to Multiple Industry Members, Exchange, and Filled
@@ -117,6 +133,7 @@ This section illustrates the reporting requirement when a customer order is split and each slice is subsequently routed to different parties - external Industry Member and subsequently an exchange and to an ATS.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Order event for the customer order
• Order Route event for the routing of an order slice to Broker 2
@@ -127,7 +144,12 @@For this scenario, Industry Member ATS 3 is required to report the following events:
• Order Accepted event for the received client order from Broker 1
• Trade event when the order is matched
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Order Routed from an Exchange through a Routing Broker to another Exchange
@@ -138,6 +160,7 @@ This section will show the scenario when one exchange routes an order via a routing broker who is an Industry Member to another exchange.
+For this scenario, the exchange that routes the order (Exchange 1) must report:
• The route of the order to its routing broker
• After the execution, a Fill of the routed order
@@ -147,19 +170,24 @@The exchange that accepts the routed order (Exchange 2) must report the following events:
• The receipt of the order routed from Broker 1; and
• Any subsequent order handling events, if applicable
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order Route Followed by Electronic Route, Merged Event
Compliance User: Industry Member
Keywords:
This scenario illustrates the reporting requirements when an Industry Member manually routes an order to another Industry Member and follows up with an electronic route message.
+For this scenario, the sending Industry Member Broker 1 is required to report:
• New Order event for the customer order
• Order Route event for the electronically routed order (inclusive of routedOrderID) to Broker 2 with both the electronic and original manual timestamp
For this scenario, the receiving Industry Member Broker 2 is required to report:
• Order Accepted event for the electronically received client order (inclusive of routedOrderID) from Broker 1 with both the electronic and original manual timestamp
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order Route, Electronic Duplicate Order
@@ -176,7 +204,12 @@ For this scenario, Industry Member Broker 2 is required to report:
• Order Accepted event once agreeing to the route from Broker 1
• Order Accepted event for the receipt of the electronic order route from Broker 1 (marked with electronicDupFlag = true)
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Origination and Route Scenarios, Manual Order, One Side Reports Merged Event
@@ -191,7 +224,11 @@ For this scenario, the receiving Industry Member Broker 2 is required to report:
• Order Accepted event for agreeing to the route from Broker 1 (with manualFlag = true)
• Order Accepted event for the receipt of the electronic order route from Broker 1 (marked with electronicDupFlag = true)
-pubdate: N/A effdate: N/A
This scenario illustrates the reporting requirements to CAT when an Industry Member (Broker 1) matches a Customer Buy order with a Sell order routed from another Industry Member (Broker 2).
+For this scenario, Industry Member Broker 1 is required to report the following events:
1) The receipt of the order from the customer (New Order event)
2) The receipt of the order routed from Broker 1 (Order Accepted event)
@@ -215,7 +253,11 @@2) The route of the order to Broker 1 (Order Route event)
The customer Order A at Broker 1 was fully executed, while the routed order from Broker 2 was partially executed.
For ATS agency order cross, please refer to Section 2.2.1 step 10 for more details.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Internalized Trade against Proprietary Account
@@ -228,7 +270,9 @@ For this scenario, Industry Member Broker 1 is required to report the following events:
• The receipt of the customer order as a New Order event (New Order event)
• The execution as a Trade event
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, ATS Cross with Multiple Orders on One Side
@@ -240,7 +284,14 @@ This scenario illustrates the reporting requirement when an ATS performs a cross that has multiple orders on one side. For this case, the ATS must report:
• The receipt of the three orders involved in the execution (three Order Accepted events)
• Two Trade Events
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Negotiated Trade
@@ -257,7 +308,11 @@ • A New Order event
• The execution of the order (Trade event)
All of the New Order and Trade events occurring within the negotiation process must have the negotiatedTradeFlag and negotiatedTradeSide present and marked properly.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Trade Scenarios, Trade as the Result of a Quote
@@ -275,7 +330,11 @@ • A Trade event for execution against Market Maker A
For this scenario Industry Member OTCM must report the following event:
• Quote Received event for the receipt of the quote from Market Maker A
-pubdate: N/A effdate: N/A
2) Routing the representative order to the exchange (Order Route event)
Note that execution of the representative order is only reported by the exchange.
Because this scenario involves an aggregation of two customer orders that are worked as a single representative order, this is a Phase 2c representative order scenario and linkage between the customer orders and the representative orders is not required. In Phase 2c, the representative order and the underlying customer orders must be linked.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Single Order on a Riskless Principal Basis
@@ -308,6 +371,7 @@ This scenario illustrates the CAT reporting requirements when an Industry Member fills an order as riskless principal.
In this example, upon receipt of the customer order, the Industry Member sends a riskless principal or principal order to an exchange for execution, in order to satisfy the customer's order. The representative principal order is linked to the original customer order.
+The Industry Member Broker 1 is required to report the following events to CAT:
• The creation of the customer order as a New Order event
• The creation of a riskless principal order with linkage to the original customer order (New Order event with aggregatedOrders field). As an alternative, the Industry Member may report a New Order event (for the principal order) without linkage to the customer order, and an additional New Order Supplement event
@@ -316,7 +380,11 @@The exchange will report the following:
• The receipt of the order B routed from the Broker 1
• The execution of order
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Customer Order Internally Routed to Another Desk and Subsequently Executed Against a Firm Proprietary Account
@@ -326,11 +394,14 @@ This section will illustrate an example of CAT reporting when an Industry Member internally routes a customer order from the sales desk to the trading desk, and subsequently executes against a firm proprietary account. The sales desk and trading desk are separated by information barriers.
+In this scenario, Industry Member Broker 1 must report the following events to CAT:
• The receipt of the customer order in a New Order event
• The internal route from the sales desk to the trading desk (Order Internal Route event)
• The principal execution (Trade event)
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Customer Order Internally Routed to Multiple Desks and Subsequently Executed
@@ -339,6 +410,7 @@ This scenario illustrates the CAT reporting requirements when an Industry Member internally routes a customer order from the sales desk to multiple desks within the Industry Member. Each destination desk subsequently internally fills the order. Each internal route and execution must be reported separately.
+For this scenario, Industry Member Broker 1 is required to report the following events for CAT:
• At the Sales Desk
• New Order event for the customer order
@@ -351,13 +423,19 @@• At the Program Trading Desk
• Order Internal Route event from the trading desk to the program trading desk
• The principal execution as a Trade event
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Internal Route and Execution, Leaves Quantity Routed Externally
Compliance User: Industry Member
Keywords:
This scenario illustrates the reporting requirements to CAT when an Industry Member internally routes an order to another desk where it is partially executed and the remainder is routed to another Industry Member to execute.
+Industry Member Broker 1 is required to report the following events:
• New Order event for the customer order
• Order Internal Route from the Sales Desk to the Trading Desk
@@ -366,7 +444,10 @@Industry Member Broker 2 is required to report the following events:
• Order Accepted event for the order from Broker 1
• Trade event for the execution of Broker 1's order
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Customer Order from a Pre-Existing Principal Order
@@ -380,7 +461,11 @@ • Route the principal order to an exchange via an Order Route event
• The receipt of a customer order (New Order event)
• Fill of the customer order with the executed principal order via an Order Fulfillment event
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Fill of a Customer Order from a Pre-Existing Principal Order with Better Price than the Representative Order
@@ -394,7 +479,12 @@ • The creation of the representative order as a New Order event
• The route of the representative order to the exchange as an Order Route event
• An Order Fulfillment event for the fill of the customer order against the principal order
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Route to Foreign Broker
@@ -407,7 +497,10 @@ • A New Order event for the receipt of customer order
• An Order Route event for the routing of the order to the foreign broker
• An Order Fulfillment event to show the executed shares given back to the customer
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Fulfillment Scenario s, Order Fulfillment Amendment
@@ -415,8 +508,10 @@ Keywords:
In the following scenario, the Industry Member amends the price of a customer fill that was reported to CAT on a previous day.
For this scenario, Industry Member Broker 1 is only required to report an Order Fulfillment Amendment event for T+1.
+Note that the amendment reporting is only applicable to Order Fulfillment events, not the events reported to the TRF for media dissemination (which would have originally been reported as Trade events).
-pubdate: N/A effdate: N/A
This scenario illustrates the reporting requirements to CAT for an Industry Member for a customer initiated modification on an order.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Order event for the customer order
• Order Modified event upon receipt of customer request
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Initiated Modification of Order Previously Routed to Exchange
@@ -449,7 +547,11 @@ • Order Route event for the route to the exchange
• An Order Modification event
• A second Order Route event for the route of the modified order to the exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Customer Initiated Modification of Order Previously Routed to Another Industry Member
@@ -458,6 +560,7 @@ This scenario illustrates the reporting requirements to CAT for two Industry Members when a customer of the first Industry Member initiates a modify on an order. The example shown does not illustrate events that would occur following the second Order Route event to account for the New Order and Order Accepted events, such as cancellations, trades, or fulfillments.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Order event for the customer order
• Order Route event for the routing of the order to Broker 2
@@ -466,7 +569,11 @@For this scenario, Industry Member Broker 2 is required to report the following events:
• Order Accepted event for the received client order from Broker 1
• Order Modified event upon receiving the modify notice from Broker 1
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, System Driven Modification of Previously Routed Order
@@ -479,7 +586,11 @@ For this scenario, receiving Industry Member Broker 2 is required to report the following events:
• Order Accepted event for the received order from Broker 1
• Order Modified event upon receiving the modify from Broker 1
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Order Modification of a PEG Order by a Display ATS
@@ -499,7 +610,12 @@ ATS A must report:
• An Order Accepted event for the receipt of the PEG order from Broker 1
• The modification of the price due to NBBO changes - this should be reported using an Order Adjusted Event with only the price fields restated
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Display Modifications of a Display ATS
@@ -508,6 +624,7 @@ Display modifications can be reported to CAT using the Order Adjusted event. This scenario illustrates the reporting requirements when an order is partially executed on an ATS, and as a result the display size of the order changes.
+In this scenario, an order is routed to an ATS for execution. The sending Industry Member Broker 1 is required to report:
• Receipt of the order from the customer in a New Order event
• An Order Route event of the order route to ATS A
@@ -516,7 +633,12 @@• Partial execution of the order as a Trade Event
• Update to the display size post execution as an Order Adjusted event
Note that ATS A and Broker 1 may have subsequent order handlings on the order. This example is to illustrate the display modification reporting only, so not all possible steps are shown here.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Order Modification Scenarios, Manual Route, Followed by an Electronic Modification
@@ -527,6 +649,7 @@ This scenario illustrates the Phase 2a reporting requirement to CAT when an order is initially routed manually between two Industry Members, and then an electronic message is sent to modify the material terms of the order.
+In this scenario, Industry Member Broker 1 must report:
• Receipt of the customer order in a New Order event
• Manual route of the order to Broker 2 (Order Route event)
@@ -535,7 +658,11 @@The following must be reported by Industry Member Broker 2:
• Receipt of the manual route from Broker 1 (Order Accepted event)
• An Order Modified event for reducing quantity of the order (Order Modified event)
-pubdate: N/A effdate: N/A
For this scenario, Industry Member Broker 1 is required to report the following events:
• New Order event for the customer order
• Order Canceled event upon receipt of notice by the customer
+Note that for illustration purposes, actions taken by the Broker between the receipt of the original order and the customer cancellation are not included.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Partial Cancellation of an Order
@@ -562,7 +692,10 @@ In this scenario, Industry Member Broker 1 must report:
• The receipt of the customer order as a New Order event
• Either a Order Canceled event or an Order Modified event for the partial cancellation
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Cancellation Scenarios, Cancellation of a Routed Order
@@ -571,6 +704,7 @@ This scenario illustrates the CAT reporting requirements for an Industry Member when an order that was previously routed to another Industry Member is canceled.
+Industry Member Broker 1 must report:
• The receipt of the customer's order as a New Order event
• The initial route of the order to Broker 2 (an Order Route event)
@@ -578,7 +712,10 @@Industry Member Broker 2 must report:
• The receipt of the route from Broker 1 as an Order Accepted event
• The cancellation of the order as an Order Canceled event
-pubdate: N/A effdate: N/A
In this scenario, the desk which received the customer's order transfers the order into another internal application in order to route the order to an exchange. Since the desk handling the order does not change, the Industry Member Broker 1 is required to report:
• New Order event for the receipt of the customer order
• Order Route event for route to the exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Creates Child Orders and Routes
@@ -609,7 +749,12 @@ • An Order Route event for each child order
Receipt Industry Members Broker 2 and 3 are required to report:
• Order Accepted events for receipts of the order from Broker 1 (and any subsequent order handling)
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Industry Member Creates Multiple Branches of Child Orders
@@ -621,6 +766,7 @@ This scenario illustrates the reporting requirements for an Industry Member where each internal desk has chosen to work an order by splitting the original order into smaller components. The Industry Member has the flexibility to report different events for each desk, should it better reflect the firm's internal systems.
+For this scenario, Industry Member Broker 1 must report:
• The receipt of the customer order at the Sales Desk as a New Order event
• A Child Order event for each slice created at the Sales Desk prior to routing to another desk
@@ -628,24 +774,35 @@• For the Child Order sent to the Arbitrage Desk, a Child Order event for each new slice created
• An Order Route event for each Child Order routed from the Arbitrage Desk
• For the Child Order sent to the Trading Desk, an Order Internal Route event for each slice of the order (and any subsequent events not shown)
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Received and Routed Manually, Electronically Captured at Subsequent Desk
Compliance User: Industry Member
Keywords:
This scenario illustrates the reporting requirements for an Industry Member when an order is received and then manually internally routed to another department where it is immediately entered into an electronic order management system upon receipt (e.g. the branch receives an order and calls the Trading Desk).
+For this scenario, Industry Member Broker 1 must report:
• The receipt of the order from the customer (a New Order event with manualFlag = true)
• An Order Internal Route event for route of the order to the trading desk which will enter the trade into the Industry Member's electronic system
• The route of the order to the exchange (Order Route event)
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routed and Executed via a Clearing Firm
Compliance User: Industry Member
Keywords:
This example illustrates the reporting requirements when an introducing firm enters the customer order into the clearing firm's system. The clearing firm then executes the order from a proprietary account. Both the introducing firm and clearing firm are Industry Members.
+For this scenario, the introducing firm (Broker 1) must report:
• The receipt of the order from the customer in a New Order event
• The route of the order to the clearing firm in an Order Route event
@@ -653,7 +810,9 @@• The receipt of the order by the clearing firm in an Order Accepted event
• The execution of the order in a Trade event
Only the executing entity is required to report executions to CAT. In this scenario only the clearing firm is responsible to report a Trade event.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Direct Order Routing via a Clearing Firm's System
@@ -665,7 +824,10 @@ • The route of the order to the Exchange 1 in an Order Route event
The clearing firm does not have CAT reporting obligations.
The exchange follows Participant reporting requirements for subsequent handling.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routing via an Algorithm Provided by the Clearing Firm
@@ -681,7 +843,11 @@ The routing destination (exchange) must report:
• The receipt of order routed from the clearing firm
• The subsequent order handling actives that are CAT reportable
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Order Routing via Smart Router Provided by another Industry Member
@@ -698,6 +864,7 @@ 3. The Destination Market Center views the order as coming directly from the originating Industry Member, not the Industry Member providing the order routing system, for all purposes, but not limited to, CAT reporting, trade reporting, applicable fees, etc.
4. The originating Industry Member, rather than the member providing the order routing system, identifies itself as the routing firm for purposes for the SEC Rule 606 (formerly SEC Rule 11Ac1-6).
+The introducing firm, Industry Member Broker 1, is required to report:
• The receipt of the customer order in a New Order event
• The route of the order through a smart router (Order Route event with handlingInstructions = SMT)
@@ -705,7 +872,10 @@• Execution of the order (Trade event)
The Industry Member providing the order routing system is not required to report to CAT.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, GTC Order Routed to Exchange, Modified by Customer
@@ -715,13 +885,18 @@ The following scenario illustrates the reporting requirements for handling order types that can live across days (e.g. GTC, GTD). Industry Member Broker 1 receives a "GTC" order from a customer. From Broker 1's perspective, the order is reported as GTC as maintained on their book. When Broker 1 routes the order to the exchange for execution, the order is a "DAY" order from the exchange's perspective and should be reported as timeInForce = DAY on the Order Route event as well as relevant Participant events. The Industry Member must submit an Order Route event every day the order is sent to the exchange until the order is executed or canceled.
On T+1, the customer modifies the GTC order. Broker 1 must report an Order Modified event with the original order date and an Order Route event for the modification on the exchange.
+For this scenario, Industry Member Broker 1 is responsible for reporting:
• The receipt of the customer GTC order on T (New Order event)
• An Order Route event for the route to the exchange (as a "DAY" order)
• Another Order Route event for the route to exchange on T+1 (start of day) as the order was not executed or canceled on T
• The modification of the customer order on T+1 (during market hours) in an Order Modified
• The route of the modified order to the exchange on T+1 (Order Route event)
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Dividend Reinvestment
@@ -734,6 +909,7 @@ The following scenario illustrates the reporting requirements for an Industry Member whose customers participate in a dividend reinvestment program. Industry Member Broker 1 aggregates dividend reinvestment investment program (DRIP) orders for participating customers, rounds up to the the next whole share, and creates a new order to purchase shares that need to allocate to customers. This order is routed to the street, executed, and allocated to the participating customers. The remaining fractional share is allocated to the proprietary account of Broker 1. It is not required for Broker 1 to report Post Trade Allocation events for allocations to sub-accounts for dividend repurchase orders until Phase 2c.
+For this scenario, Industry Member Broker 1 is responsible for reporting:
• A New Order event for a single order to acquire shares for all customers participating in the dividend reinvestment program
• An Order Route event for routing the principal purchase to Broker 2
@@ -741,13 +917,19 @@• An Order Accepted event to confirm receipt of the order from Broker 1
• A Trade event confirming execution of the order
Once the fractional inventory reaches a whole share threshold, Broker 1 would follow standard procedures for sales from proprietary accounts if actions were taken to flatten fractional share inventory.
+Industry Member Broker 1 is responsible for reporting:
• A New Order event for the whole share order
• An Order Route event for routing the sale order to Broker 3
Industry Member Broker 3 is responsible for reporting:
• An Order Accepted event for the receipt of the order from Broker 1
• A Trade event for the execution of the order
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, Additional Reporting Scenarios, Routing of the Equity Leg of a Complex Option to another Industry Member
@@ -768,7 +950,13 @@ • The receipt of the equity leg order (Sell) from Broker 1 in an Order Accepted event
• The receipt of the equity leg order (Buy) from Broker 1 (Or receipt of a Buy order from another Industry Member) in an Order Accepted event
• The execution of the orders in a Trade Event
-pubdate: N/A effdate: N/A
Below is a JSON representation using the example in section 2.2.2 Internalized Trade Against Proprietary Account.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Equity Scenarios and Examples, JSON and CSV Examples, CSV Representation
@@ -824,7 +1014,10 @@ For this scenario, Industry Member Broker 1 is required to report the following events:
• The creation of a New Option Order (Principal)
• The route to an exchange as an Option Order Route event
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Routed to the Exchange
@@ -838,7 +1031,10 @@ • New Option Order event for the customer order which was received electronically
• Option Order Route event for routing the customer order to the exchange
In this scenario, the execution is passed back directly to the customer, therefore no Option Order Fulfillment is required to be reported.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Option Order Electronically Routed between Two Industry Members and Subsequently Executed
@@ -851,13 +1047,17 @@ This scenario illustrates the reporting requirements when an option order is electronically routed from one Industry Member to another.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Option Order event for the customer order which was received electronically
• Option Order Route event for routing the customer option order to Broker 2
For this scenario, Industry Member Broker 2 is required to report the following events:
• Option Order Accepted event for receiving the client order from Broker 1
• Option Order Route event for routing the order to the Exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Manually Received, Routed Electronically
@@ -869,7 +1069,10 @@ This scenario illustrates the reporting requirements for Phase 2b for a customer order received manually by an Industry Member that is systematized and electronically routed.
For this scenario, Industry Member Broker 1 is required to report the following events: • Option Order Route event for the route of the option order to the exchange
In Phase 2b, the Option Order Route event must include the priorUnlinked= M, indicating the prior step is a manual handling not reported in Phase 2b.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Option Order Origination and Route Scenarios, Customer Option Order Received Electronically, Manually Routed
@@ -881,11 +1084,14 @@ This scenario illustrates the reporting requirement for Phase 2b for a customer order received electronically by an Industry Member that is manually routed to another Industry Member. The order is then subsequently routed to the exchange.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Option Order event for the customer order which was received electronically (The nextUnlinked flag must be marked as "M" indicating next step is a manual handling so no linkage is available)
For this scenario, Industry Member Broker 2 is required to report the following events:
• Option Order Route event for the route of the option order to the exchange (The priorUnlinked flag must be marked as "M" indicating prior step is a manual handling so no linkage is available)
-pubdate: N/A effdate: N/A
This scenario illustrates the Phase 2b reporting requirements for Industry Members when a complex option order is created from multiple single leg option orders. For Phase 2b, there is no linkage required between the single leg option orders and the complex order.
+For this scenario, Industry Member Broker 1 is required to report the following events:
• New Option Order events for each single leg customer order electronically received
• Option Order Fulfillment events for each single leg customer order post execution of the complex order
In Phase 2b, the two New Option Order events must be flagged as nextUnlinked = C, indicating that the orders are represented by a complex order so no linkage to the complex order in Phase 2b.
-pubdate: N/A effdate: N/A
• Option Order Route event for the route to the exchange
• An Option Order Modification event for the electronic receipt of the order modification
• A second Option Order Route event for the route of the modified option order to the exchange
-pubdate: N/A effdate: N/A
• New Option Order event for the customer order which was received electronically
• Option Order Internal Route event from the sales desk to the trading desk
• Option Order Route event for the route of the option order to the exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Customer Option Order Internally Routed Electronically, Trading Desk Creates Child Orders Prior to Route
@@ -977,7 +1194,11 @@ • Option Order Internal Route event from the sales desk to the trading desk
• Child Order events for slicing the original order into smaller quantities and assigning new orderIDs prior to routing from the Trading Desk
• Option Order Route events for the route of each child option order to an exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Receives Complex Option Order, Splits into Individual Single Order Legs to be Worked in the Customer's Account
@@ -988,7 +1209,10 @@ This scenario illustrates the reporting requirements for an Industry Member in Phase 2b that receives a complex option order but routes single leg option orders directly from the customer's account to the exchange without creating new single leg option orders. Linkage between the original complex option order and the single leg option order routes is not required in Phase 2b, but reporters must indicate on the Option Order Route event there is no prior step reported since it was a complex order by populating field priorUnlinked = C. Since the single leg orders were routed to the exchange as single legs, linkage to the related single leg exchange order is required.
In this scenario, Industry Member Broker 1 is required to report the following events:
• Option Order Route events for each single leg option order routed to the exchange
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Receives Complex Option Order, but Client Sends Multiple Single Leg Option Orders Electronically
@@ -999,7 +1223,11 @@ This scenario illustrates the reporting requirements for an Industry Member that receives a complex order that is routed by the Industry Member to an exchange as a complex order but where the client sends single leg electronic messages due to limitations in the client's system.
For Phase 2b, reporting this order is out of scope as it was intended to be handled as a complex order. In Phase 2b, the preferred approach is that the Industry Member not report the electronic single leg orders as complex orders are not in scope. However, if Industry Member's elects to report the single legs, they must populate handlingInstruction 'CMPX' and include the nextUnlinked = 'C', to indicate there is no linkage to additional order events as subsequent handling was at the complex order level.
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Routes Multiple Single Leg Option Orders to another Industry Member, Calls with Complex Order Instructions
@@ -1013,7 +1241,16 @@ • Four (4) Option Order Route events for the route of the single leg orders to Broker 2
Industry Member Broker 2 would report the following events:
• Four (4) Option Order Accepted events for the electronic routes received from Broker 1
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Industry Member Solicits Order, Creates Paired Option for Partial Quantity
@@ -1025,7 +1262,11 @@ In this scenario, Industry Member Broker 1 is required to report the following events:
• New Option Order event for the receipt of the customer order
• Option Order Route for the un-paired quantity of the single leg order
-pubdate: N/A effdate: N/A
Topic: CAT Industry Member Reporting Scenarios, Executive Summary, Option Scenarios and Examples, Additional Reporting Scenarios, Response to an Exchange Auction
@@ -1037,7 +1278,10 @@ In this scenario, Industry Member Market Maker 1 is required to report the following events:
• New Option Order event for the creation of the proprietary order
• Option Order Route event for the response to the exchange auction
-Under Rule 613(g)(2), each member of a national securities exchange or national securities association is required to comply with all the provisions of the CAT NMS Plan. Relatedly, as mandated under Rule 613, the CAT NMS Plan requires each SRO to adopt rules requiring its members to comply with Rule 613 and the CAT NMS Plan, and to agree to enforce compliance by its members in that regard. Accordingly, each SRO has adopted rules requiring its members to comply with Rule 613 and the CAT NMS Plan. See, e.g., FINRA Rule 6800 Series.
The SROs jointly own CAT NMS, LLC, which was formed by the SROs to arrange for and oversee the creation, implementation, and maintenance of the CAT as required under Rule 613. Thus, the CAT is a facility of each SRO.
This specification represents a phased approach to industry reporting. Key dates are as noted below. Please note that a proposed amendment to the CAT NMS Plan will be filed with the Commission to reflect the phased approach for Industry Member CAT reporting described in these Technical Specifications. The proposed amendment will be subject to the Commission's approval.
- +pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Executive Summary
@@ -41,7 +43,9 @@ This document describes the requirements for the reporting of data to CAT by Industry Members, including detailed information about data elements and file formats of each Reportable Event. It also describes how Industry Members should submit files to CAT, including access instructions, network and transport options, and testing requirements.
A separate companion document containing detailed reporting scenarios entitled CAT Industry Member Reporting Scenarios should be used as a guide for determining how the event types and field values laid out in this document should be applied when reporting various order handling and execution scenarios for both equities and options.
Revision / Change Process
-pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Introduction
@@ -280,6 +284,11 @@ Data Validation Based on Data Types
All data submitted to CAT will be validated based on the defined data type of each item, including proper formatting and range checking. Examples of accepted values are detailed in the table below. Valid values for Choice fields are defined in the Data Dictionary for each data element. Valid data values, ranges, and formats will be specified in the record schema files, which will be used to validate submitted data element values. Records and values that fail validation will be marked as a failure and will be reported as feedback to the Reporter and Data Submitter as detailed in Section 7.
Data Types
+pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Data Types, Name/Value Pairs
@@ -303,7 +312,8 @@ Compliance User: Industry Members
Keywords:
Throughout this document, event types and their fields will be defined. Each field will be notated with the abbreviation R, C, O or A to represent whether it is required, conditionally required, optional or required for ATSs only. This codification will appear in the last column of each table describing an event.
-pubdate: February 28, 2019 effdate: N/A
In Phase 2a, Industry Members are responsible for reporting routes, modifications, and cancellations in line with OATS guidance. Below are a list of sample scenarios and the reporting responsibilities of the sender (Broker A) and the receiver (Broker B).
-pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, CAT Reporting Fundamentals, Linkage Overview, Summary of Route Linkage Keys
@@ -352,6 +364,8 @@ The table below summarizes the required data elements to construct the route key for linking Route and Order Accepted events reported by different entities in CAT. The combination of the data elements must be unique. Data elements in the same row must always be equal values. Note that only the data elements used to create linkage are listed here.
For Participant related event details, please refer to the CAT Reporting Technical Specifications for Participants.
+* Not required for manual order route/receipt.
• session - The session field contains an ID string for the specific session used to route the order. Note that this differs from the trading session (e.g., pre-market, regular, post-market, etc.) Session can constitute an actual protocol session name, IP/port combination, unique login account, or some other means of identifying a particular API session. It must be reported as the same value by both the sending and receiving entities. When routing between two Industry Members, the session must be left blank by both the sending and receiving entities.
• routedOrderID - When an order is routed away, it may be assigned another ID on the route - this is noted in the Order Route event as the routedOrderID (e.g., the ClOrdID in FIX, ClientOrderID for NYSE UTP direct users, etc). This ID must match the routedOrderID reported by the receiving entity in its Order Accepted event.
@@ -477,6 +491,8 @@This section describes Reportable Events for equities that are Eligible Securities. The following table lists each equity event type with its corresponding Message Type code.
Events and data elements that are greyed out do not apply to Phase 2a.
Equity Events
+pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Order Event
@@ -506,6 +522,9 @@ The representativeInd is used to show whether an order is originated to represent a customer/client order and whether the linkage is present. It is required for all New Order events.
Note that all fields and values necessary to support Phase 2c linkages are included in this version of the specification and Industry Member Reporters may voluntarily report these linkages prior to the start of Phase 2c.
New Order Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Quote Key: date, reporter, symbol, quoteID (if applicable)
@@ -525,6 +544,7 @@2) When there is no explicit linkage to disparate orders when a representative order is generated. This supplement event can be used to capture the relationship of representative and disparate orders and submitted to CAT separately as an addition to the original New Order event.
This event can be submitted in the same file as the original New Order event or in a separate file, so long as it is submitted on the same date as the New Order event. One New Order event can have multiple New Order Supplement events. Multiple New Order Supplement events are considered as additions (not replacements or modifications). The aggregatedOrders field in the New Order Supplement event should only contain the additional Name/Value Pairs that have not been captured in the original New Order event (or another Supplement event for the same New Order).
New Order Supplement Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Order Key: date, reporter, symbol, aggregatedOrders.Name
@@ -553,6 +573,9 @@Notes
• Please note that internal routes to another desk or department within an Industry Member are not reported using the Order Route event; instead an Order Internal Route event is used. See the Order Internal Route section for more details.
Order Route Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, orderID
• Order Key: priorOrderDate (when present), reporter, symbol, orderID
@@ -594,6 +617,9 @@When an Industry Member receives a routed order from another CAT Reporter (i.e., Industry Member, ATS or exchange), then an Order Accepted event must be reported to CAT by the Industry Member receiving the routed order. As described in Order Route event, if an Industry Member accepts a routed order from another IMID belonging to the same Industry Member, i.e., the same CRD, an Order Accepted event must be reported.
Once all Industry Members are reporting to CAT, in all cases, the order reported with this event should have already been originated by another broker and reported upon origination with a New Order event. A New Order event represents the beginning of the order lifecycle in CAT, therefore a new customer order is represented with a New Order event - not an Order Accepted event. Similarly, orders received by an Industry Member from its non-broker-dealer affiliates or from a non-reporting foreign broker-dealer should be reported as a New Order event - NOT an Order Accepted event. (Note: At the start of Phases 2a and 2b, there will be some lifecycles beginning at Order Accepted event, as small Industry Members will not be required to report until a later phase).
Order Accepted Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Route Link Key: date, senderIMID, destination, symbol, session, routedOrderID
@@ -626,6 +652,9 @@Order Internal Route event is used to report routing within a reporterIMID as described above.
Internal Route Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Prior Order Key: date, reporter, symbol, priorOrderID
@@ -673,6 +702,8 @@Child Order Event
+Linakge keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Prior Order Key: date, reporter, symbol, parentOrderID
@@ -690,6 +721,8 @@When the price, quantity or any Material Terms of the child order has been changed, a Child Order Modified event must be reported to CAT. This modification event is only used when the child order creation is reported to CAT in a Child Order event. As such, modifying a partial quantity internal route can not be reported in this event.
All attributes and Material Terms of the Order of a modified child order listed on this event should be reported when applicable, including the fields that remain unchanged.
Child Order Modified Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Prior Order Key: date, reporter, symbol, priorOrderID
@@ -705,6 +738,7 @@If a child order is canceled, a Child Order Canceled event must be reported to CAT by the Industry Member.
Note that a partial cancellation can be reported either with a Child Order Modified event or Child Order Canceled event with leavesQty, depending on how it is handled by the Industry Member. If an actual Cancel message was used, the Industry Member should report a Child Order Canceled event to CAT. If a modify or cancel/replace message was used, a Child Order Modified event should be reported to CAT. This keeps the reported event in line with the action taken by the Industry Member.
Child Order Canceled Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
Side is required to be reported, but side adjustments are only allowed for same-side changes (e.g., changes between short and long sell).
All attributes and Material Terms of the modified order listed on this event should be reported when applicable, including the fields that remain unchanged.
Order Modified and Cancel/Replace Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date (from eventTimestamp), reporter, symbol, orderID
• Prior Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, priorOrderID
@@ -741,6 +779,7 @@The Order Modified Supplement event serves as a supplement to the Order Modified event, just as the Supplement Event serves as a supplement to the New Order event.
Order Modified Supplement Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Order Key: date, reporter, symbol, aggregatedOrders.Name
@@ -764,6 +803,9 @@When the display price or quantity changes as the result of a display ATS matching engine action and not from a customer instruction, an Order Adjusted event must be used (the Order Modified event cannot be used in this scenario).
Any modification that cannot be fully represented in this Reportable Event must be reported via the Order Modified event.
Order Adjusted Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, symbol, orderID
• Prior Order Key: date, reporter, symbol, priorOrderID
@@ -783,6 +825,7 @@• This Order Canceled Event is only reported by the entity that performs the cancellation. Cancellations by away venues are not required to be reported. For example, if Broker B accepts an order from Broker A, and Broker B initiated a cancel on the order, then B is responsible for reporting the order canceled (not Broker A).
• Implicit order cancellations are not required to be reported to CAT (e.g., cancellation due to expiration of Time in Force.)
Order Canceled Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, symbol, orderID
• Order Key: priorOrderDate (when present), reporter, symbol, orderID
@@ -811,6 +854,9 @@Note that there is no Quote Modify event. The field priorQuoteID is used to report modifications to a previously reported New Quote. If the field priorQuoteID is populated with a value in the New Quote event, then this New Quote is considered to replace the quote described in the priorQuoteID field. In the case when quote ID does not change for a modified quote, the priorQuoteID and the quoteID (new) will have the same value.
Otherwise, if the field onlyOneQuoteFlag = true, any New Quote event offered by the same reporterIMID to the same destination in the same symbol will be considered canceled by CAT.
New Quote Event Field Specifications
+pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote, Quote Received
@@ -821,7 +867,9 @@ When Quotes are sent to another Industry Member, that receiving Industry Member must report their receipt of the quote. Note that Industry Members do not have to report the quotes that they do not accept.
Quote Received Event Field Specifications
-pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Equity Events, New Quote, Quote Canceled
@@ -833,8 +881,11 @@ Quote Canceled Event Field Specifications
-pubdate: February 28, 2019 effdate: N/A
The tables below describe the data elements to report agency cross or internalized orders by filling them from a proprietary account.
Trade Event Field Specifications
+Trade Side Details
+Linkage Keys for this Reportable Event:
• Order Key: date, reporter, symbol, buyDetails.orderID
• Order Key: date, reporter, symbol, sellDetails.orderID
@@ -892,7 +947,10 @@If a trade is the result of a quote displayed by a market maker on an inter-dealer quotation system where the market maker is the executing broker under FINRA trade reporting rules and required to report the trade to the FINRA ORF, the Trade as the Result of a Quote event must be used to report the trade. The market maker is required to report the Quote ID of the quote from the inter-dealer quotation in order to link the quote to the trade.
Trade on a Quote Event Field Specifications
+Trade on a Quote Side Details
+Linkage Keys for this Reportable Event:
• Order Key: date, reporter, symbol, buyDetails.orderID
• Order Key: date, reporter, symbol, sellDetails.orderID
@@ -932,7 +990,10 @@Order Fulfillment Event Field Specifications
+Fulfillment Side Details
+Linkage Keys for this Reportable Event:
• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter, symbol, firmDetails.orderID
• Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter, symbol, clientDetails.orderID
@@ -957,6 +1018,8 @@If an Industry Member makes a correction via a debit/credit to the customer's account instead of modifying the executed shares given back to the customer, then the Industry Member does not need to report an Order Fulfillment Amendment event.
Note that the amendment reporting is only applicable to Order Fulfillment events, not the events reported to the TRF for media dissemination (which would have originally been reported as Trade events).
Order Fulfillment Amendment Event
+Linkage Keys for this Reportable Event:
• Order Key: date (from eventTimestamp if firmDetails.priorOrderDate is not present), reporter symbol firmDetails.orderID
, , . • Order Key: date (from eventTimestamp if clientDetails.priorOrderDate is not present), reporter symbol clientDetails.orderID
@@ -991,10 +1054,13 @@• If data elements are greyed out for Phase 2b on a supported order event, the fields will be supported7 though not required. The Industry Member may voluntarily report the elements in Phase 2b.
Linkages in Phase 2b
In Phase 2b, the definition of an electronic single option order will result in unlinked events within a single CAT Reporter. To address these expected unlinked events, two fields (priorUnlinked and nextUnlinked) are used as described below. The purpose of these fields is to identify that the immediately preceding or following event is not reportable in Phase 2b and is not present for linkage. An immediately preceding or following event may be a manual event, complex order event, or a paired order. The priorUnlinked and nextUnlinked fields have values to indicate why the immediately preceding or following event is not present.
+One or both of these fields will be on all options event types as conditional. If an event does not have this field populated, linkage will be attempted.
Special circumstances of a complex order being represented as individual legs in Phase 2b
In the special circumstance of an Industry Member sending (receiving) a complex order electronically as individual legs of the complex orders, the preferred method of reporting is to suppress the events associated with these messages. If an Industry Member cannot do this, the Industry Member must populate the handlingInstructions field with 'CMPX' to indicate that the order (route) is part of a complex option order in Phase 2b. In addition, such voluntarily reported single leg orders must include a priorUnlinked or nextUnlinked flag of 'C', as applicable, to indicate they will not link to a related order at the sending (receiving) firm.
Summary of Option Order Events
+pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Single Leg Option Events, New Option Order Event
@@ -1023,6 +1089,8 @@ Any scenario that does not meet the definition of Phase 2b representative order will fall into this category, including any scenario involving a manual or complex order.
See the CAT Industry Member Reporting Scenarios document for detailed examples of how representative order scenarios for options are reported in Phase 2b.
New Option Order Event
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, optionID, orderID
• ComplexOrderKey: date, reporter, (complexOptionID), complexOrderID (Not applicable in Phase 2b)
@@ -1074,6 +1142,9 @@Handling Instructions on the Option Order Route
The handling instructions included in this event should represent those on the routed order. If the handling instructions do not change from the Option Order Accepted or New Option Order associated with the order, Industry Members may use the handling instruction code "RAR" - routed as received, instead of repeating each individual handling instruction.
Option Order Route Event Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date (from eventTimestamp if priorOrderDate is not present), reporter, optionID, orderID
• Order Key: priorOrderDate (when present), reporter, optionID, orderID
@@ -1112,6 +1183,9 @@Once all Industry Member are reporting, in all cases, the order reported with this event should have already been originated by another Industry Member and reported upon origination with a New Option Order event. A New Option Order event represents the beginning of the order lifecycle in CAT, therefore a new customer order is represented with a New Option Order event - not an Option Order Accepted event. At the start of Phase 2b, there will be some lifecycles beginning at Option Order Accepted event, as Small Industry Members are not required to report until a later phase.
Orders received from a non-reporting foreign entity or affiliate should be reported as a New Option event instead of an Option Order Accepted event.
Option Order Accepted Field Specifications
+Linkage keys for this Reportable Event:
• Order Key: date, reporter, optionID, orderID
• Route Link Key: date, senderIMID, destination, optionID, session, routedOrderID
@@ -1427,6 +1501,7 @@Metadata Files
The hashes are to be submitted as 64-character hexadecimal string encodings of the hash value.
+If a metadata block in the file has an error, the erroneous block will be dropped, and proper corresponding feedback will be returned (see Section 7 for File Acknowledgment Feedback or Basic File Integrity Feedback). The rest of the "blocks" of the metadata file will continue to be processed. The reporter can resubmit the corrected metadata block in another metadata file.
Reporters can include the metadata for original data files and for correction files into one metadata file, as long as they are for the same reporter, submitter and calendar day.
JSON schema files for each record type will be provided on the CAT public website. Industry Members will be able to download and use these schemas to format and validate their CSV and JSON data files prior to submission. These schemas will also allow Industry Members to translate their data files from JSON to CSV or from CSV to JSON formats, as desired.
The schema files will be maintained by the Plan Processor and will be versioned as the message specifications change. The meta files submitted to CAT will contain a version identifier specifying which version of the schema the associated reference or order data was formatted in accordance with. This will allow the CAT System to perform a basic initial formatting validation of all submitted data.
Provided here is an abbreviated example of a JSON schema containing only part of the equity New Order event and a couple definitions for Choice fields:
+Note that the file is not a typical "JSON schema" but a schema describing the Reportable Events in JSON.
The field "JSONDataType" indicates the underlying JSON data type.
The field "dataType" is the actual type, as indicated in this specification, with some further restrictions over the underlying JSON data type.
@@ -1469,6 +1546,8 @@The JSON schema defines valid data types, and mappings between JSON and CSV. Note that schemas can change with each specification version, and the authoritative schemas will be available on the CAT website. For this discussion, assume the following schema for an Equity Order Adjusted event. Provided here is an abbreviated example of a JSON schema containing only part of the Order Adjusted event and a couple definitions for Choice fields:
+The corresponding CSV would be:
MEOJ,20170901T120201.123456,E,false,,,XYZ,T12346,T12345,Customer,Buy,,,,1100, 100,100,,,,,,,,
• Failure Code
• Failure Description
The following is an example JSON object for a successful file acknowledgement:
+CSV presentation of a successful file acknowledgement:
Line 0 SUBID,MYID,20170307T153552.000001089,20170307, MYID_20170307_OrderEvents_000123.json.gz.pgp,0.1,Success
The following is an example JSON object for an unsuccessful file acknowledgement:
+CSV presentation:
Line 0 SUBID,MYID,20170307T153552.000001089, 20170307,MYID_20170307_OrderEvents_000123.json.gz.pgp,0.1,Failure
Line 1 ERROR, FILE.TIMEOUT.001, Time out waiting for meta file
@@ -1781,9 +1862,11 @@• Failure Code
• Failure Description
The following is an example JSON object for a successful integrity check:
+CSV conversion
Line 0 SUBID,MYID,20170307T153552.000001089,20170307,0.1,Success
The following is an example JSON object for an unsuccessful integrity check:
+CSV conversion
Line 0 SUBID,MYID,20170307T153552.000001089,20170307,Failure
Line 1 ERROR,INT.META.001,Encrypted SHA does not match SHA in meta file.
@@ -1839,9 +1922,11 @@• Reject Record Index - if applicable, the 0-based byte index of the record in the Reject Report
• Firm ROEID - the value reported in the firmROEID field in the original Order Event if populated (otherwise blank)
The following is an example JSON object for a successful OrderEvents ingestion:
+CSV presentation:
Line 0 SUBID,MYID,20170307T153552.000001089,20170307,INGESTION,Success,21 4513134,0,0.1
The following is an example JSON object for an unsuccessful OrderEvents normalization:
+CSV presentation:
Line 0 SUBID,MYID,20170307T153552.000001089,20170307,INGESTION,Failure,21 4513132,2,MYID_20170307_OrderEvents_000002.rejects.pgp,0.1
Line 1 ERROR, OE.INGEST.014,Invalid value for TIF,123456,DESKP123456
@@ -1886,7 +1971,9 @@• origFileName:"MYID_20170307_OrderEvents_000130.json"(origFileNumber=000124)
Then metadata for this correction file must include "origFileNumber": [000123,000124]
For example:
+The repairs records in the correction file are organized in a record change list. The repairs should be grouped by original file number.
+In the CSV presentation, origFileNumber will be flattened into the first column of each line, and the repairRecords will be starting from the next columns. For the examples above, the CSV presentation will look like below.
Line 0 000123,DEL,456
Line 1 000123,DEL,5098
@@ -1904,7 +1991,8 @@• Record Type - DEL
• Original Record Index - the 0-based index of the record in the original file
The following is an example delete record:
- +pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Correction Record
@@ -1919,7 +2007,8 @@ • Original Record Index - the 0-based index of the record in the original file
• Replacement record - the corrected record
The following is an example correction record:
-pubdate: February 28, 2019 effdate: N/A
Topic: CAT Reporting Technical Specifications for Industry Members, Feedback and Corrections, Corrections, Submitter Created Repair File Structure, Repair File Sample
@@ -1928,6 +2017,7 @@ Please see a sample of a repair file in JSON below:
+CSV presentation:
Line 0 000123,DEL,456
Line 1 000123,DEL,457
@@ -1942,6 +2032,7 @@The rejectFile that can be accessed in downloads/failures will be pre-populated with Correction Records. Below is an example of the rejectFile:
+In the example above, two correction records are included and pre-populated with the original records as they were submitted. The submitter or reporter may simply modify the erroneous data elements, rename the file and submit it to CAT as the correction file.
Below is the CSV format presentation.
Line 0 COR,567,MENO,DESK98765,20170801T143031.123456,false,,,XYZ,O12345, N,O,,Buy,10.01,500,,LMT,DAY,REG,,false,PROP456,O,,,false, N,,,,,,,,,,,
@@ -2053,6 +2144,8 @@Representative Order Marking and Linkage Requirements by Phase
Single Order Scenarios
The table below details requirements for both linkage and marking of a Representative Order in Single Order scenarios. These requirements are NOT applicable in situations where an electronic link does not exist between the Industry Member's OMS and EMS. Please refer to Data Dictionary for relevant field values. Pease refer to the CAT Industry Member Reporting Scenarios document for further information on how the relevant field values should be populated for each scenario.
+Aggregated Order Scenarios
[Placeholder for Phase 2c. Aggregated Order Reporting will be finalized and included in future version of the specification.]
D. CAT Date Definitions and Reporting Guidelines
@@ -2064,26 +2157,61 @@• CAT Reporting Due By Date: All events that occurred by 4:15PM on one Trading Day must be reported by 8:00AM the following Trading Day.
Order Event Times and Reporting Deadlines
The table below illustrates the reporting deadlines for Order Events across multiple calendar days and CAT Trading Days.
+Order IDs must be unique within the same calendar date. In the table above, the orderID in row 1 and 2 are distinct since both orders have a calendar date of 9/12. The Trading Day is not used for determining orderID uniqueness, as illustrated in rows 5 and 6.
The Trading Day for Industry Members is defined as starting 1 millisecond after 4:15PM on one trade date and ending 4:15PM on the next trade date. As shown in rows 1 and 2, events with a timestamp after 4:15PM (row 2) are considered to be the following trading date and are not due until T+1 at 8:00AM. Alternatively, Industry Members may submit one file one file per calendar day (the orders on rows 1 and 2 can both be submitted on a 9/12 file). The Trading Day only exists to determine the reporting deadline of an event, it does not impact the date used to create linkage or the file name.
Weekends are excluded from Trading Days. Events from 4:15PM on a Friday to 4:15PM the follow Monday are the same Trading day, but files must be separated by the calendar date (see rows 4, 5, and 6).
Holidays are also excluded from Trading Days. Hypothetically, if Monday 9/17 were are holiday in the example, the next available Trading Day becomes Tuesday 9/18.
+E. Failure Codes11
The failure code is a machine-parseable string of why a file or record was rejected.
Each failure code is divided into a failure category, sub-category and value, joined together by a period.
<category>.<sub-category>.<value>
• Category and sub-category are defined as the table below. Each category corresponds to the stage of processing at which a file or record was rejected.
• Value will be an alphanumeric (12) code that represents a specific error or warning. The list of values will be refined and a complete list of codes and descriptions will be provided.
+A failure code may be used for warnings or errors, distinguished by the severity field in the failure report. The failure code itself does not distinguish between a warning (in which a record is accepted but still shows up in the feedback report) and an error (which causes a record to be rejected).
A failure description is a human readable field returned with a failure code that informs a user which field failed, the value which was submitted (if applicable to the error), and why it is incorrect. The failure descriptions are specific to the type of field that has a failure and the original value used by the reporter.
For example, the following failure code tells the user the severity is an error, the failure was identified on an Order Event file during the ingestion stage, and the field originalOrderID is missing from the record.
+The following failure code example was also identified on an Order Event file during the ingestion stage. The description informs the user that the value submitted is invalid as it was more than 40 characters in length.
+Below is a sample of Failure Codes/Descriptions.
Not that this is not the final list nor a complete list. The code values will be refined to lower granularities.
+F. Glossary
G. Data Dictionary
-fn |
1 Customers are defined in SEC Rule 613(j)(3) as: (i) the account holder(s) of the account at a registered broker-dealer originating the order; and (ii) any person from whom the broker-dealer is authorized to accept trading instructions for such account, if different from the account holder(s). |
As discussed above, the Participants do not believe that it is necessary or appropriate to amend the Business Clock synchronization requirements set forth in the Plan at this time. The Participants will reassess whether the Business Clock synchronization requirements remain consistent with industry standards – or whether it may be necessary to amend such requirements – in the future as part of the annual assessment required by Section 6.8(c) of the Plan. To make such an assessment, the Participants intend to continue working with the Advisory Committee and the industry generally, including CAT Reporters of various sizes and types, to determine whether current Business Clock synchronization practices have changed sufficiently to suggest that narrower synchronization thresholds may be consistent with industry standards. As the Commission noted when it approved the Plan, if the Participants determine based on a future assessment that the clock synchronization requirements in the Plan should be changed, the Participants would need to file a proposed amendment to the Plan with the Commission. Such a submission would enable the Commission, as well as Industry Members and the public, to evaluate the proposed requirements, including anticipated costs, benefits and related implementation time frames.
- +fn |
1 The CAT NMS Plan is a national market system plan approved by the Commission pursuant to Section 11A of the Exchange Act and the rules and regulations thereunder. See Securities Exchange Act Release No. 79318 (Nov. 15, 2016), 81 Fed. Reg. 84696 (Nov. 23, 2016) (the “Adopting Release”). The full text of the CAT NMS Plan is available at www.catnmsplan.com. diff --git a/spider/files/data000005.html b/spider/files/data000005.html index e3c6391..19ef05e 100644 --- a/spider/files/data000005.html +++ b/spider/files/data000005.html @@ -30,6 +30,7 @@CAT NMS Plan Potential ExpansionJuly 19, 2017 Page2 Thank you for your attention to this matter. Please contact me at 212-229-2455 if you have any questions or comments. +![]() cc (via email): The Hon. Jay Clayton, Chairman The Hon. Michael S. Piwowar, Commissioner The Hon. Kara M. Stein, Commissioner @@ -120,14 +121,20 @@2. Debt Markets v. Equity MarketsThe U.S. debt markets and equity markets are vastly different in most material respects. As noted above, the markets vary significantly in types of issuers, issue characteristics, trading, and regulatory regimes such as the level of market transparency on both a pre- and post-trade basis. All of these differences would influence how expanding the CAT to include reporting for debt securities could be efficiently and effectively achieved. Below, we describe some of the key characteristics of the government and corporate debt markets. First, the U.S. debt market is significantly larger than the equities market in terms of both the number of outstanding securities and the amount of capital raised; however, the size of the U.S. debt market is heavily influenced by U.S. Treasury securities.19 Second, there are significantly more issuances of debt securities as compared with equity securities. Many public companies may have only one class of stock, but can issue numerous types of bonds with different yields, maturities, and denominations.20 For example General Electric has only one class of stock, but it has issued over 1,000 unique bonds.21 In addition, daily trading volumes are significantly different for equities than for debt, with the number of trades in equity securities far surpassing trades in debt securities. The following charts highlight some of the more significant differences between the debt markets and the equity markets. Chart 1 compares the monthly value of new issue corporate bonds and public corporate stocks in the United States from January 2015 to January 2017.22 +![]() Chart 2 demonstrates the number of issues in the U.S. debt and equities markets by charting the number of unique CUSIPs reportable to a FINRA facility as of the beginning of the calendar year for each of the last five years.23 As the chart makes clear, there are significantly more CUSIPs for debt securities than for equity securities.24 +![]() Chart 3 displays the average daily trading volume for U.S. corporate debt, all TRACE reported debt, and exchange-listed equity securities for each month from January 2016 to March 2017.25 As the chart makes clear, in any given month the trading volume on equities exchanges is generally over five times that in U.S. corporate debt. However, when compared with all TRACE reported debt, the notional volume of transactions in U.S. debt and exchange-listed equity securities is relatively similar due to the high notional volume of transactions in Agency MBSs. +![]() Chart 4 shows the combined equity trades on exchanges compared to the TRACE reported trades during each quarter of 2016.26 Despite the fact that there are substantially more bonds in the market and more new bond issuances, the volume of equity trades is higher, and there are significantly more equity transactions on a daily basis than bond transactions. While exchanges had in excess of 1.5 billion trades each quarter, with one quarter over 2.5 billion, TRACE averages only 4.5 million reported trades per quarter. +![]() Another major difference between the bond and equity markets is the size of the trades. The dollar value of bond transactions typically is greater than stock transactions. The average size of a bond trade exceeds $500,000 whereas the average stock trade is less than $10,000.27 These large transaction sizes are the result of a substantial portion of transactions by institutional investors in the debt markets as compared to the equity markets.28 Chart 5 uses Federal Reserve financial sector data to chart retail investors in different bond types. Chart 5: Presence of Retail Investors in the Bond Market29 +![]() In general, the debt markets have a much higher proportion of institutional market participants than in the equity markets, in which retail investor participation is substantially higher.30 However, for purposes of Chart 5, institutional investors include mutual funds, pension funds, insurance companies, and endowments. When these forms of indirect ownership are factored in, 49% of U.S. households are invested in bonds.31 Two other major differences between the debt and equity markets are related. Due to the vast number and variety of debt securities outstanding, most individual debt securities trade much less often than a typical stock, particularly listed stocks. For an equity security that is listed on an exchange, there is an active market for the stock, and, consequently, it is easy to obtain a current price for any particular listed stock. However, bonds and other debt securities tend to actively trade during the period after their initial issue, but, thereafter, trading in a particular debt security may not occur for months or even years. Chart 6: Trading Volume Reduction in Corporate Debt 90 Days After Issuance32 +![]() Because of the relative lack of liquidity in the debt markets compared to the equity markets, there is significantly less pre-trade price transparency for most debt securities compared to equity securities. In addition, because of the relative lack of trading activity in the debt markets compared to the equity markets, it is significantly less difficult to link specific orders in debt securities to resultant trades. For example, an order in an equity security may be split into numerous child orders (or numerous orders can be aggregated into a larger order). By requiring that the parent order and each child order be linked, the equity order audit trail provides insight into these relationships that otherwise would be difficult to ascertain. Along with these fundamental differences in the character of equity versus debt securities, the manner in which orders are handled in the two markets—and even what constitutes an “order”—and how trades are executed, differ substantially. In the debt market, it is common for an investor to contact his or her broker to purchase a bond with certain characteristics (e.g., a specific yield, credit rating or maturity) rather than a particular security, and the broker will reach out to other bond brokers and assess what debt securities that meet those criteria are available. Based on this information, the broker generally provides the investor with options, and the investor can choose a particular debt security to purchase when presented with the options. FINRA requires its members to submit trade reports to TRACE and disseminates some of this information; however, this information is limited to post-trade transparency and is subject to other limitations, such as volume thresholds. By contrast, exchanged-listed stocks always have pre-trade bid and offer prices available, often on multiple trading centers. Finally, unlike most equity securities, most debt securities are traded over-the counter (“OTC”) rather than on an exchange. In 2017, approximately 10,000 of the approximately 61,500 corporate bonds outstanding–approximately 16% were reportable to NYSE’s bond trading platform, which is the largest centralized corporate bond exchange in the U.S..33 The vast majority of transactions in debt securities are executed through informal networks of bond dealers in the OTC market. Further, while there has been significant growth in electronic trading venues for bonds in recent years—the number of corporate bond transactions occurring on ATSs has grown to approximately 20%—much of the activity in this space occurs as a Request for Quote (“RFQ”) or similar format where the terms of a trade are negotiated bilaterally.34 @@ -314,6 +321,7 @@1. Originating Firm New Order Report; Execution Reports (Approach #1)Report Fields,Under Approach #1, originating firms would report the receipt of a new order from a customer (i.e., when an order for a CUSIP/specific security is received), including a customer identifier that would be linkable to a separate database containing the relevant personally identifiable information (“PII”), similar to the CAT framework.57 If a transaction is fully or partially executed, the originating firm would enter an execution report that is linked to its new order report in the audit trail. Likewise, if the order was cancelled in whole or in part, the cancellation would be included in the audit trail, and would be linked to the originating firm’s new order report. The execution report also would include an identifier that would link it to the related TRACE transaction report. The Participants do not assume any changes to current transaction reporting frameworks. Where no customer order is involved, no audit trail requirement would be required as data would be available from the transaction report. +![]() Approach #1 - Example The below relates to the sell order scenario depicted above. Relevant order audit trail reports under this approach are underlined. Note that the events used in the example are illustrative and that alternatives, such as indications of interest, requests for quotes, non-firm quotes and negotiated trades, may also be used as examples. • 12:10pm – Firm A creates New Order ID #1234 – New Order Report @@ -356,6 +364,7 @@3. Complete, Linked, Order through Execution Life Cycle (Approach #3)The Participants understand that this process is common in the debt area and, therefore, initially considered whether an audit trail might begin with recording and reporting certain pre-order information obtained by the firm in advance of the entry of an order for a particular security. For example, an approach might be considered where, if a customer provides a minimum number of descriptive elements regarding a debt security — e.g., where a customer provides several of the following: investment dollar amount; issuer; sector; yield; coupon; maturity; rating; or specified additional features — a firm conceivably might be required to submit a pre-order report. Any securities presented by the firm to the customer as satisfying the customer’s criteria also could be entered into a pre-order report and, should an order result, the pre-order report could be linked to the new order report (which would be followed by route, execution or cancellation reports, as applicable). This type of framework would be an attempt to capture in an automated fashion the pre-order events that are likely to be extensive in the debt markets. However, the Participants haven’t included the concept of a pre-order report in Approach #3 due to the possibly numerous manual steps likely necessary to submit and amend such a report to account for each debt security being explored. Under Approach #3, firms (both originating firms and route recipients) would report the receipt of a new order, though only originating firms would be required to report a customer identifier that would be linkable to a separate database containing the relevant PII. As noted above, although typically the order itself is not being truly routed to multiple firms (the originating firm is contacting a dealer or market center for indications of interest in the particular bond), this approach would require new order reports from all receiving firms and any associated executions or cancellations. Where a firm sends an order to another firm, a route report would be added to the audit trail by the sender (linked to the related new order report). If an order is fully or partially executed, any firm with a new order report related to the execution would enter an execution report that is linked to its new order report in the audit trail. The execution report also would include an identifier that would link it to the related transaction report. Likewise, if the order was cancelled in whole or in part, any firm with a new order report related to the cancellation also would report the cancellation. Approach #3 - Example +![]() The below relates to the sell order scenario depicted above. Relevant audit trail reports under this approach are underlined. Note that the events used in the example are illustrative and that alternatives, such as indications of interest, requests for quotes, non-firm quotes and negotiated trades, may also be used as examples. • 12:10pm – Firm A creates a new order and assigns Internal Order ID #1234, a reportable event by Firm A – New Order Report • 12:15pm, 12:16pm and 12:17pm, Firm A sends Sub-Orders #12341, #12342 and #12343 to Firm B, ATS #1 and ATS #2, respectively. Reportable events by Firm A – Route Reports diff --git a/spider/files/data000007.html b/spider/files/data000007.html index 5ba79d1..cf3e79d 100644 --- a/spider/files/data000007.html +++ b/spider/files/data000007.html @@ -35,8 +35,10 @@Executive SummaryThis document provides Participants with information to understand their responsibilities to comply with SEC Rule 613 and CAT NMS Plan, and describes the requirements for reporting data to CAT, including detailed information about data elements and file formats of each reportable event. It also describes how Participants should submit files to CAT, including access instructions, network and transport options, and testing requirements. This document does not include information for Industry Members. A separate document, CAT Reporting Technical Specifications for Industry Members, will be published to provide technical specifications for Industry Members. Contents and Structure +![]() Revision / Change Process - +![]() pubdate: September 09, 2018 effdate: N/A
1. IntroductionTopic: CAT Participant Technical Specifications v1.7.1, Introduction
@@ -123,6 +125,7 @@ 1.3. CAT IdentifiersCAT Reporter ID,CAT uses a number of identifiers, many of which readily convey their meaning from the context in which they are used. The subsections below include terms associated with the entities that will report data into the CAT and their respective roles. As shown in the diagram below, Exchange ID is a subset of Participant ID, which is a subset of Reporter ID. +![]() pubdate: September 09, 2018 effdate: N/A
1.3.1. Reporter IDTopic: CAT Participant Technical Specifications v1.7.1, Introduction, CAT Identifiers, Reporter ID
@@ -206,6 +209,8 @@ 1.5. Fundamental Data TypesA schema will be provided for each data object that can be reported in both JSON and CSV. When a data field is marked as either optional or conditional, some records may not provide values for that field. In such a case, the field is simply not reported as part of the JSON record, or reported as an empty column of a CSV record. Data Types +![]() ![]() pubdate: September 09, 2018 effdate: N/A
1.5.1. Data ValidationTopic: CAT Participant Technical Specifications v1.7.1, Introduction, Fundamental Data Types, Data Validation
@@ -243,6 +248,8 @@ 2.1. Member InformationEach member may have multiple aliases, but a specific Member Alias may only be assigned once per SRO. Note that the member dictionary is loaded each day, and the values only apply to that trading day. Thus, Member Aliases could be reassigned on subsequent trading days. The data will be uploaded as a file of newline-delimited JSON objects, one object per member entry. The member dictionary is necessary to process other file uploads, and must be uploaded to CAT no later than 6:00AM Eastern, with entries sufficient to support all reports submitted on that trading day (this is a same-day upload requirement whereas order events are required to be reported by 8:00AM Eastern the following trading day). Member Dictionary Entry +![]() ![]() The Inactive status can be used if a Participant wants to report a member who may have been temporarily deactivated. If a member is removed, the member may be reported as Inactive or may be not reported at all. The following example shows a potential member dictionary for exchange Exch1 where the first entry represents an industry member that is also a member of the reporting SRO, the second entry represents an industry member that is not a member of the reporting SRO, and the third entry represents the SRO itself, with various facilities that have been given Member Alias values. { @@ -304,6 +311,7 @@2.2.1. Adding a New IssueTo add a new issue, an Add Symbol Entry record is submitted. Note that this record is for adding a brand new symbol only - one that has never existed in the CAT system. Add Symbol Entry +![]() This record type is to be submitted when a symbol is assigned to a brand new issue for the very first time. The symbol must not be assigned to any other participant in the beginDate, endDate range. The symbol will be brand new, and will be assigned a new and unique internal CAT Symbol ID. It will not be linked to any other symbol. Once a symbol has been added to the database, it cannot be removed via the API. A request must be made to the CAT support desk to perform such an operation. Even then, a symbol will only be removed if it was a clear error, and the symbol was never activated. 2.2.2. Restating an IssueAn existing symbol can be restated, providing an explicit check that the exchange and CAT have the same information for the symbol. This is accomplished by submitting a Symbol Master Restatement. The fields for a restatement are identical to those for an add. However, it makes explicit the understanding that the symbol is expected to already be present in the system. The values presented in the restatement must exactly match what is in the CAT database, or the record will be rejected. Symbol Master Restatement -![]() pubdate: September 09, 2018 effdate: N/A
2.2.3. Updating an IssueTopic: CAT Participant Technical Specifications v1.7.1, Reference Data, Equity Symbols, Updating an Issue
@@ -331,6 +340,7 @@ 2.2.3. Updating an IssueAn issue is updated when any field of an existing issue needs to be changed. Two Symbol Entry objects are passed. The first represents the expected current state of the symbol entry before being updated, and the second represents the new values for the fields that will be updated. The current state of the database must match the expected symbol entry or the update request will be rejected (when comparing name value pairs, the order in which the name/values appear is not considered). If successful, the database will be changed to reflect the updates requested, and the response will contain a complete updated entry. Update Symbol Entry +![]() The SRO requesting the update must be the current "owner" (i.e., listing participant) of the symbol. All updates are kept, and the history of updates can be queried for a given CAT Symbol ID or a symbol name. Note that an update request will not allow the listing participant to be changed. To change the listing participant of a symbol, submit a Symbol Master Transfer record. pubdate: September 09, 2018 effdate: N/A
@@ -342,6 +352,7 @@ 2.2.4. Transferring an IssueTo transfer an existing issue from one listing participant to another, the new ownership participant must submit a Symbol Master Transfer request. The request will be validated for data accuracy, and once validated, a transfer will be scheduled inside the system. Symbol Master Transfer +![]() Transfer requests should be submitted prior to the effectiveDate, in which case the transfer will be scheduled for the night before the effectiveDate. If the effectiveDate is the same date as the record submission, then the request will be applied immediately instead of being scheduled. This use pattern may be necessary at times, but is discouraged as it does not leave much time for review of the changes by all parties and opens a potential race condition window. Current owners are encouraged to release the symbol prior to transfer by submitting an Update Symbol Entry record (USE), and setting the endDate to be the last day they are responsible for the issue. This is especially important if there may be a gap between the time the symbol is delisted and resisted by another exchange. If the current owner has not submitted an update to their endDate when the transfer is applied, then the current owner's endDate will be automatically updated to be one day prior to the effectiveDate in the transfer request. @@ -482,6 +493,7 @@2.2.8. Daily Symbol DictionaryFor example, assume an exchange receives an order for a symbol in the symbology ABC.B, and then routes it to an away exchange, but the away exchange requires the symbol to be represented as ABC B. This exchange would have to process its routing logs to convert each use of ABC B to ABC.B. However, if it loaded a symbol dictionary with a set of aliases, then it could report events with both ABC.B and ABC B and CAT would determine that they meant the same thing. Note that the symbol dictionary is completely optional. If each symbol will be reported in all events in its native symbology, then the reporter would not need to upload a symbol dictionary. Symbol Dictionary Entry +![]() In the following example, the reporter (MYID)has three internal mappings for the symbol FOO.A: an internal symbol number (345), and two different symbology values (FOO/A and "FOO A"). { "type": "SDE", @@ -517,6 +529,7 @@2.2.9.1. Option Series Dictionary EntryThe dictionary mapping for an option series (flex or simple) will contain the following information, which allows options events to be reported using the Option ID reported in the dictionary entry. Simple Option Series Dictionary Entries +![]() For example, the following dictionary entry would be for the January 19, 2018 150.0 Put for BRK class B. Note that the primary deliverable is reported in NYSE symbology because BRK.B is listed on NYSE. { "type": "OSDE", @@ -634,6 +647,8 @@2.2.9.2. Option Symbol Changes"settlement": "PM" } The pre- and post-Spinoff JSON Dictionary Entries shown above are also shown in table format below. +![]() ![]() A final example demonstrates the impact of the third corporate action event – the stock split on November 1, 2018. On November 1, 2018 ABCD undergoes a 3 for 2 stock split. Option contracts in ABCD and ABCD1 are affected. Contracts in ABCD become ABCD2 delivering 150 shares of underlying stock ABCD. Option symbol ABCD2 = 150 ABCD. Contracts in ABCD1 remain ABCD1 and deliver 150 shares ABCD and 10 shares EFGH. Option symbol ABCD1 = 150 ABCD + 10 EFGH. The exchange will again list a new ABCD delivering 100 shares of ABCD stock upon exercise. Before 3:2 Stock Split -- ABCD delivers 100 shares of ABCD. ABCD1 options deliver 100 shares of ABCD + 10 shares EFGH. @@ -718,6 +733,7 @@2.2.9.3. Complex Option Dictionary EntryThe dictionary mapping for a complex option will contain the following information. Each complex option can contain multiple legs, where each leg is either an option leg or a stock leg (stock leg will generically refer to equity/exchange-traded fund "ETF"). Complex Option Dictionary Entries +![]() The Option ID must be unique. Duplicate dictionary entries are ignored. Entries that have the same Option ID, but different details are rejected. Any entry which defines the opposite side of an existing entry will be rejected. For example, a complex option dictionary entry to Buy one (1) contract of option 1234 and Sell two (2) contracts of option 4321 is considered to be the "opposite side" of an entry to Sell one (1) contract of option 1234 and Buy two (2) contracts of 4321. Thus, if both were submitted the second would be rejected. JSON Example { @@ -875,7 +891,8 @@3.4. Order Linkage and LifecycleThe Routing Party is a text string that the exchange has assigned to the firm routing the order. Complexity arises when a member is assigned multiple values by the exchange. The determination as to which value is used by both parties depends on protocol-specific information. The text string can be a Member Alias, but there is no restriction that it must be a Member Alias. It can be any string, so long as both the sender of the order and the exchange agree on using the same string for their orders. The Session ID is also exchange-assigned, usually a unique login account, an actual protocol session name, IP/port combination, or some other means of identifying a particular API session. The Session ID identifies the specific session used to route the order. Even in cases where there is only one session in use between reporters, the same non-empty value must be reported in the session field by both parties. CAT, in cooperation with each exchange, will determine how the Routing Party, Routed Order ID, and Session ID are derived for each API supported by the exchange. This guidance will be documented and published on the CAT website. -![]() pubdate: September 09, 2018 effdate: N/A
3.5. Material Terms of an OrderTopic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Material Terms of an Order
@@ -929,7 +946,8 @@ 3.6. Optional, Required, and Conditional FieldsConditional,Subsequent sections describe event types and their fields. Each field will be notated with the abbreviation R, O, C, or r to represent whether it is required, optional, conditional, or required conditionally. This codification will be present in the last column of each table describing an event. -![]() pubdate: September 09, 2018 effdate: N/A
3.7. Common EventsTopic: CAT Participant Technical Specifications v1.7.1, Special Data Elements and Common Events, Common Events
@@ -971,6 +989,7 @@ 3.7.2. Self-Help Declarations“Self-help” declarations allow market participants to disregard the protected quotations of trading centers that are experiencing systems problems such as failure, material delay, or malfunction. Participants must report to CAT any self-help declarations they make. If a self-help declaration is carried over to the next day, it must be reported again on that day. The following data is required to be reported for Self-Help declarations: Self-Help Declaration +![]() Both the declared and revoked timestamps can be reported in one single event by including both declaredTimestamp and revokedTimestamp. Alternatively, the declaration and revocation can be reported independently by just including the relevant timestamp in separate events. pubdate: September 09, 2018 effdate: N/A
@@ -986,6 +1005,7 @@ 3.7.3. Supplemental Trade EventThis event is used for stock and option trades. If the trade references a stock, then the symbol field must be provided. If the trade references an option, then the optionID field must be provided. The description uses "trade" in a general manner. If the event references a trade, the tradeID field is required. If the event references a fill, the fillID and side are required. Supplemental Trade Event +![]() Lifecycle keys for this event: • Trade Key: date, exchange, symbol, tradeID • Trade Key: date, exchange, optionID, tradeID @@ -1018,6 +1038,7 @@4.1. Order Accepted EventNote that for the order accepted event, the firm that sends the order to the exchange will be referred to as the routing firm. In the next event, order route event (section 4.2), the routing broker dealer will also be referred to as the routing firm. The Order ID that is used in orders must be globally unique when combined with the date, exchange, symbol and general side, where the general side is either Buy or Sell. Order Accepted +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Route Link Key: date, symbol, routingParty, routedOrderID, session, exchange @@ -1037,6 +1058,7 @@4.2. Order Route EventThe Routing Firm must be represented by an entry in the exchange's member dictionary (though not necessarily a member of the exchange). Furthermore, as explained in the linkage section, both the exchange and the Routing Firm must know which Member Alias is to be reported to CAT because both will have to report the same Member Alias (the exchange in their Route event, and the firm in their Accepted event). Either both sides must use a constant value, or there must be some way to derive the value being used (via session configurations or in the message itself). If the exchange creates a derived order, and passes that order ID to the firm via its API, then the Routed Order ID will be the order ID of the derived order. If, however, there is no derived order and the exchange passes its own internal order ID to the routing broker, then the internal order ID will also be assigned as the Routed Order ID. In this case, both the order ID and the routed order ID are populated with the same value. Order Route +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty @@ -1051,6 +1073,7 @@4.3. Internal Order Route EventIn some cases, an exchange may have multiple internal subsystems involved in handling orders. In such cases, and order may be accepted by one internal system, and then routed to one or more internal systems for processing. Routes within an exchange are not required to be reported to CAT. However, there are cases where it is difficult for an exchange to report the entire status of an order to CAT when its internal processing is handled on multiple systems. Specifically, ensuring that the events contain the same order identifiers would require substantial post processing. Thus, an internal route event may be reported to CAT, indicating that an order is being passed from one internal system to another. This will allow CAT to link events that are related to the same order within an exchange, even if the exchange has changed the identifiers on the order as it moves between internal systems. Internal Order Route +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty @@ -1067,6 +1090,7 @@4.4. Order Modified EventSome times, during the course of an order modification, a new internal order is generated (with a new order ID) and completely replaces the previous order (though the new order will be linked to the original order). Both of these cases are handled by the Order Modified event. If the order ID remains the same, then the Original Order ID field will be the same. If the order ID changes, then the Order ID field will contain the new internal ID of the order, and the Original Order ID will contain internal ID of the order prior to being replaced. When a modification is reported, the full state of the order is reported, including those fields which have not changed. Order Modified +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Previous Order Key: date, exchange, symbol, originalOrderID @@ -1087,6 +1111,7 @@4.5. Order Adjusted EventIf either the displayPrice or the displayQty change, they both need to be reported. The only exception is if the displayQty changes from non-zero to zero. In such a case, the displayQty would be reported, but the displayPrice would not be reported since there is no display quantity. This event is meant to capture the most common simple adjustments to orders (e.g., reduction in shares, short-to-long sell, price-only changes). Any modification that cannot be fully represented in this event must be reported via the Order Modified event. Order Adjusted +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Previous Order Key: date, exchange, symbol, originalOrderID @@ -1103,6 +1128,7 @@4.6. Order Canceled EventA Canceled event should be used anytime any part of an order is cancelled. For example, an order can be partially reduced either with a cancel message or a modify (cancel/replace) message. If an actual cancel is processed by the exchange, a Canceled event would be reported. If a modify and/or cancel/replace was sent to the exchange, a Modified event would be reported. This keeps the reported event in line with the original intent. Some protocols only allow full cancels; partial cancels must be accomplished via a cancel/ replace. In such cases, partial cancels would always be reported as Modified events. Order Canceled +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID 4.7. Order Trade EventAll trade events are reported to CAT as two-sided transactions, with a single event. Each order trade event is represented with the following details. The details in the table Order Trade Side Details must be populated for each side of the trade. Order Trade Event +![]() Order Trade Side Details +![]() ![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, buyDetails.orderID • Order Key: date, exchange, symbol, sellDetails.orderID @@ -1135,6 +1164,7 @@4.8. Order Fill EventWhen a routed order executes, the routing firm acquires the position. The exchange will report the fill with the order on one side, and the routing firm on the other side. Order Fill Event +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Fill Key: date, exchange, symbol, fillID @@ -1155,6 +1185,7 @@4.9. Bulk Print EventEach batch execution needs an identifier (bulkPrintID) which is unique for that set of executions, by date, reporter, and symbol. An event will be reported to CAT for every order that participated in the batch execution. For example, if the opening cross matched 1,000,000 shares of symbol ABCD across 5,000 buy orders and 4,000 sell orders, then there would be 9,000 Bulk Print Event reports sent to CAT for that cross. Each event would contain the same bulkPrintID, which would uniquely identify that particular cross event. The total of all buy-orders execution quantities should be equal to the total total of all sell-orders execution quantities (in this example, 1,000,000 shares). Bulk Print Event +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID @@ -1170,6 +1201,7 @@4.10. Order Cancel Route EventWhen an exchange initiates a cancel request on an order it has previously routed away, it must report its intent to cancel, using a Cancel Route Event. Order Cancel Route +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty @@ -1185,6 +1217,7 @@4.11. Order Modify Route EventWhen an exchange initiates a modify or cancel/replace request on an order it has previously routed away, it must report its intent to modify the order, using a Modify Route Event. If the request does not change the routed order ID, then both routedOrderID and routedOriginalOrderID must be the same. Modify Route +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Route Link Key: date, symbol, exchange, routedOrderID, session, routingParty @@ -1202,6 +1235,7 @@4.12. Order Restatement EventOrders that persist across business days (e.g., GTC orders) must be restated each day before any other activity is reported for that symbol. The restatement is an explicit confirmation that the order is still active in the reporter’s order book, and also provides an opportunity to use per-day unique order IDs for all orders. The attributes of the order will be restated in terms of the order's current state, after any corporate actions have been processed (e.g., if a 2:1 split occurred, the quantity and price would reflect the resulting change). Order Restatement +![]() Lifecycle keys for this event: • Order Key: date, exchange, symbol, orderID • Previous Order Key: originalOrderDate, exchange, symbol, originalOrderID @@ -1216,6 +1250,7 @@4.13. Trade Break EventWhen a trade is broken, an event is reported to CAT with the appropriate information. Note that CAT adds the event to the history of the order. The broken trade is not removed from the history, as it is something that actually happened and should be recorded. Order Trade Break +![]() Lifecycle keys for this event: • Trade Key: tradeDate, exchange, symbol, tradeID @@ -1247,7 +1282,8 @@4.15. Lifecycle KeysThe lifecycle keys for each event are summarized in the following table. Lifecycle Keys for Equity Events - +![]() pubdate: September 09, 2018 effdate: N/A
5. Events for Options Exchanges@@ -1259,6 +1295,7 @@5. Events for Options ExchangesThese events are specific for options exchanges. Events for Options Exchanges +![]() pubdate: September 09, 2018 effdate: N/A
5.1. Market Maker QuotesTopic: CAT Participant Technical Specifications v1.7.1, Events for Options Exchanges, Market Maker Quotes
@@ -1282,6 +1319,7 @@ 5.1. Market Maker QuotesNote that all pre-open quotes are still reportable to CAT. This exception is explicitly for those cases where the exchange allows quotes to be sent before they are officially accepted - but those quotes are neither processed, nor entered into the book, nor accepted for participating in the opening nor any other trading session. Once the system has started accepting quotes (either because a set time has arrived, or it has sent out a message indicating that quotes are now being accepted), then all quotes must be reported. CAT does not have rules in place for when exchanges start accepting quotes, but it seems that all exchanges start accepting quotes at least five minutes before the start of trading. For example, in the following diagram, an exchange ignores quotes until they send their "Now Accepting Quotes" message. Thereafter all quotes are processed and reported to CAT. +![]() Similarly, if a quote is rejected and neither accepted nor booked, then the quote should not be reported to CAT. pubdate: September 09, 2018 effdate: N/A
5.1.1. Quote Event@@ -1295,6 +1333,7 @@5.1.1. Quote EventThe following data elements are to be reported with all quote events. For two-sided quotes, all bid/ask/price/qty values are required. For one-sided quotes, both the price and quantity fields are required, but only for one side. Quote Events +![]() Lifecycle keys for this event: • Quote Key: date, exchange, optionID, quoteID • Previous Quote Key: date, exchange, optionID, originalQuoteID @@ -1309,6 +1348,7 @@5.1.2. Quote Cancel EventThe following data elements are required for cancel quote events. Quote Cancel Event +![]() Lifecycle keys for this event: • Quote Key: date, exchange, optionID, quoteID 5.2.1. Order Accepted EventsA simple option order can represent either a stand-alone option series, or one leg of a complex parent order. If the order represents a leg of a complex order, then the field Complex Order ID will be set to the Order ID of the parent complex order. If necessary, the event timestamp and sequence number could be the same as those in the parent complex order. Fields marked with a lower-case 'r' are required if the event represents a normal option order, and they are conditional if the event represents a leg of a complex order. Simple Option Order Accepted Event +![]() Lifecycle keys for this event: • Order Key: date, exchange, optionID, orderID • Route Link Key: date, optionID, routingParty, routedOrderID, session, exchange @@ -1350,6 +1391,8 @@5.2.1. Order Accepted EventsNote that the following fields are conditional in this event. If they are present, then they do not have to appear in the individual order events for option legs, unless the value for a leg would be different from the value in the complex order. In other words, these field values apply to all option legs, unless the option leg contains a different value. If these fields are missing, then the data must be present in each option leg. coverage, exchOriginCode, executingFirm, cmtaFirm, mktMkrSubAccount Complex Option Order Accepted Event +![]() ![]() Lifecycle keys for this event: • Order Key: date, exchange, optionID, orderID (if not isGloballyUnique) Order Key: date, exchange, orderID (if isGloballyUnique) @@ -1614,6 +1657,7 @@5.5. Options Trade Correction EventIf a trade is corrected in any way, a correction event must be reported to CAT with all details of the trade, after having been corrected. This event must capture the entire state of the trade after having been corrected. As with trade breaks, CAT will still keep the original trade, adding the correction to the audit trail of the trade being corrected. Options Trade Correction +![]() Lifecycle keys for this event: • Order Key: date, exchange, optionID, buyDetails.orderID • Order Key: date, exchange, optionID, sellDetails.orderID @@ -1632,7 +1676,10 @@5.6. Lifecycle KeysThe lifecycle keys for each event are summarized in the following table. Lifecycle Keys for Option Events -![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
6. Other Reporting@@ -1661,7 +1708,9 @@6.2. FINRA Reporting of OTCBB Quote DataOTC Bulletin Board quote data must be reported to the CAT by FINRA as a CSV with the following fields: OTC BB Quote Elements -![]() ![]() pubdate: September 09, 2018 effdate: N/A
6.3. FINRA Reporting of Halt/Resume DataTopic: CAT Participant Technical Specifications v1.7.1, Other Reporting, FINRA Reporting of Halt/Resume Data
@@ -1671,7 +1720,9 @@ 6.3. FINRA Reporting of Halt/Resume DataHalt/resume data must be reported to the CAT by FINRA as a CSV with the following fields: FINRA Halt/Resume -![]() ![]() pubdate: September 09, 2018 effdate: N/A
7. Stock Exchange Event Examples@@ -1689,7 +1740,11 @@7.1. Order Event ExamplesModified Event,This section will illustrate examples for an order accepted event, an order modified event, and an order canceled event using the following scenario: A new order is routed to the exchange, accepted by the exchange, updated by the firm that sent the order, and is finally canceled by the exchange. -![]() ![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
7.1.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Stock Exchange Event Examples, JSON Examples
@@ -1698,9 +1753,12 @@ 7.1.1. JSON ExamplesJSON Examples,Order Accepted Event +![]() Order Modified Event +![]() Order Canceled Event -![]() pubdate: September 09, 2018 effdate: N/A
7.2. Order Trade Event Example@@ -1713,6 +1771,10 @@7.2. Order Trade Event ExampleIn this scenario, the exchange is required to report the following events to CAT: 1) Order Accepted Events from each of the orders; and 2) The order trade event +![]() ![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
7.2.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, JSON Examples
@@ -1721,9 +1783,12 @@ 7.2.1. JSON ExamplesJSON Examples,Order Accepted Event: Sell +![]() Order Accepted Event: Buy +![]() Order Trade Event -![]() pubdate: September 09, 2018 effdate: N/A
7.3. Order Route and Order Fill Event ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Route and Order Fill Event Examples
@@ -1740,11 +1805,18 @@ 7.3. Order Route and Order Fill Event Examples1) Order Accepted Event of the original order, 2) The Order Route Event, and 3) The Order Fill Event. +![]() ![]() ![]() ![]() JSON Examples Order Accepted Event +![]() Order Route Event +![]() Order Fill Event -![]() pubdate: September 09, 2018 effdate: N/A
7.4. Order Restatement ExampleTopic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Restatement Example
@@ -1753,6 +1825,9 @@ 7.4. Order Restatement ExampleRestated Event,This series of examples shows a restatement of a GTC order before market open the following day. Also it is assumed that a stock split on the symbol ABCD has taken effect, and that this is reflected in the restatement. +![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
7.4.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Restatement Example, JSON Examples
@@ -1761,8 +1836,10 @@ 7.4.1. JSON ExamplesJSON Examples,Order Accepted Event +![]() Order Restatement Event -![]() pubdate: September 09, 2018 effdate: N/A
7.5. Order Modified Example@@ -1772,6 +1849,9 @@7.5. Order Modified ExampleModified Event,This section will show how an order modified event is reported when the order type is changed by the initiating member firm from a limit order to a market order. This series of events will follow the submission of a limit order from a member firm to the exchange, that is subsequently modified by the member firm. +![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
7.5.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Modified Example, JSON Examples
@@ -1780,8 +1860,10 @@ 7.5.1. JSON ExamplesJSON Examples,Order Accepted Event +![]() Order Modified Event -![]() pubdate: September 09, 2018 effdate: N/A
7.6. Order Adjusted Example@@ -1791,6 +1873,9 @@7.6. Order Adjusted ExampleOrder Adjusted Example,This section will show how an order adjusted event is reported when a change in the NBBO causes the working price of an order to change. This series of events will follow the route of a peg order followed by an adjustment of the price. +![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
7.6.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Order Trade Event Example, Order Adjusted Example, JSON Examples
@@ -1799,8 +1884,10 @@ 7.6.1. JSON ExamplesJSON Examples,Order Accepted Event +![]() Order Adjusted Event -![]() pubdate: September 09, 2018 effdate: N/A
@@ -1829,12 +1916,20 @@ 8.1.1. Two Sided Quote ExamplesTwo Sided Quote Examples,The following section will provide examples of reportable events for a two-sided market maker quote when it is posted as a new quote, updated by the market maker, then canceled by the market maker or the exchange. Both the new quote and the updated quote are expressed by the Quote Event, while the quote cancel is expressed by the Quote Cancel Event. +![]() ![]() ![]() ![]() 8.1.1.1. JSON Examples Quote Event (Step 2) +![]() Quote Event (Step 4) +![]() Quote Cancel Event (Step 6a) +![]() Quote Cancel Event (Step 5b) -![]() pubdate: September 09, 2018 effdate: N/A
8.1.2. Example One Sided QuotesTopic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Quote and Quote Cancel Events, Example One Sided Quotes
@@ -1843,12 +1938,19 @@ 8.1.2. Example One Sided QuotesExample One-sided,The following section will provide examples of reported events for a one-sided market maker quote when it is posted as a new quote, updated by the market maker, then canceled by the market maker or the exchange. Both the new quote and the update are expressed by the Quote Event, while the quote cancel is expressed by the Quote Cancel Event. +![]() ![]() ![]() 8.1.2.1. JSON Examples Quote Event (Step 2) +![]() Quote Event (Step 4) +![]() Quote Cancel Event (Step 6a) +![]() Quote Cancel Event (Step 5b) -![]() pubdate: September 09, 2018 effdate: N/A
8.2. Option Order Event Examples@@ -1865,7 +1967,10 @@8.2.1. Example Simple Option Order AcceptedSimple Option Order,This example describes a Simple Option Order Accepted Event in which the exchange receives and accepts an order for a simple option. Note that in this example Complex Order ID is not provided because there is no parent complex order. -![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
8.2.1.1. JSON ExampleTopic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Option Order Event Examples, JSON Example
@@ -1874,7 +1979,8 @@ 8.2.1.1. JSON ExampleJSON Examples,Simple Option Order Accepted Event -![]() pubdate: September 09, 2018 effdate: N/A
8.2.2. Example Complex Option Order Accepted EventTopic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Option Order Event Examples, Example Complex Option Order Accepted Event
@@ -1884,10 +1990,15 @@ 8.2.2. Example Complex Option Order Accepted EventIn the example below, the exchange only creates leg orders at the time an order is executed. Thus, an order on the complex option would have a report sent to CAT for an order accepted event at the parent level of the complex order. Any leg reports would wait until the leg orders are actually created when a trade occurs. The examples in this section will use an order on the complex option with optionID 9843. This hypothetical complex option has two option series legs: +![]() For this example, we suppose at 192411.121456789 on April 20, 2017 an order was accepted for 10 units of complex option 9843 at net price -65 per unit. +![]() ![]() ![]() 8.2.2.1. JSON Examples Complex Order Accepted Event (Step 3) -![]() pubdate: September 09, 2018 effdate: N/A
8.3. Simple Option Trade Event Examples@@ -1897,6 +2008,10 @@8.3. Simple Option Trade Event ExamplesSimple Option Order,The below section will provide an example of a trade event for an option series where a broker order is executed against an existing market maker quote. +![]() ![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
8.3.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Simple Option Trade Event Examples, JSON Examples
@@ -1905,9 +2020,12 @@ 8.3.1. JSON ExamplesJSON Examples,Quote Event +![]() Simple Option Order Accepted Event +![]() Option Trade Event -![]() pubdate: September 09, 2018 effdate: N/A
8.4. Complex Options Trade Events and Examples@@ -1917,6 +2035,7 @@8.4. Complex Options Trade Events and ExamplesComplex Options Trade Events,In all cases, complex option trades are reported to CAT only at the leg level. There is no roll-up trade reported at the complex order level. For example, an order on the complex option (ID 9851) below would have had corresponding orders reported to CAT for each of the underlying legs. As the following examples will show, trades on this complex option will report by leg, with each leg trade event corresponding to an order event on the leg that is in turn attached to a parent-level complex order event. +![]() This section follows a series of trade events on the complex option described above, along with examples of the quotes and orders that would be referenced in those trades. • A new market maker quote is posted for the option leg 1491 • A new market maker quote is posted for the option leg 1492 @@ -1924,7 +2043,14 @@8.4. Complex Options Trade Events and Examples• A trade on the first option leg 1491 is reported (10 contracts) • A trade on the second option leg 1492 is reported (10 contracts) • A route on the stock leg XYZZY is reported (1,000 shares) +![]() • A fill on the stock leg XYZZY is reported (1,000 shares) +![]() ![]() ![]() ![]() ![]() ![]() pubdate: September 09, 2018 effdate: N/A
8.4.1. JSON ExamplesTopic: CAT Participant Technical Specifications v1.7.1, Options Exchange Event Examples, Complex Options Trade Events and Examples, JSON Examples
@@ -1933,16 +2059,26 @@ 8.4.1. JSON ExamplesJSON Examples,Quote Event (Step 2) +![]() Quote Event (Step 4) +![]() Complex Option Order Accepted Event (Step 7) +![]() Simple Option Order Accepted Event (Step 8) +![]() Simple Option Order Accepted Event (Step 9) +![]() Stock Leg Order Accepted Event (Step 10) +![]() Option Trade Event (Step 11) +![]() Option Trade Event (Step 12) +![]() Option Route Event (Step 13) +![]() Stock Leg Fill Event (Step 14) -![]() pubdate: September 09, 2018 effdate: N/A
@@ -2061,20 +2197,46 @@ AppendixC.1. NASDAQ Specifications NASDAQ will submit all data for the day using a single file type, similar to all other file submissions, with the base filename NASDDaily. The file will contain any or all record types listed in this section, and shall be submitted in JSON format. Note that each record type is identified by a type field. C.1.1. NASDAQ Equities Daily List - Notes for the Day +![]() C.1.2. NASDAQ Equities Daily List +![]() ![]() ![]() ![]() ![]() ![]() C.1.3. NASDAQ Dividends Daily List +![]() ![]() ![]() ![]() C.1.4. NASDAQ Next Day X-Rates Daily List +![]() ![]() ![]() ![]() C.2. BATS Specifications Bats will submit all reports using one single file type, with the base filename BATSDaily. Each report will be submitted in CSV format, where the first column designates the type of that record. Each record type may have different numbers of columns, but each record of the same type must have all columns in the definition for that record type. C.2.1. Header Record The very first record of the file must be a header record, which provides general information about the submitted records. There must be exactly one header record, which contains the following fields. Header Record +![]() C.2.2. Daily Listed Securities Record Daily Listed Securities Record Fields +![]() ![]() ![]() C.2.3. Daily Distribution Record Daily Distribution Record Fields +![]() ![]() ![]() C.2.4. Daily Corporate Action Record Daily Corporate Actions Record Fields +![]() ![]() ![]() ![]() C.3. NYSE Specification The NYSE Group Corporate Actions product is comprised of several reports and provides information for equities listed on the NYSE, NYSE MKT and NYSE Arca market centers, including, but not limited to, new listings (for example IPOs, spin-offs and structured product listings), corporate actions, cash dividends, proxy related matters, and so forth. NYSE will submit all reports using one single file type, with the base filename NYSEDaily. Each report will be submitted in CSV format, where the first column designates the type of that record. Each record type may have different numbers of columns, but each record of the same type must have all columns in the definition for that record type. @@ -2082,15 +2244,33 @@AppendixC.3.1. NYSE Corporate Actions The NYSE corporate actions and group ex-date corporate actions will be submitted with a record of this type. NYSE Group Daily Corporate Actions & NYSE Group Ex-Date Corporate Actions +![]() ![]() C.4. FINRA Daily Specification +![]() C.4.1. FINRA Corporate Actions The layout of the FINRA Corporate Action. FINRA OTC Corporate Action +![]() ![]() The following table contains the valid choices for the field DAILY_LIST_RSN_CD. Daily List Reason Codes +![]() ![]() ![]() D. FINRA Trade Reporting Facility (TRF) Fields These message types go into the FinraTransactions file kind. TRF Trade Report Required Fields +![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() E. Market Move Scenarios This appendix provides guidance on how some common scenarios where a listed symbol can move from one listing participant to another should be handled. E.1. Common Scenarios diff --git a/spider/files/data000014.html b/spider/files/data000014.html index 9ce401e..9202bb0 100644 --- a/spider/files/data000014.html +++ b/spider/files/data000014.html @@ -2668,12 +2668,14 @@APPENDIX D• 8:00 a.m. Eastern Time T+5 (transaction date + five days) – Corrected data available to Participant regulatory staff and the SEC. Late submissions or re-submissions (after 8:00 a.m.) may be considered to be processed that day if it falls within a given time period after the cutoff. This threshold will be determined by the Plan Processor and approved by the Operating Committee. In the event that a significant portion of the data has not been received as monitored by the Plan Processor, the Plan Processor may decide to halt processing pending submission of that data. Figure A: CAT Central Repository Data Processing Timelines +![]() 6.2 Data Availability Requirements Prior to 12:00 p.m. Eastern Time on T+1, raw unprocessed data that has been ingested by the Plan Processor must be available to Participants’ regulatory staff and the SEC. Between 12:00 p.m. Eastern Time on T+1 and T+5, access to all iterations of processed data must be available to Participants’ regulatory staff and the SEC. The Plan Processor must provide reports and notifications to Participant regulatory staff and the SEC regularly during the five-day process, indicating the completeness of the data and errors. Notice of major errors or missing data must be reported as early in the process as possible. If any data remains un-linked after T+5, it must be available and included with all linked data with an indication that the data was not linked. If corrections are received after T+5, Participants’ regulatory staff and the SEC must be notified and informed as to how re-processing will be completed. The Operating Committee will be involved with decisions on how to re-process the data; however, this does not relieve the Plan Processor of notifying the Participants’ regulatory staff and the SEC. Figure B: Customer and Account Information (Including PII) +![]() CAT PII data must be processed within established timeframes to ensure data can be made available to Participants’ regulatory staff and the SEC in a timely manner. Industry Members submitting new or modified Customer information must provide it to the Central Repository no later than 8:00 a.m. Eastern Time on T+1. The Central Repository must validate the data and generate error reports no later than 5:00 p.m. Eastern Time on T+1. The Central Repository must process the resubmitted data no later than 5:00 p.m. Eastern Time on T+4. Corrected data must be resubmitted no later than 5:00 p.m. Eastern Time on T+3. The Central Repository must process the resubmitted data no later than 5:00 p.m. Eastern Time on T+4. Corrected data must be available to regulators no later than 8:00 a.m. Eastern Time on T+5. Customer information that includes PII data must be available to regulators immediately upon receipt of initial data and corrected data, pursuant to security policies for retrieving PII. 7. Receipt of Data from Reporters diff --git a/spider/files/data000017.html b/spider/files/data000017.html index 9b91958..000af57 100644 --- a/spider/files/data000017.html +++ b/spider/files/data000017.html @@ -2221,6 +2221,7 @@1. Analysis of Expected CostsFinally, the Plan now requires that each Participant conduct background checks of its employees and contractors that will use the CAT System. The Commission estimates that this requirement would entail an initial cost of $60,000, with ongoing annual costs of $14,000.2504 The Commission is also revising its Participant cost estimates to account for the addition of two additional Participants that were not covered by the Participants Study.2505 The Commission assumes the new Participants will have similar costs to the 19 Participants that provided cost estimates summarized in the Plan. Consequently, the Commission has increased its estimates of Participants costs by 10.53%.2506 The Commission now estimates that the 21 Participants spend $8 million annually for data reporting, and $162.7 million for surveillance. The Commission estimates that implementation of CAT Data reporting will cost the Participants $19.8 million, and implementation of surveillance using data in the Central Repository will cost the Participants $25.6 million. The Commission estimates that Participants will spend $16.2 million annually to maintain CAT Data reporting, and $96.9 million annually on surveillance. The Commission is also recognizing that the Participants will recoup $8.8 million in Plan development costs, as discussed above. The Commission estimates that Participants will spend approximately $1.1 million to produce one-time reports required by amendments to the Plan, and $1.1 million annually to produce additional periodic reports required by amendments to the Plan. Furthermore, the Commission is recognizing $343,000 in system retirement costs, as discussed below.2507 The Commission is unable to update cost estimates to account for the modifications to the clock synchronization standards for exchanges, but, as discussed below, the Commission does not believe that the modifications will result in substantial cost increases for exchanges.2508 The Commission acknowledges that the addition of quote sent times to option market maker quotes may increase costs to options exchanges. Based on comments received, the Commission believes that Participant cost estimates from the Participants Study are unlikely to include the additional expense Participants will incur capturing and processing the Quote Sent Time field. The Commission lacks information to estimate these costs for Participants because the Plan does not include this information and commenters did not offer estimates. Table 3 reflects the Commission’s estimates after taking these adjustments into consideration. Table 3: Estimates of Participants’ Costs +![]() c. Costs to Broker-Dealers (1) Summary of Notice and Comments and Commission’s Response In the Notice, the Commission provided an analysis of the compliance cost estimates for broker-dealers that included analyzing whether estimates provided in the Plan and based on a Reporters Study survey were reliable.2509 The Commission preliminarily believed that the cost estimates for small broker-dealers were not reliable. The Commission described the details of the analysis supporting that conclusion. The Commission then developed and calibrated a model (“Outsourcing Cost Model”) to estimate average current data reporting costs and average Plan compliance costs for broker-dealers that the Commission expects will rely on service bureaus to perform their CAT Data reporting responsibilities (“Outsourcers”). For other broker-dealers, the “Insourcers,” the Commission continued to rely on the large broker-dealer estimates from the Plan. Using this framework, the Commission estimated approximate one-time implementation costs for broker-dealers of $2.1 billion, and annual ongoing costs of CAT reporting of $1.5 billion. @@ -2251,6 +2252,7 @@1. Analysis of Expected CostsAs discussed in detail in the Notice, pre-CAT Data reporting cost estimates range from $167,000 annually for floor brokers and firms that are exempt from OATS reporting requirements to $8.7 million annually for firms that report more than 350,000 OATS ROEs per month (“Insourcers”). Estimates of one-time implementation costs range from $424,000 for OATS reporters that are assumed to outsource (“OATS Outsourcers”) to $7.2 million for Insourcers, and ongoing annual costs range from $443,000 annually for firms that are assumed to outsource (OATS Outsourcers, New Outsourcers and Floor Brokers) to $4.8 million for Insourcers. Table 4 summarizes the Commission’s updated estimates of costs to broker-dealers expected from the approval of the CAT NMS Plan. The Commission estimates that broker-dealers spend, in aggregate, approximately $1.6 billion annually on current regulatory data reporting activities. The Commission estimates approximate one-time implementation costs of $2.2 billion, and annual ongoing costs of CAT reporting of $1.5 billion.2564 The Commission notes that its estimate of ongoing CAT reporting costs of $1.5 billion is slightly lower than current data reporting costs of $1.6 billion. As explained in the Notice, this differential is driven by expectations of reductions in data reporting costs reported by large OATS-reporting broker-dealers in the Reporters Study survey.2565 The Commission estimates that all other categories of broker-dealers will face significant increases in annual data reporting costs. Also, the Commission acknowledges that there are some broker-dealers that would be classified as Outsourcers or new reporters for which the Commission’s cost estimates rely on the Outsourcing Cost Model, and the additional implementation costs that these firms face due to clearing for other broker-dealers or supporting introducing broker-dealers are not captured by these estimates. Table 4: Estimated Broker-Dealer Costs for CAT NMS Plan2566 +![]() The Commission recognizes both that there is uncertainty in these cost estimates and that these cost estimates do not include additional costs that Outsourcers and new reporters that clear for other broker-dealers or support introducing broker-dealers will incur. As explained above, because the Commission’s Outsourcing Cost Model does not and cannot incorporate these costs, the cost estimates here could underestimate the costs for these firms and, as a result, the total broker-dealer costs. Because Bids are not yet final, the Commission believes that its cost estimates, while reliable in light of available data and information, could differ from actual costs the broker-dealers will incur and that broker-dealers will not know the true magnitude of their costs until they can analyze the Technical Specifications. d. Costs to Service Bureaus In the Notice, the Commission considered whether to include the implementation and ongoing costs to service bureaus in the aggregate costs of the Plan.2567 The Commission preliminarily believed that costs that service bureaus would face to implement CAT should be included as part of the aggregate costs of CAT. While the CAT NMS Plan does not require the use of service bureaus to report CAT Data, the Commission recognized that the most cost effective manner to implement the Plan likely will be for most market participants to continue their current practice of outsourcing their regulatory data reporting to one or more service bureaus. By doing so, the roughly 1,600 broker-dealers predicted to outsource would avoid incurring a significant fraction of CAT implementation costs; instead, service bureaus would incur implementation costs on their behalf. Based on conversations with market participants, the Commission believed that these implementation costs are likely to pass-through to broker-dealers that outsource data reporting, because service contracts between broker-dealers and service bureaus are renegotiated periodically, and approval of the CAT NMS Plan could trigger renegotiation as the bundle of services provided would materially change. @@ -2280,6 +2282,7 @@2. Aggregate Costs to IndustryThe Commission has, however, updated its aggregate cost estimates to account for the updates to Central Repository, Broker-Dealer, Participant and Service Bureau cost estimates which incorporate updates due to modifications of the Plan. In aggregate, the Commission believes that that industry will spend $2.4 billion to implement CAT, and $1.7 billion per year in ongoing annual costs. Table 5 below shows these new cost estimates and aggregate costs to industry. Some individual estimates have changed from estimates presented in the Notice for a number of reasons. First, the Commission is now recognizing system retirement costs of $55 million. Also, estimates for Participant costs have increased to account for two additional Participants that were not covered by the Participants Study, and to account for the cost of additional reporting required by amendments to the Plan. Finally, estimates for Central Repository implementation and ongoing costs have been updated to reflect the Participants’ current estimates. As Table 5 shows, however, the changes to the cost estimates do not affect the rounded estimates of implementation and ongoing costs presented in the Notice. The Commission recognizes that these cost estimates do not specifically itemize the costs of certain modifications to the Plan or respond to information provided by certain Commenters related to the costs of individual elements of the Plan. The Commission discusses these in detail in Section VI.F.3 below. Table 5 Commission's Estimate +![]() b. System Retirement and Duplicative Reporting Costs In the Notice, the Commission considered whether to include in its estimates of aggregate compliance costs the costs of system retirement and the costs of duplicative reporting if Participants and broker-dealers need to maintain and report to current systems after commencing reporting to the Central Repository. The Commission considered the costs for system retirement provided in the Plan, which discussed significant costs ($2.6 billion) for retirement of current regulatory reporting systems.2580 The Commission did not include those costs in its estimate of the aggregate costs of the Plan, for several reasons. First, the Commission preliminarily believed that the cost estimates provided in the Plan were unlikely to accurately represent the actual costs industry would face in retiring duplicative reporting systems. 2581 In particular, for the majority of broker-dealers that outsource, system retirement would affect few in-house systems; these broker-dealers would likely adapt the systems that interface with service bureaus for current regulatory data reporting to interface for CAT Data reporting. Further, for broker-dealers that self-report regulatory data, the Commission could not determine the source of the costs of system retirement that were estimated in the Plan and the magnitude of estimated costs led the Commission to doubt that estimates included only costs of retiring systems.2582 Second, the retirement of current regulatory reporting systems was not a requirement of the Plan and the timeline and process for their retirement was uncertain. @@ -2304,7 +2307,8 @@2. Aggregate Costs to IndustryThe Commission has also considered the comment that proposed alternative estimates for system retirement costs2619 and has revised its economic analysis accordingly. Specifically, the Commission believes that this commenter has the expertise to provide reliable estimates because this industry group’s members can inform it of their costs; furthermore, the Commission believes the estimates this commenter provided seem more reasonable than estimates provided in the Plan because estimates provided in the Plan exceeded the Commission’s estimate of costs of implementing the Plan.2620 To estimate the aggregate costs of system retirement, the Commission assumes that the $100,000 estimate would be appropriate for Insourcers and the $10,000 estimate would be appropriate for Outsourcers.2621 The Commission assumes that for firms that do not currently report to OATS, firms that were considered large for cost estimates (ELPs and Options Market Makers) will have similar system retirement costs to Insourcers because they are more similar in size and scope of operations to Insourcers than Outsourcers.2622 The Commission further assumes that non-OATS reporting firms that were considered small for cost estimates (new small firms and options floor brokers) will face similar system retirement costs to Outsourcers because they are more similar in size and scope of operations to Outsourcers than Insourcers.2623 With these assumptions, the Commission now estimates that broker-dealer system retirement costs would be $33.4 million, as described in Table 6. The Commission draws its estimates of system retirement costs for Participants and service providers from the Plan, which estimates aggregate costs of $343,0002624 across all Participants, and $21.3 million across all service providers. The Commission now estimates total industry costs for system retirement will be $55 million. Table 6: Estimate of System Retirement Costs -![]() pubdate: November 15, 2016 effdate: N/A
3. Further Analysis of CostsTopic: Order Approving the Consolidated Audit Trail Plan Release 34-79318, Economic Analysis, Costs, Further Analysis of Costs
diff --git a/spider/files/data000022.html b/spider/files/data000022.html
index 2e39d57..2e5a72a 100644
--- a/spider/files/data000022.html
+++ b/spider/files/data000022.html
@@ -123,11 +123,68 @@ E. Reasons for Selection of the Plan ProcessorMr. David S. Shillman, Associate Director, Division of Trading and Markets Mr. David Hsu, Assistant Director, Division of Trading and Markets IN WITNESS WHEREOF, the Participants have executed this Limited Liability Company Agreement as of the day and year first above written. +![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() IN WITNESS WHEREOF, the Participants have executed this Limited Liability Company Agreement as of the day and year first above written. P A R T I C I P A N T S: +![]() ![]() ![]() ![]() TN WITNESS WHEREOF, the Participants have executed this Limited Liability Company Agreement as ofthe day and year first above written. PARTICIPANTS: -![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|