Orchimate 1.3.2 /

FINRA CAT4.0.0-r18

Orchestra Hub

New Order events represent the beginning of the order lifecycle in CAT. An Industry Member must report a New Order event to CAT when an order is received or originated including:

• New customer orders
• Representative orders
• Proprietary orders
• Order(s) received from a foreign broker-dealer or affiliate that is not a CAT Reporter.

An order received from another CAT Reporter (US broker-dealer, ATS or an exchange) must be reported as an Order Accepted event.

Representative Orders

Industry Members are required to link representative street-side orders with the related customer order or client order being represented. The Industry Member must report a New Order event for the creation of the representative order, and populate the representativeInd field to indicate that it is a representative order. The Industry Member must also populate the aggregatedOrders field linking the representative order to the underlying orders.

Appendix C contains detailed descriptions of representative order scenarios and illustrates when marking of the representative order, linkage between the represented order and the representative order, and Order Fulfillment linkage is required.

The New Order Supplement event is a supplement to 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. This event accommodates reporting in the following scenarios:

Aggregated Orders

This event accommodates reporting in scenarios when the number of Aggregated Orders included in the aggregatedOrders field causes the New Order event to exceed the maximum allowed message length, or when the orders being represented are not captured in the New Order Event. The aggregatedOrders field in the New Order Supplement event must contain the additional Aggregated Orders that were not captured in the original New Order event, or another Supplement event for the same order.

FDID

This event accommodates reporting in scenarios when an Industry Member receives an order for a new account and the new account number, on which the FDID is based, is not yet available for creation and reporting of the CAT new order event. If an FDID has not yet been created when an order has been received, the Industry Member must populate the firmDesignatedID field in its New Order event with a value of ‘PENDING’.

Once the FDID becomes available, the Industry Member must report the actual FDID in the firmDesignatedID field in a New Order Supplement event. Any New Order Supplement event with an FDID populated will not be considered late for CAT reporting purposes if it is received by T+3 @ 8:00 AM ET. Refer to the CAT CAIS Industry Member Reporting Scenarios for additional information on how the firmDesignatedID will be reflected in the CAIS.

Industry Members are required to report an Order Route event to CAT in the following scenarios when an order is routed in full or in part:

• Routing to another Industry Member
• Routing to foreign broker-dealers
• Routing to exchanges
• Routing between two IMIDs (e.g., two different FINRA MPIDs) attributed to the same legal entity (i.e., the same CRD).

When routing between two IMIDs of the same legal entity, the affiliateFlag must be populated as ‘true’ in accordance with CAT FAQ E27. Internal routes to another desk or department within an Industry Member are reported using an Order Internal Route Accepted event. Refer to the Order Internal Route Accepted section for more details.

Handling Instructions on Order Route Events

Handling Instructions are required to be reported on the Order Route event. The handling instructions included in this event must represent the handling instructions sent by the routing firm to the receiving destination. If the handling instructions do not change when the order is routed externally from the handling instructions received by the Industry Member and reported on the Order Accepted or New Order event associated with the order, Industry Members may use the handling instruction code ‘RAR’ (Routed as Received) instead of repeating each individual handling instruction.

Industry Members must report a Route Modified event to CAT when the Material Terms of a route have been changed (e.g., price, quantity), or when a route is cancel/replaced.

All attributes and Material Terms of the route listed on this event must be restated with the modification(s) reflected. The side field is required to be reported, but side adjustments are only allowed for same-side changes, including changes between Short Sale and Sell Long. Route Modified events must not be used to reflect a change in senderIMID, destination, or destinationType. These changes must be reflected as a Route Cancelled event followed by a new Order Route event.

The routedOrderID of the Order Route event being modified must be reflected in the Route Modified event. If the routedOrderID changed when the route was modified, the routedOrderID of the Order Route event being modified must be populated in the priorRoutedOrderID field. If the routedOrderID did not change when the route was modified, the routedOrderID of the Order Route event must be populated in the routedOrderID field, and the dupROIDCond must be populated as ‘true’.

If a route modification request is rejected by the destination venue, the Route Modified event must be reported with a routeRejectedFlag of true.

