This is the Client supplied order identifier. The Server will maintain this order identifier throughout the life of the order and always provide it back through the ClientOrderID field in the ORDER_UPDATE messages for the order.

This identifier cannot be an identifier used for a currently open order and it cannot be an identifier previously used in the current trading session. The trading session typically will be a 24-hour period defined by the Server. The Server shall reject an order with a client order identifier that is for a currently open order or which has already been used during the current trading session.

The Client will set this to 1 when the order is part of a bracket order. This indicates that this is the parent order. A bracket order will consist of a SUBMIT_NEW_SINGLE_ORDER message followed by a SUBMIT_NEW_OCO_ORDER message. The Server will use IsParentOrder as a flag to know that this message is a parent order. The Server will hold onto this order until it receives the subsequent SUBMIT_NEW_OCO_ORDER message and then process all of the orders as one complete set.

Optional: This is an optional text string which can be set by the Client to associate text with the order. The Server is not under any obligation to use this text and it may place a limitation on the length of this text.

The SUBMIT_NEW_SINGLE_ORDER_INT message is identical to SUBMIT_NEW_SINGLE_ORDER except that the order prices are as integers.

The Client will only send this message to the Server if UseIntegerPriceOrderMessages is set in the LOGON_RESPONSE message.

When setting the Price1 and Price2 fields, multiply the order price by the FloatToIntPriceMultiplier value provided in the SECURITY_DEFINITION_RESPONSE message for the Symbol being traded.

This message also contains the Divisor field. This is the FloatToIntPriceMultiplier value provided in the SECURITY_DEFINITION_RESPONSE message for the symbol being traded. The Server needs to divide the Price1 and Price2 fields by this Divisor to get the prices as float values.

This is the Client supplied order identifier. The Server will maintain this order identifier throughout the life of the order and always provide it back through the ClientOrderID field in the ORDER_UPDATE messages for the order.

This identifier cannot be an identifier used for a currently open order and it cannot be an identifier previously used in the current trading session. The trading session typically will be a 24-hour period defined by the Server. The Server shall reject an order with a client order identifier that is for a currently open order or which has already been used during the current trading session.

This is the FloatToIntPriceMultiplier value provided in the SECURITY_DEFINITION_RESPONSE message for the symbol being traded. The Server needs to divide the Price1 and Price2 fields by this Divisor to get the prices as float values.

The Client will set this to 1 when the order is part of a bracket order. This indicates that this is the parent order. A bracket order will consist of a SUBMIT_NEW_SINGLE_ORDER message followed by a SUBMIT_NEW_OCO_ORDER message. The Server will use IsParentOrder as a flag to know that this message is a parent order. The Server will hold onto this order until it receives the subsequent SUBMIT_NEW_OCO_ORDER message and then process all of the orders as one complete set.

Optional: This is an optional text string which can be set by the Client to associate text with the order. The Server is not under any obligation to use this text and it may place a limitation on the length of this text.

SUBMIT_NEW_OCO_ORDER [s_SubmitNewOCOOrder structure] Client >> Server

This is a message from the Client to the Server for submitting an order cancels order (OCO) pair into the market. What this means is when one of the orders is filled or canceled, the other order will be canceled. If one order partially fills, the other order will be reduced in quantity by the fill amount of the order that partially filled.

A service provider must implement OCO orders on the server so that they can independently be modified (Cancel/Replace) and canceled independently using each order's distinct ServerOrderID. Although, if one of the orders is canceled by the Client, the other order will be canceled as well unless they have a parent order, as specified through the ParentTriggerClientOrderID field, in which case the other order should remain open.

If the OCO order pair is rejected, this must be communicated through two separate ORDER_UPDATE messages, 1 for each order, with the OrderUpdateReason set to NEW_ORDER_REJECTED.

Optional: This is an optional text string which can be set by the Client to associate text with each of the OCO orders. The Server is not under any obligation to use this text and it may place a limitation on the length of this text.

This field is only relevant to a Bracket order which is the case when the ParentTriggerClientOrderID field is set.

UseOffsets can be set to 1 and indicates that the OffsetFromParent1 and OffsetFromParent2 fields specify the two OCO order prices as a price offset from the parent order price, rather than an absolute price. In this case Price1_1 and Price1_2 are not used.

When UseOffsets is set to 0, the default, then the OCO order prices are specified with Price1_1 and Price1_2.

When UseOffsets is set to 1, then this field specifies the Price1_1 price as an offset from the parent order. In this case Price1_1 will not be set in the message. Instead the Server calculates that price from this offset and parent order price.

This needs to always be set to a positive price value which is an offset from the parent order price. The Server will make the correct calculation based upon the Side and Order Type.

When UseOffsets is set to 1, then this field specifies the Price1_2 price as an offset from the parent order. In this case Price1_2 will not be set in the message. Instead the Server calculates that price from this offset and parent order price.

