| ID | 30471 |
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.
31 | Y | The indicator of the event type as defined by the enumeration specifications. | |||
32 | Y | The creation time of the event. In-Scope Brokers should record the most accurate time they can get closest to the actual time. | |||
36 | This field is used in conjunction with the eventDateTime, if the timestamp in eventDateTime is not granular enough to accurately reconstruct the sequence of events. | ||||
53 | Y | An identifier assigned to the top parent order which should be unique throughout its life cycle. | |||
62 | Y | The ID of the order generated by a system, this should be unique during a trading day but can be reused over time. In Split events, it is the order ID of the child order split itself. In Execution events, it is the order ID of the corresponding order or child order. | |||
72 | Y | Indicates the security to be traded by the order, e.g. '0001.HK'. | |||
73 | Y | Specifies the type of the ID used in the securityID field, e.g. RIC, SEDOL, ISIN, etc. as defined by the Data Standards enumeration specifications. | |||
76 | Y | Indicates whether the order is a Buy, Sell, Short Sell or Short Sell Exempt, etc. as defined by the Data Standards enumeration specifications. | |||
42 | Y | Key string for an internal mnemonic used by the In-Scope Broker for an Execution Venue, which can be industry standards such as ISO MIC code, or non-standard venue name as defined by the In-Scope Broker. In both cases, it should map to the In-Scope Broker’s Reference Data Dictionary. This field is not applicable to allocation fills from aggregated orders. | |||
79 | Y | A free text string name or identifier of the primary system recording the event, e.g. OMS, Algo, etc. as defined by the In-Scope Broker. | |||
83 | Indicates the name or identifier of the trader processing or monitoring the order. An In- Scope Broker can use a system user name (or a valid filler value) for automated trade processes such as low touch order. This must map to the In-Scope Broker’s Reference Data Dictionary. | ||||
51 | Y | 'true' indicates an Internalised Trade. | |||
82 | Indicates the code of the trading book that the position was booked under. For manually filled order, this field indicates the internal book used by the In-Scope Broker to manually fill the order from its own inventory. | ||||
21 | Indicates the counterparty for an internally crossed trade, which could be the internal clientID or an exchange 'broker code'. | ||||
23 | Y | ‘true’ indicates that the trade is an internally crossed trade by the In-Scope Broker, either against another agency client or a proprietary desk for facilitated orders. | |||
38 | Y | Specifies the capacity in which the execution was traded, e.g. 'agency', 'principal', 'cross as agency' or 'cross as principal'. | |||
39 | Y | An identifier generated by the In-Scope Broker for individual Execution or Execution Correction events. This field is not necessarily the execution ID provided by an exchange. | |||
40 | Y | The price executed in the market, as a cross, or against an internal book. Use 'zero' in Execution Correction event when cancelling an execution for the client. | |||
41 | Y | In an Execution event, indicates the executed quantity at an Execution Venue. When used in an Execution Correction event, indicates the sum of executed quantity after the correction. | |||
78 | Only required in client-side order executions for executions allocated from an aggregated order to constituent orders. Key string for an internal mnemonic used by the In-Scope Broker to refer to Execution Venue where the order is executed. E.g. if the Execution Venue of an aggregated order is showing executionVenue=XHKG, then the constituent orders should show sourceExecVenue=XHKG. | ||||
56 | 'true' indicates the execution is for an odd lot or a special lot. | ||||
84 | Indicates during which corresponding exchange trading session that off-exchange executions are effected by the In-Scope Broker, e.g. manual fills, internal crossing or ALP executions. |
Orchimate Copyright 2026 Atomic Wire Technology Limited
Orchestra Copyright 2026 FIX Protocol Ltd
Terms of Service|Privacy Policy