Industry Members must report a Route Cancelled event to CAT when a route has been fully or partially cancelled. Partial cancellations of a route may be reported to CAT using a Route Cancelled event or a Route Modified event. However, when routing between Industry Members, both parties must communicate and use the same method to report to CAT. If one party reports to CAT using the cancellation method and the other party reports to CAT using a modification method, this will result in unlinked records that must be resolved.

The routedOrderID of the Order Route event being cancelled must be reflected in the Route Cancelled event. If a route cancellation request is rejected by the destination venue, the Route Cancelled event must be reported with a routeRejectedFlag of ‘true’.

The Order Route Supplement event is a supplement to the Order Route event. Order Route Supplement events are considered as additions to an Order Route event, not replacements or modifications. This event accommodates reporting in scenarios where a route is rejected by the venue to which an order was routed, and the Industry Member chooses to report the routeRejectedFlag in this separate Order Route Supplement event.

An Order Route Supplement event may not be used to supplement an Order Route event where the dupROIDCond field is ‘true’. These supplement events will be accepted by CAT, but credit will not be provided to any exchange linkage errors on the Order Route event where the dupROIDCond field is ‘true’.

The Route Modified Supplement event is a supplement to the Route Modified event. Route Modified Supplement events are considered as additions to a Route Modified event, not replacements or modifications. This event accommodates reporting in scenarios where a route modification is rejected by the venue to which the route modification was sent, and the Industry Member chooses to report the routeRejectedFlag in this separate Route Modified Supplement event.

A Route Modified Supplement event may not be used to supplement a Route Modified event where the dupROIDCond field is ‘true’. These supplement events will be accepted by CAT, but credit will not be provided to any exchange linkage errors on the Route Modified event where the dupROIDCond field is ‘true’.

The Route Cancelled Supplement event is a supplement to the Route Cancelled event. Route Cancelled Supplement events are considered as additions to a Route Cancelled event, not replacements or modifications. This event accommodates reporting in scenarios where a route cancellation is rejected by the venue to which the route cancellation was sent, and the Industry Member chooses to report the routeRejectedFlag in this separate Route Cancellation Supplement event.

A Route Cancellation Supplement event may not be used to supplement a Route Cancelled event where the dupROIDCond field is ‘true’. These supplement events will be accepted by CAT, but while Route Cancelled events are not subject to exchange linkage, Route Cancelled events where the dupROIDCond field is ‘true’ will not be considered supplemented.

An Order Accepted event must be reported to CAT when an Industry Member receives an order from another CAT Reporter (i.e., Industry Member, ATS or exchange), or from another IMID belonging to the same Industry Member (i.e., the same CRD).

New customer orders, orders received from a non-broker-dealer affiliate, and orders received from a non-reporting foreign broker-dealer must be reported using a New Order event.

An Order Internal Route Accepted event must be reported when an order is passed to a different department or desk within the CATReporterIMID. Routes between different IMIDs attributed to the same Industry Member must be reported as Order Route and Order Accepted events.

An Order Internal Route Accepted event is required to be reported from the perspective of the recipient desk, and indicates that an order was received by an internal destination. In Phase 2d, Industry Members may choose to assign a new Order Key to an Order Internal Route Accepted event. If a new orderID is assigned, the parentOrderID must be populated with the orderID of the event that was internally routed, and the parentOrderKeyDate must be populated.

An Industry Member may generate child orders using the Child Order event prior to routing internally to another desk. This approach is acceptable for CAT reporting and will not result in unlinked events.

Industry Members must report an Order Internal Route Modified event to CAT when the Material Terms of the internal route have been changed (e.g., price, quantity). All attributes and Material Terms of the modified internal route listed on this event must be restated with the modification(s) reflected.

Industry Members may assign a new Order Key to Order Internal Route Modified events. If a unique orderID is assigned, the priorOrderID must be populated with the orderID of the Order Internal Route Accepted event that is being modified, and the priorOrderKeyDate must be populated.

If an internal route is cancelled, an Order Internal Route Cancelled event must be reported. Partial cancellations may be reported using an Order Internal Route Modified event or Order Internal Route Cancelled event with leavesQty.

Industry Members must report an Order Internal Route Modification Request event to CAT when a desk within the firm receives a request to modify the Material Terms of an internal route if the request is not captured in the requestTimestamp field of the Order Internal Route Modified event. All attributes and Material Terms of the modified internal route listed on this event must be restated with the requested modification(s) reflected.

