| ID | 10571 |
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).
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. | ||||
33 | The date and time that the acknowledgement or response was sent to the upstream system or to the client. | ||||
34 | Y | Indicates the type of logical response of the recorded Order or Split event. If the Order or Split event has no actual response, use the 'null' filler (i.e. null). | |||
35 | Text associated with an event response to record any additional details (e.g. the reject reason in the case of a rejection). | ||||
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. | |||
68 | Indicates the original order ID on Modify event if the order ID changes after the modification. This field is not necessary if such order ID does not change after modification. | ||||
70 | Indicates the order ID received from a client. For orders not created electronically or if the client side does not provide the order ID, this field is not required. | ||||
69 | Indicates the original order ID received from a client in an Order Modify event if that received order ID changes after the modification. It is not needed if such order ID does not change after modification. | ||||
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. | |||
2 | The account ID assigned to an order. This must map to the In-Scope Broker’s Reference Data Dictionary. Not required if the account is not known, or it is an aggregated order. | ||||
16 | Y | Key string used to identify the client defined by the In-Scope Broker. This must map to the In-Scope Broker’s Reference Data Dictionary provided by the broker which may include other client-related identification such as LEI, entity name, or other detailed information about the client or internal desk. Not required if it is an aggregated order. | |||
60 | In Order and Split events, it indicates the intended trading capacity of an order, i.e 'A - agency' or 'P - principal'. In Order Summary event, it also allows additional value 'AP - agency/principal' to indicate cases when an order is intended to trade partially in an agency capacity and partially in a principal capacity. | ||||
65 | The price value for limit based order types, for market order types, a 'zero' value should be used. | ||||
66 | For day orders, it is the quantity of the order. For multi-day orders, this can be the rolled over quantity from the previous trading day or the original order quantity. In Modify events, this indicates the intended or target order quantity of the modification, regardless of whether the order was partially filled or not. | ||||
67 | Indicates the type of order as defined by the enumeration specifications. | ||||
80 | Indicates the lifetime of the order, e.g. today only, valid until specified date, valid until it is cancelled or completed, as defined by the Data Standards enumeration specifications. | ||||
aggregatedOrders | If multiple orders are aggregated into a new single order for trading, then this field contains the list of those orders' logicalOrderIDs and respective quantities which make up the aggregated order. | ||||
collectionID | A free text field as a unique identifier for a 'collection of orders'. (Please refer to Section 3.1.7.4 for details.) | ||||
8 | The key value of the referenced Algo strategy, e.g. 'VWAP', 'percentage of volume', etc. as defined by the In-Scope Broker. | ||||
6 | Algo parameters as part of order requests as specified by the client. The In-Scope Broker can concatenate all specified parameters into a single string with proper delimiters. | ||||
44 | Used in conjunction with GTD orders to indicate the order expiry date. | ||||
63 | Indicates any In-Scope Broker defined order instruction that is not already captured in the orderType and/or algoAttributes fields. This must map to the In-Scope Broker’s Reference Data Dictionary. | ||||
47 | Captures any free text fields on an order new or modify message. This usually contains information from client order instructions, or inter-desk instructions other than the data supplied in the orderInst field. For a child order split that does not have its own instructions, copy the value from its parent order if available. | ||||
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. | ||||
50 | Y | Indicates the initiator of a modify or cancel event, e.g. 'Broker' is shown as the initiator when a partially-filled Algo order is cancelled by the Algo automatically because the market is closed whereas 'Client' is shown when a partially-filled Algo order is cancelled upon a client request. |
Orchimate Copyright 2026 Atomic Wire Technology Limited
Orchestra Copyright 2026 FIX Protocol Ltd
Terms of Service|Privacy Policy