| ID | 19870 |
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.
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. | |||
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. | ||||
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. | |||
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. | |||
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. | |||
54 | ’true’ indicates that orders are cancelled due to mass cancel requests sent by the In- Scope Broker to an exchange in exception scenarios. This is not intended for client- side mass cancel request. Not required if this information is not captured by the In- Scope Broker. |
Orchimate Copyright 2026 Atomic Wire Technology Limited
Orchestra Copyright 2026 FIX Protocol Ltd
Terms of Service|Privacy Policy