Industry Members must report an Order Internal Route Cancel Request event to CAT when a desk within the firm receives a request to cancel an internal route if the request is not captured in the requestTimestamp field of the Order Internal Route Cancelled event.

The Child Order is used to represent instances when an order is sliced within the desk or department it is being worked, and is assigned a new order identifier. While all CAT reportable activity must be reported to CAT in applicable phases, Child Order events are not required to be utilized for CAT reporting. These event types are for the convenience of Industry Members to help model these types of order handling scenarios.

Child Order events are defined to include only the key data elements that may be changed when the event is created including fields to link to the parent order. The following rules apply with respect to Child Orders:

• Child Order events can only be reported when new order IDs are assigned within the same desk. An Order Internal Route Accepted event must be reported when routed to another desk.
• A child order may be generated off of another child order without limitation.
• Child Order events must belong to the same FDID as the parent order. Child Orders must not be used to create representative orders. If the FDID changes, a representative New Order event must be reported and not a Child Order.
• Child Order events must not be used to represent a multi-leg option order being “legged out”. However, the Child Order event may be used in scenarios where an order is “legged out” and subsequently entered into another OMS/EMS or Algo within the same desk or department where a new orderID is assigned to each leg upon entry.

Industry Members must report a Child Order Modified event to CAT when the Material Terms of the child order have been changed (e.g., price, quantity). All attributes and Material Terms of the modified child order listed on this event must be restated with the modification(s) reflected. A Child Order Modified event may not be used when modifying an Order Internal Route Accepted event.

Industry Members may assign a new Order Key to Child Order Modified events. If a unique orderID is assigned, the priorOrderID must be populated with the orderID of the Child Order event that is being modified, and the priorOrderKeyDate must be populated.

If a child order is cancelled, a Child Order Cancelled event must be reported. Partial cancellations may be reported using a Child Order Modified event or Child Order Cancelled event with leavesQty.

Industry Members must report an Order Modified event to CAT when the Material Terms of an order have been changed (e.g., price, quantity) or when an order is cancel/replaced. All attributes and Material Terms of the modified order listed on this event must be restated with the modification(s) reflected. If the order is a representative order, the aggregatedOrders field must be restated every time the order is modified or cancel/replaced. Changes to the orders being represented in the aggregatedOrders field are considered a modification to the order. The side field is required to be reported, but side adjustments are only allowed for same-side changes, including changes between Short Sale and Sell Long.

If a modification results in the generation of new order with a new Order Key which replaces the prior order, the orderID field must capture the identifier for the new order, and the prior order fields must reflect the order that is being replaced. If the order has been modified more than once with a new orderID assigned with each modification, the priorOrderID must refer to orderID of the immediately preceding modification which will not be the original Order ID. If the orderID remains the same during the modification, the priorOrderID must remain blank.

Industry Members are not required to report the modification request to CAT if the order is terminal (e.g., it has already been fully executed or cancelled) in Phase 2d. However, this activity may be required in future phases of CAT. If a modification request was received that was too late to modify, and the order was not terminal (e.g., the order was “in-flight” and there was no confirmation time), the request must be reported as an Order Modification Request event.

The Order Modified Supplement event serves as a supplement to the Order Modified event, just as the New Order Supplement event serves as a supplement to the New Order event.

The Order Modification Request event is required when a request is received to modify the Material Terms of an order if the request is not captured in the requestTimestamp field of the Order Modified event. Industry Members are not required to report an Order Modification Request event to CAT if the order is terminal (e.g., it has already been fully executed or cancelled) in Phase 2d. However, this activity may be required in future phases of CAT.

An Order Adjusted event must be used when the display price or quantity changes as the result of a Display ATS matching engine action and not from a customer/client instruction. The Order Adjusted event may be used by non-ATS firms instead of an Order Modified event to report changes to the price or quantity of an order.

The following rules apply:

• If any of the price fields change, then all price fields (i.e., price, displayPrice, and workingPrice) must be reported to represent current state of the order relative to price. The quantity fields are not required.
• If any of the quantity fields change, then all quantity fields (i.e., quantity, minQty, leavesQty, displayQty) must be reported to represent the current state of the order relative to quantity. The price fields are not required.

