Orchimate / Community /

SFC-DSOL1.0

In the DS-OL, both request and response part of an event are stored in the same record, and even if a trading system provides no message level response to a request, the eventResponseType field should still be populated with a logical response. I.e. As an order is accepted or rejected by an In- Scope Broker’s trading system, either an ’ACK’ or ’REJ’ value should be set in the eventResponseType field.

In case an event does not have any logical response, e.g. if an order was sent to an Execution Venue but a response was never received (e.g., when the Execution Venue went down), this can be recorded with a ’No Response’ (’null’) value in the eventResponseType field.

The Order Modify event should generally be used when any Material Term of an order is modified. When multiple Material Terms of an order are modified in a single operation, only one Order Modify event is required. However, if multiple modify operations are performed separately on the same event, these Order Modify events should be recorded separately. For example, if a client order was originally traded as ’agency’, but later the client requested for a guaranteed price of the whole order, the intended trading capacity should be modified to ’principal’ using an Order Modify event.

As Execution Venue is not one of the Material Terms, no Order Modify event is required if an order is rerouted. E.g., if a client order was originally sent to an exchange, but later cancelled by an In-Scope Broker’s trader and crossed in an ALP, such changes should be recorded as Split events (please refer to Section 3.1.4 for details).

The Order Cancel events should be used whenever an order is cancelled. For mass cancel requests to exchanges in exception scenarios (e.g. a Kill Switch or Cancel on Disconnect), although these requests are not on order level, the result is that individual exchange-side orders are cancelled back to the In- Scope Broker’s trading systems. Thus, these events should be recorded using Order Cancel events on the client orders as unsolicited cancels.

A ’Mass Cancelled’ flag (massCancelled) should also be used if the In-Scope Broker can provide this indicator.

The Split New event denotes a ’child order split’ of a parent order. Throughout the order life cycle, regardless of the number of times the order is split while traversing through trading systems or technology stacks, only the order splits that may receive executions from Execution Venues are required to be recorded with the Split New event. For the avoidance of doubt, child order splits that are eventually not executed are still required to be recorded. Child order splits for Internalised Trades are not strictly required if the orderCapacity of the child order split is the same as the parent order’s orderCapacity.

For order handling which does not typically split an order into smaller orders and/or change any Material Terms before sending the order to an exchange for execution, a Split New event is not required.

The Split Modify event should be used when any Material Term of a child order split is modified. An example of a Split Modify event would be when an Algo child order split sent to an exchange has its order price modified by the Algo due to market movements.

The Split Cancel event should be used when a corresponding child order split is cancelled, including unsolicited cancellations by an exchange. Please refer to Section 3.1.3 in respect of mass cancel requests sent to exchanges.

The Execution event denotes a ’trade report’ for each client order from an Execution Venue. Execution events should be linked to corresponding Order events via LOID. Linkage to the immediate order or split order IDs is not required. If trade details are subsequently amended or cancelled, this should be recorded using an Execution Correction event (please refer to Section 3.1.8 for details).

Internalised Trades

Internalised Trades refer to:

• Trades that are executed internally, such as by internal crosses, ALP matches and manual fills; or
• Post-execution allocations of aggregated orders (please refer to Section 3.1.9 for details).

For these executions, the internalisedTrade field is set as ‘true’.

Agency Cross Trades

When an order is executed by crossing orders between agency clients, either through an ALP or via manual internal crossing, the crossTrade field should be set as ‘true’ with executionCapacity set as ‘XA - Cross as Agency’. The counterpartyID field should indicate the actual counterparty of the cross in the corresponding Execution events on both sides.

Facilitated Trades from In-Scope Broker’s Own Inventory

For Internalised Trades filled by the In-Scope Broker’s own inventory, this should be denoted by an Execution event with the internalisedTrade field set as ‘true’. The crossTrade field should be set as ‘true’ with executionCapacity set as ’XP - Cross as Principal’. The tradeBookID field should indicate the internal book of the In-Scope Broker which has provided the inventory.

Post-execution Allocations of Aggregated Orders

Where orders have been aggregated and executed orders need to be allocated to the constituent client orders, the client-side executions should be denoted with internalisedTrade set as ‘true’. Also, the sourceExecVenue should provide the Execution Venue on which the market side executions have taken place. E.g. If the executionVenue field on an aggregated order shows XHKG, the executionVenue fields of the constituent orders should show the same.

Orders executed with mixed Execution Capacity