This needs to always be set to a positive price value which is an offset from the parent order price. The Server will make the correct calculation based upon the Side and Order Type.

The SUBMIT_NEW_OCO_ORDER_INT message is identical to SUBMIT_NEW_OCO_ORDER except that the order prices are as integers.

The Client will only send this message to the Server if UseIntegerPriceOrderMessages is set in the LOGON_RESPONSE message.

When setting the Price1 and Price2 fields, multiply the order price by the FloatToIntPriceMultiplier value provided in the SECURITY_DEFINITION_RESPONSE message for the Symbol being traded.

This message also contains the Divisor field. This is the FloatToIntPriceMultiplier value provided in the SECURITY_DEFINITION_RESPONSE message for the symbol being traded. The Server needs to divide the Price1 and Price2 fields by this Divisor to get the prices as float values.

Optional: This is an optional text string which can be set by the Client to associate text with each of the OCO orders. The Server is not under any obligation to use this text and it may place a limitation on the length of this text.

This is the FloatToIntPriceMultiplier value provided in the SECURITY_DEFINITION_RESPONSE message for the Symbol being traded. The Server needs to divide the Price1_* and Price2_* fields by this Divisor to get the prices as float values.

This message is sent by the Client to the Server to cancel and replace an existing order. This is also known as an order modification.

When the cancel and replace operation is completed, an OrderUpdate message is sent by the Server with the OrderUpdateReasonfield set to ORDER_CANCEL_REPLACE_COMPLETE. If the cancel and replace operation cannot be completed, an OrderUpdate message is sent by the Server with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED.

This must be the same throughout the life of the order. If the Server sees that this order identifier has changed in relation to the ServerOrderID, then it should reject this message with a ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED

In the case where the order modification cannot be performed because the ServerOrderID does not exist, the Server will send a ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED and ClientOrderID set to the given ClientOrderID in this message. ServerOrderID will be unset because an invalid server order identifier was given.

The Order Type for the order. For list of Order Types, refer to OrderTypeEnum.

The default value is ORDER_TYPE_UNSET.

When this field is set to a value other than ORDER_TYPE_UNSET, it indicates that the OrderType is being changed.

If the server does not support changing the Order Type, it needs to reject this CANCEL_REPLACE_ORDER message and send an ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED.

The Time in Force for the order. For a list of Time in Force values, refer to TimeInForceEnum.

The default value is TIF_UNSET.

When this field is set to a value other than TIF_UNSET, it indicates that the TimeInForce is being changed.

If the server does not support changing the Time in Force of the order, it needs to reject this CANCEL_REPLACE_ORDER message and send an ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED.

The server is under no obligation to support changing the Time in Force.

When the cancel and replace operation is completed, an OrderUpdate message is sent by the Server with the OrderUpdateReasonfield set to ORDER_CANCEL_REPLACE_COMPLETE. If the cancel and replace operation cannot be completed, an OrderUpdate message is sent by the Server with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED.

This must be the same throughout the life of the order. If the Server sees that this order identifier has changed in relation to the ServerOrderID, then it should reject this message with a ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED

In the case where the order modification cannot be performed because the ServerOrderID does not exist, the Server will send a ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED and ClientOrderID set to the given ClientOrderID in this message. ServerOrderID will be unset because an invalid server order identifier was given.

The Order Type for the order. For list of Order Types, refer to OrderTypeEnum.

The default value is ORDER_TYPE_UNSET.

When this field is set to a value other than ORDER_TYPE_UNSET, it indicates that the OrderType is being changed.

If the server does not support changing the Order Type, it needs to reject this CANCEL_REPLACE_ORDER_INT message and send an ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED.

The Time in Force for the order. For a list of Time in Force values, refer to TimeInForceEnum.

The default value is TIF_UNSET.

When this field is set to a value other than TIF_UNSET, it indicates that the TimeInForce is being changed.

If the server does not support changing the Time in Force of the order, it needs to reject this CANCEL_REPLACE_ORDER_INT message and send an ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REPLACE_REJECTED.

The server is under no obligation to support changing the Time in Force.

This is the order identifier for the order to cancel. The Client needs to set this to the ServerOrderID field received back in the most recent ORDER_UPDATE message for the order. The only case in which a ServerOrderID would change is in the case of a successful order Cancel and Replace operation.

The Server will rely upon this ServerOrderID and only this order identifier to identify the order to be canceled. Although the given ClientOrderID from the Client must not change.

This must be the same throughout the life of the order. If the Server sees that this order identifier has changed in relation to the ServerOrderID , then it should reject this message with a ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REJECTED.

In the case where the order cancellation cannot be performed because the ServerOrderID does not exist, the Server will send a ORDER_UPDATE message with the OrderUpdateReason set to ORDER_CANCEL_REJECTED and ClientOrderID set to the given ClientOrderID in this message. ServerOrderID will be unset because an invalid server order identifier was given.