Any modification that cannot be fully represented in this Reportable Event must be reported via the Order Modified event. This includes modifications received from another Industry Member where a routedOrderID is required, and modifications to the orderType.

Industry Members may assign a new Order Key to Order Adjusted events. If a unique orderID is assigned, the priorOrderID must be populated with the orderID of the order that is being adjusted, and the priorOrderKeyDate must be populated. If the order has been adjusted more than once, the priorOrderID must refer to orderID of the immediately preceding adjustment which will not be the original Order ID.

The Order Cancelled event is reported when an order is fully or partially cancelled. Partial cancellations of an order may be reported to CAT using an Order Cancelled event or an Order Modified event. However, when routing between Industry Members, both parties must communicate and use the same method to report to CAT. If one party reports to CAT using the cancellation method and the other party reports to CAT using a modification method, this will result in unlinked records that must be resolved.

Implicit order cancellations, such as cancellations due to expiration of Time in Force, are not required to be reported to CAT.

Order Cancelled events are required to be reported by the entity that initiated the cancellation. When an Order is routed from Firm A to Firm B, the following rules apply:

• If Firm A or its customer/client initiates the cancel, Firm A and Firm B must report the Order Cancelled event.
• If Firm B initiates the cancel, Firm B must report the Order Cancelled event.

Industry Members are not required to report the cancel request to CAT if the order is terminal (e.g., it has already been fully executed or cancelled) in Phase 2d. However, this activity may be required in future phases of CAT. If a cancellation request was received that was too late to cancel, and the order was not terminal (e.g., the order was “in-flight” and there was no confirmation time), the request must be reported as an Order Cancel Request event.

The Order Cancel Request event is required when a request is received to cancel an order if the request is not captured in the requestTimestamp field of the Order Cancelled event. Industry Members are not required to report an Order Cancel Request event to CAT if the order is terminal (e.g., it has already been fully executed or cancelled) in Phase 2d. However, this activity may be required in future phases of CAT.

The New Quote Event is used to report the following:

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

For two-sided quote events, the bidPrice, bidQty, askPrice, and askQty fields must be populated. For one-sided quote events, the price and quantity of the applicable side must be populated. For quotes representing a name only quote for which a price and quantity is not applicable, the price and quantity of the applicable side must be blank or must be populated with zero, and the unpricedInd must be populated as ‘true’.

If the field onlyOneQuoteFlag is populated as ‘true’, any New Quote event offered by the same CATReporterIMID to the same destination in the same symbol will be considered cancelled and replaced by CAT. Modifications reflected using the onlyOneQuoteFlag method may maintain the same quote ID. However, if a quote is cancelled and a new quote is reported to CAT, the New Quote Event must not maintain the same quote ID as the quote that was cancelled. Modifications to a quote when the onlyOneQuoteFlag is populated as ‘true’ must not be captured using the Quote Modified event.

Quotes entered directly into an inter-dealer quotation system’s platform that are not sent to the inter-dealer quotation system electronically (e.g., via FIX) are considered to be originated manually, and the manualFlag must be populated as ‘true’.

The New Quote Supplement event is a supplement to the New Quote event. One New Quote event can have multiple New Quote Supplement events. Multiple New Quote Supplement events are considered as additions, not replacements or modifications.

This event accommodates reporting in scenarios when the number of Aggregated Orders included in the askAggregatedOrders or bidAggregatedOrders fields cause the New Quote event to exceed the maximum allowed message length, or when the orders being represented are not captured in the New Quote event. The askAggregatedOrders and bidAggregatedOrders fields in the New Quote Supplement event must contain the additional Aggregated Orders that were not captured in the original New Quote event, or another Supplement event for the same quote.

This event is applicable for an Industry Member generating quotes and displaying them on a Display-only Facility.

The Routed Quote Event is used to report the following:

• Quotes in OTC equity securities sent to an inter-dealer quotation system operated by an Industry Member
• Quotes in OTC Equity securities sent to a quotation venue not operated by a CAT Reporter.
• Any other route of electronic quotes which are provided by or received in a CAT Reporter’s order/quote handling or execution systems in CAT reportable securities and are provided by an Industry Member to other market participants off a national securities exchanges, as described in [CAT FAQ B45](https://catnmsplan.com/faq%23B45.

For two-sided quote events, the bidPrice, bidQty, askPrice, and askQty fields must be populated. For one-sided quote events, the price and quantity of the applicable side must be populated. For quotes representing a name only quote for which a price and quantity is not applicable, the price and quantity of the applicable side must be blank or must be populated with zero, and the unpricedInd must be populated as ‘true’.

Quotes entered directly into an inter-dealer quotation system’s platform that are not sent to the inter-dealer quotation system electronically (e.g., via FIX) are considered to be routed manually, and the manualFlag must be populated as ‘true’. The routedQuoteID field is not required for manual routes.

The Routed Quote Supplement Event is a supplement to the Routed Quote event. Routed Quote Supplement events are considered as additions to a Routed Quote event, not replacements or modifications. This event accommodates reporting in scenarios where a quote route is rejected by the venue to which it was routed, and the Industry Member chooses to report the quoteRejectedFlag in this separate Routed Quote Supplement event.

This event is applicable for an Industry Member generating quotes and displaying them on a Display-only Facility.

The Quote Received event is used to report Quotes in OTC Equity securities received by an Industry Member inter-dealer quotation system.

For two-sided quote events, the bidPrice, bidQty, askPrice, and askQty fields must be populated. For one-sided quote events, the price and quantity of the applicable side must be populated. For quotes representing a name only quote for which a price and quantity is not applicable, the price and quantity of the applicable side must be blank or must be populated with zero, and the unpricedInd must be populated as ‘true’.

If the field onlyOneQuoteFlag is populated as ‘true’, any Quote Received event offered by the same CATReporterIMID from the same senderIMID in the same symbol will be considered cancelled and replaced by CAT. Modifications reflected using the onlyOneQuoteFlag method may maintain the same quote ID. However, if a quote is cancelled and a new quote is reported to CAT, the Quote Received Event must not maintain the same quote ID as the quote that was cancelled. Modifications to a quote when the onlyOneQuoteFlag is populated as ‘true’ may alternatively be captured using the Quote Modified event.

Quotes entered directly into an inter-dealer quotation system’s platform that are not sent to the inter-dealer quotation system electronically (e.g., via FIX) are considered to be received manually, and the manualFlag must be populated as ‘true’. The routedQuoteID field is not required for manual routes.

Reported when a quote is cancelled. If a quote is cancelled that was sent to by an Industry Member to an Industry Member inter-dealer quotation system, then both the sender of the quote and the inter-dealer quotation system that accepted the quote must report Quote Cancelled events.

Orders cancelled directly in an inter-dealer quotation system’s platform that are not sent to the inter-dealer quotation system electronically (e.g., via FIX) are considered to be cancelled manually, and the manualFlag must be populated as ‘true’.

Reported when a quote is modified, and the venue supports more than one quote per symbol for an Industry Member at one time. If the field onlyOneQuoteFlag field on the related New Quote or Quote Received event is populated as ‘true’, the Quote Modified event must not be used.

If a modification to a quote results in the generation of a new quoteID with a new Quote Key which replaces the prior quoteID, the quoteID field must capture the newly assigned quoteID, and the prior quote fields must reflect the quote that is being modified. If the quote has been modified more than once with a new quoteID assigned with each modification, the priorQuoteID must refer to quoteID of the immediately preceding modification which will not be the original Quote ID. If the quoteID remains the same during the modification, the priorQuoteID must remain blank.

Orders modified directly in an inter-dealer quotation system’s platform that are not sent to the inter-dealer quotation system electronically (e.g., via FIX) are considered to be modified manually, and the manualFlag must be populated as ‘true’.

Reported when the status of a quote is changed to be opened or closed. If a quote that was sent by an Industry Member to an Industry Member inter-dealer quotation system is opened or closed by the Industry Member that sent the quote, then both the sender of the quote and the inter-dealer quotation system that accepted the quote must report Quote Status events.

If the status of a quote that was sent by an Industry Member to an Industry Member inter-dealer quotation system is changed as a result of an automatic process, then a Quote Status event is only required to be reported by the inter-dealer quotation system. Refer to CAT FAQ J5 for additional information.

Orders updated directly in an inter-dealer quotation system’s platform that are not sent to the inter-dealer quotation system electronically (e.g., via FIX) are considered to be updated manually, and the manualFlag must be populated as ‘true’.

A Trade Event is used when the Industry Member acts as the executing broker and is required to report the trade for public dissemination purposes. When an Industry Member is not required to report the execution of a customer/client order for public dissemination purposes, with the exceptions noted below, an Order Fulfillment event must be used. See Section Order Fulfillment for more details.

Reporting Exception Codes

In general, Trade events are required to match to a TRF/ORF/ADF report. However, there are four circumstances when an MEOT would not be able to be linked to a TRF report and a Reporting Exception Code (REC) is required on a Trade event to allow the Processor to identify that there will be no link to a TRF/ORF/ADF report:

• An Industry Member executes a trade between two desks or departments of the same firm, but because there is no change in beneficial ownership, no trade is reported for public dissemination. In this instance a REC of “P” should be used on the Trade event.

• An Industry Member executes a trade and must report the trade via Form T. In this instance, a REC of “F” should be used on the Trade event.

• A trade was executed by a non-FINRA member firm and was reported to the TRF by the FINRA member counterparty. In this instance, the non-FINRA member must populate a REC of “N” on the Trade event.

• Industry Member was the contra side of the trade report which was reported to a TRF/ORF/ADF via a QSR or AGU, and was therefore unable to populate a tapeTradeID. In this instance, a REC of ‘C’ should be used on the Trade event to reflect a linkage to the related TRF/ORF/ADF report could not be made. The following rules apply when REC ‘C’ is used:

  • The marketCenterID field must be populated.
  • The clearingFirm and counterparty fields must be populated.
  • The cancelFlag and cancelTimestamp must be populated accordingly for all trades that are reported to a TRF via a QSR or AGU and later cancelled, as the CAT would not be able to link to a related TRF cancellation.

  FINRA CAT will closely monitor all uses of REC ‘C’ to ensure compliance with the above noted guidelines.

Trade Side Details

Trade events are two-sided, containing information on both sides of the trade. Exceptions requiring only one side of the Trade event to be populated are noted below. The details of each side are reported using Trade Side Details. The data type Trade Side Details is described as a list of fields in Table 49 below. Trade Side Details must contain only one orderID per side. The buyDetails must contain the orderID of the buy side of the trade and the sellDetails must contain the orderID of the sell side of the trade. If there is more than one orderID associated with one side of the trade, the Trade Side Details related to each orderID must be populated in a separate Trade Supplement event.

Internalized Trade

When an Industry Member internalizes an order by filling it from a proprietary account, the Industry Member must report the orderID on the customer/client side and the FDID and the accountHolderType of the proprietary account on the firm side. In this scenario, no orderID is required on the firm side of the Trade event.

However, if the Industry Member generates a proprietary order to facilitate the execution of the customer/client order, the Industry Member must report the orderID of both the customer/client side and the firm side of the Trade event. Refer to CAT FAQ B41 for additional information.

One-Sided Trade events

There are several exceptions which only require one side of a Trade event to be populated. These exceptions include:

• Trade is executed as the result of a negotiation between two Industry Members.
• Order is routed by a FINRA Member to a non-FINRA member, and the FINRA Member has the obligation to submit a media trade report to a TRF/ADF/ORF.
• Order is routed by an Industry Member to a foreign broker-dealer, and the foreign broker-dealer executes the order at a net price, creating a media trade reporting obligation in the United States.

In these scenarios, each party that is required to report a Trade event to CAT must populate the sideDetailsInd indicating which side of the trade the Industry Member was associated with, and which Trade Side Details will be populated in the Trade event.

Cancelled Trades

In accordance with CAT FAQ E25, the cancelFlag must be set to true only in instances when a trade is cancelled because the trade report is rejected by the TRF/ORF or ADF. For all instances where a trade is reported to, and accepted by, the TRF/ORF or ADF, including those that are cancelled or busted in the trade reporting data, the cancelFlag must be set to false. Refer to CAT FAQ E29 and CAT FAQ E30 for additional information.

The tables below describe the data elements used to report when there is more than one order associated with one side of the trade.

The Order Fulfillment event is used to report the execution of a customer/client order that is not required to be reported for public dissemination purposes. Order Fulfillment events are required in scenarios where:

• A representative order was used to facilitate the execution of the customer/client order.
• An order is routed to a foreign market and the resulting foreign execution is not captured by CAT.

The Order Fulfillment event is designed to capture the customer/client details and the firm side details. Firm side details provide linkage to the representative order used to facilitate the execution of the customer/client order.

The fulfillmentLinkType field is used to indicate if the firm side details are required. Appendix C contains detailed descriptions of representative order scenarios and illustrates when marking of the representative order, linkage between the represented order and the representative order, and Order Fulfillment linkage is required.

The tables below describe the data elements used to report a customer/client order filled from multiple representative orders. Only one orderID may be represented in each Order Fulfillment Supplement event. If multiple representative orders were used to fill a customer/client order, the orderID for each representative order must be populated in its own Order Fulfillment Supplement event.

This CAT event is used to report the amendment of a previously reported fulfillment that occurs on the same day or on a subsequent day. An Order Fulfillment Amendment event is required to be reported to CAT if the fill to the customer/client was changed after the final fulfillment had been provided to the customer/client. This Reportable Event must capture the entire state of the fulfillment after it has been amended, even though some of the data elements may remain unchanged. However, Side Details are only required to be restated if changed. When the fulfillmentLinkType value ‘YS’ is used, Side Details must be restated using an MEOFS event if changed.

Order Fulfillment Amendments are not required in scenarios where:

• Executions against an order are tracked throughout the day but a single average price fill is provided to the customer/client after the order is completed or at the end of the day. Some systems may provide intraday transparency to the progress of executing an order as informal information that is not considered by the firm to be ‘final’ fulfillments, and these should not be reported to CAT as fulfillments and fulfillment amendments. Refer to CAT FAQ B64 for additional information.
• An Industry Member makes a correction via a debit/credit to the customer's/client’s account instead of modifying the executed shares given back to the customer/client.
• Changes do not impact CAT reportable attributes of the fulfillment.

Industry Members that perform allocations are required to submit a Post-Trade Allocation event to CAT any time shares are allocated to a customer account regardless of whether the Industry Member was involved in executing the underlying order(s). Refer to Section 3.3 for additional information on the requirements for reporting allocation events to CAT.

An Amended Allocation event is used to report to CAT when an allocation is updated such that a CAT reportable attribute is changed after the shares/contracts were originally booked in a customer account, and must always reflect the current state of the allocation. This Reportable Event must capture the entire state of the allocation after it has been amended, even though some of the data elements may remain unchanged.

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

Since changes to an allocation may occur any time after the original booking, the Amended Allocation event is due at 8AM on the next CAT Trading Day after the change was booked, even if it is on a different day than the original Allocation event. Refer to CAT FAQ U14 for additional information.

Amended Allocation events must not be reported to CAT in scenarios where: • An Industry Member makes a correction via a debit/credit to the customer's/client’s account instead of modifying the allocation given to the customer/client. • Changes do not impact CAT reportable attributes of the allocation.

Any changes to the FDID that the shares/contracts were originally booked to may be reported as either an Amended Allocation event or the cancellation of a Post-Trade Allocation event followed by a new Post-Trade Allocation event regardless if they occur pre-settlement or post-settlement.

Amended Allocation events must not be used to correct ingestion errors on a previously submitted MEPA/MEAA event.

The Order Effective event is used to indicate that an order, or an underlying condition of an order, has become effective. This event is applicable to orders such as conditional (Refer to FAQ D26), Stop, Stop Limit, Trailing Stop, Trailing Stop Limit, Stop on Quote, and Stop Limit on Quote orders. This event is NOT applicable to Stop Stock transactions. The Order Effective event must be reported by the party that was holding the order at the time the order or condition became effective.

If the triggering event causing the order to become effective was a specific price, such as a stop price, the triggerPrice field must be populated in scenarios where the trigger price was not explicitly captured in the handlingInstructions field on the related new order (e.g., Stop Formula, Trailing Stop). In scenarios where the stop price was captured in prior CAT events associated with the order (e.g., as a name/value pair in handlingInstructions on MENO and/or MEOA events), then the information may be optionally restated in the triggerPrice field on the Order Effective event; however, it is not required to be reported again.

If a new order ID is generated when the order becomes effective, which replaces the prior order ID, the orderID field must capture the new order ID, and the priorOrderID field must reflect the order ID that is being replaced. If the orderID remains the same when the order becomes effective, the priorOrderID and priorOrderKeyDate must remain blank.