In the case of an Internalised Trade where the In-Scope Broker has assumed different types of execution capacity, the individual executions must be recorded separately. E.g., where a client order is partially filled by internal cross with an order from another agency client, the executionCapacity field should show XA; where this order is partially filled from the In-Scope Broker’s own inventory, the executionCapacity field should show XP.

Odd Lot or Special Lot Executions

Odd lot or special lot fills are commonly provided to clients by In-Scope Brokers as Internalised Trades (internalisedTrade=true). In such cases, these trades should be recorded as principal cross trades (i.e., crossTrade=true, executionCapacity=XP), and with executionVenue=XOFF14, oddLotTrade=true. The orderCapacity field should however remain as ’A’ indicating that the intention of the order is to be traded as agency regardless of how that order is filled.

In case an odd lot or special lot is filled via an exchange facility directly (e.g. semi-automatic matching for odd lot or special lot via HKEX), this should be recorded as an exchange execution, i.e. crossTrade=false, executionCapacity=A, executionVenue=XHKG, and with oddLotTrade=true.

The Execution Correction event denotes the ’corrected’ execution details (i.e., executed price and/or quantity) on a summary basis. This event is applicable where the execution is either amended or cancelled and there should be only one single Execution Correction event per parent order which might consist of multiple child order splits and executions.

When performing execution amendment or cancellation to an order, In-Scope Brokers should not present the workflow specifics illustrating how executions are corrected but only the outcome of a correction. i.e., regardless of whether a correction is performed by (i) directly amending one or more existing execution details, (ii) allocating the executions first to an In-Scope Broker’s error account and providing a new execution for the order, or (iii) via any other method. If a correction is performed more than one time, only the final correction of the day needs to be presented in the DS-OL format. There should be no additional Execution event for an order after the Execution Correction event.

The Allocation event should be used for ’aggregated orders’ only. When an aggregated order is partially or fully filled, these fills shall be allocated to the constituent client orders. Allocation events are recorded after all the Execution events of an aggregated order, with direct linkage to the client orders’ LOID using allocToLOID, and showing allocated quantity in the allocQty field. One Allocation event refers to one client order’s allocation, hence multiple Allocation events are expected for each aggregated order.

The Order Summary event is not part of the configuration of an order life cycle. Instead it is created to provide a record of the end of day summary of an order primarily for ease of identification and validation. Unlike the other events, Order Summary events are not necessarily the events which occur within a front-office system.

For each parent order completed within the same day, only one Order Summary event is required to provide information related to that order at the end of the order life cycle. Total executed quantity (totalExecutedQty) and averaged price (avgExecutedPrice) should be based on the final quantity and price to be settled with the client. For multi-day orders, however, an Order Summary is required which gives a summary of the multi-day order as of each corresponding end-of-day during its life cycle.

The orderCapacity field in an Order Summary event allows additional value ’AP’ which can be used to indicate when a client order is intended to trade partially in an agency capacity and partially in a principal capacity.

Order Summary events are not required on aggregated orders but are required on the constituent client orders.

The Supplementary Event is not one of the order life cycle events. The supplementary Event record is only used to hold additional data for specific fields which can contain multiple delimited values where the total length of the data to be recorded exceeds the specified field length limit.

To construct a supplementary record, please note the following:

• the event type field is denoted by appending supplemented event type with ’S’. E.g., ONEWS for an ONEW supplement
• the supplementary event record should have the same logicalOrderID as the supplemented event
• the supplementary event record should have the same timestamp as the supplemented event in eventDateTime field and use eventSequence field to denote the sequence
• individual value or key/value pairs must be kept as whole records in an event field (i.e., break the data only by removing a delimiter) Assuming a field can only hold up to 2 key/value pairs in the following example, the string ’key1=value1|key2=value2|key3=value3’, should be broken up into ’key1=value1|key2=value2’ and ’key3=value3’
• the supplementary event must be recorded on a line that immediately follows the line that records the supplemented event in the same data file provided to the SFC
• there can be as many supplementary events as needed to hold all the data

The Supplementary Event is not one of the order life cycle events. The supplementary Event record is only used to hold additional data for specific fields which can contain multiple delimited values where the total length of the data to be recorded exceeds the specified field length limit.

To construct a supplementary record, please note the following:

