From FIXwiki
Jump to: navigation, search

FIX Message OrderCancelReplaceRequest (MsgType=G)

MsgType FIX Specification First introduced
MsgType=G Trade messages - SingleGeneralOrderHandling FIX.2.7

The order cancel/replace request is used to change the parameters of an existing order.

Do not use this message to cancel the remaining quantity of an outstanding order, use the Order Cancel Request message for this purpose.

Cancel/Replace will be used to change any valid attribute of an open order (i.e. reduce/increase quantity, change limit price, change instructions, etc.), Subject to agreement between counterparties, it can be used to re-open a filled order by increasing OrderQty.

An immediate response to this message is required. It is recommended that an ExecutionRpt with ExecType=Pending Replace be sent unless the Order Cancel/Replace Request can be immediately accepted (ExecutionRpt with ExecType=Replace) or rejected (Order Cancel Reject message).

The Cancel/Replace request will only be accepted if the order can successfully be pulled back from the exchange floor without executing. Requests which cannot be processed will be rejected using the Cancel Reject message. The Cancel Reject message should provide the ClOrdID and OrigClOrdID values which were specified on the Cancel/Replace Request message for identification.

Note that while it is necessary for the ClOrdID to change and be unique, the broker"s OrderID field does not necessarily have to change as a result of the Cancel/Replace request.

The protocol supports the chaining of multiple cancel/replace requests, though trading counterparties may not support this functionality. Care should be taken if the order sender wishes to send a cancel/replace request when there is one or more cancel/replaces which have not been accepted or rejected - in general:

  • The order sender should chain client order ids on an "optimistic" basis, i.e. set the OrigClOrdID to the last non rejected ClOrdID sent
  • The order receiver should chain client order ids on a "pessimistic" basis, i.e. set the OrigClOrdID on execution reports that convey the receipt or succesful application of a cancel/replace and Order Cancel Reject messages to be the last "accepted" ClOrdID (See "Order State Change Matrices" for examples of this)

In the event that the order sender wants to chain order cancel/replaces rapidly then they should ensure that each replace request contains the full details of the order as they would now like it to be. For example if an attempt is made to change the limit price and then an immediate request to change the quantity is issued then if the desired behaviour is that both the limit price and quantity should be changed then the second request should include the revised limit price (in case the first replace request is rejected).

All of the application-level fields in the original order should be retransmitted with the original values in the Order Cancel/Replace Request, except the fields that are being changed. Any field may be changed with this message except those in the Instrument component block and limited changes to the Side field (noted below), however, buy-side firms should note that sell-side firms may further restrict which fields they allow to change; hence bilateral agreement is required. For example, some sell-side firms may not allow fields such as Side, SettlDate, etc. to change. Sell-side firms should validate the Order Cancel/Replace Request to ensure that the client is not requesting a change for a field that the sell-side cannot change; in this case the sell-side should send a Cancel Reject message with CxlRejReason = 2 (Broker/Exchange Option).

When modifying ExecInst values in a replacement order, it is necessary to re-declare all ExecInst in the replacement order. ExecInst values will not be carried forward from the original order to the replacement unless re-declared.

Message Contents By FIX Version


Always provide the desired total quantity and not the remaining or a delta quantity in the field OrderQty within an OrderCancelReplaceRequest. The recipient then calculates the remaining quantity based on previous fills. The modification is to be interpreted as an implicit deletion if the desired total quantity is below the quantity that has already been filled. This can happen if there are additional fills while the submitter sends his request.