Order Cancel/Replace Request  (MsgType = G)

The Order Cancel/Replace Request (G) 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 (F) 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 (38) .

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

The Order Cancel/Replace Request (G) 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 (9) message. The Cancel Reject (9) message should provide the ClOrdID (11) and OrigClOrdID (41) values which were specified on the Cancel/Replace Request (G) message for identification.

Note that while it is necessary for the ClOrdID (11) to change and be unique, the broker's OrderID (37) field does not necessarily have to change as a result of the Cancel/Replace Request (G) .

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 an Order Cancel/Replace Request (G) 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 (41) to the last non rejected ClOrdID (11) sent
• The order receiver should chain client order ids on a "pessimistic" basis, i.e. set the OrigClOrdID (41) on execution reports that convey the receipt or succesful application of a cancel/replace and Order Cancel Reject (9) messages to be the last "accepted" ClOrdID (11) (See Volume 4: "Order State Change Matrices" of FIX specification 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 (G) , 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 (54) 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 (54) , SettlDate (64) , etc. to change. Sell-side firms should validate the Order Cancel/Replace Request (G) 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 (9) message with CxlRejReason (102) = 2 (Broker/Exchange Option).

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