• the event type field is denoted by appending supplemented event type with ’S’. E.g., ONEWS for an ONEW supplement
• the supplementary event record should have the same logicalOrderID as the supplemented event
• the supplementary event record should have the same timestamp as the supplemented event in eventDateTime field and use eventSequence field to denote the sequence
• individual value or key/value pairs must be kept as whole records in an event field (i.e., break the data only by removing a delimiter) Assuming a field can only hold up to 2 key/value pairs in the following example, the string ’key1=value1|key2=value2|key3=value3’, should be broken up into ’key1=value1|key2=value2’ and ’key3=value3’
• the supplementary event must be recorded on a line that immediately follows the line that records the supplemented event in the same data file provided to the SFC
• there can be as many supplementary events as needed to hold all the data

The Supplementary Event is not one of the order life cycle events. The supplementary Event record is only used to hold additional data for specific fields which can contain multiple delimited values where the total length of the data to be recorded exceeds the specified field length limit.

To construct a supplementary record, please note the following:

• the event type field is denoted by appending supplemented event type with ’S’. E.g., ONEWS for an ONEW supplement
• the supplementary event record should have the same logicalOrderID as the supplemented event
• the supplementary event record should have the same timestamp as the supplemented event in eventDateTime field and use eventSequence field to denote the sequence
• individual value or key/value pairs must be kept as whole records in an event field (i.e., break the data only by removing a delimiter) Assuming a field can only hold up to 2 key/value pairs in the following example, the string ’key1=value1|key2=value2|key3=value3’, should be broken up into ’key1=value1|key2=value2’ and ’key3=value3’
• the supplementary event must be recorded on a line that immediately follows the line that records the supplemented event in the same data file provided to the SFC
• there can be as many supplementary events as needed to hold all the data

The Supplementary Event is not one of the order life cycle events. The supplementary Event record is only used to hold additional data for specific fields which can contain multiple delimited values where the total length of the data to be recorded exceeds the specified field length limit.

To construct a supplementary record, please note the following:

• the event type field is denoted by appending supplemented event type with ’S’. E.g., ONEWS for an ONEW supplement
• the supplementary event record should have the same logicalOrderID as the supplemented event
• the supplementary event record should have the same timestamp as the supplemented event in eventDateTime field and use eventSequence field to denote the sequence
• individual value or key/value pairs must be kept as whole records in an event field (i.e., break the data only by removing a delimiter) Assuming a field can only hold up to 2 key/value pairs in the following example, the string ’key1=value1|key2=value2|key3=value3’, should be broken up into ’key1=value1|key2=value2’ and ’key3=value3’
• the supplementary event must be recorded on a line that immediately follows the line that records the supplemented event in the same data file provided to the SFC
• there can be as many supplementary events as needed to hold all the data

The Supplementary Event is not one of the order life cycle events. The supplementary Event record is only used to hold additional data for specific fields which can contain multiple delimited values where the total length of the data to be recorded exceeds the specified field length limit.

To construct a supplementary record, please note the following:

• the event type field is denoted by appending supplemented event type with ’S’. E.g., ONEWS for an ONEW supplement
• the supplementary event record should have the same logicalOrderID as the supplemented event
• the supplementary event record should have the same timestamp as the supplemented event in eventDateTime field and use eventSequence field to denote the sequence
• individual value or key/value pairs must be kept as whole records in an event field (i.e., break the data only by removing a delimiter) Assuming a field can only hold up to 2 key/value pairs in the following example, the string ’key1=value1|key2=value2|key3=value3’, should be broken up into ’key1=value1|key2=value2’ and ’key3=value3’
• the supplementary event must be recorded on a line that immediately follows the line that records the supplemented event in the same data file provided to the SFC
• there can be as many supplementary events as needed to hold all the data

The Supplementary Event is not one of the order life cycle events. The supplementary Event record is only used to hold additional data for specific fields which can contain multiple delimited values where the total length of the data to be recorded exceeds the specified field length limit.

To construct a supplementary record, please note the following:

• the event type field is denoted by appending supplemented event type with ’S’. E.g., ONEWS for an ONEW supplement
• the supplementary event record should have the same logicalOrderID as the supplemented event
• the supplementary event record should have the same timestamp as the supplemented event in eventDateTime field and use eventSequence field to denote the sequence
• individual value or key/value pairs must be kept as whole records in an event field (i.e., break the data only by removing a delimiter) Assuming a field can only hold up to 2 key/value pairs in the following example, the string ’key1=value1|key2=value2|key3=value3’, should be broken up into ’key1=value1|key2=value2’ and ’key3=value3’
• the supplementary event must be recorded on a line that immediately follows the line that records the supplemented event in the same data file provided to the SFC
• there can be as many supplementary events as needed to hold all the data