This message 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 Order Cancel Request <35=F> instead.

This request can be used to change any valid attribute of an open order, e.g. to reduce or increase quantity, to change limit price, or to change instructions. 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 Execution Report <35=8> with ExecType (150) = "Pending Replace", be sent unless the request can be immediately accepted or rejected.

The request will only be accepted if the order can successfully be pulled from the exchange without executing. Requests which cannot be processed will be rejected using the Order Cancel Reject <35=9> message. The Order Cancel Reject <35=9> message should provide the ClOrdID (11) and OrigClOrdID (41) values which were specified on the request.

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 an accepted 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 owner wishes to send a cancel/replace request when there is any cancel/replace requests which have not yet 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 successful application of a cancel/replace and Order Cancel Reject <35=9> messages to be the last 'accepted' ClOrdID (11)

In the event that an application chains order cancel/replaces rapidly, it should ensure that each request contains the desirable state of the order in full. 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 request is rejected.

All of the application-level fields in the original order should be retransmitted with the original values in the 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 (54) field, noted below. Applications may further restrict which fields are allowed to change, so bilateral agreement is required. For example, some firms may not allow fields such as Side (54) to change. Applications should validate the request to ensure that it does not attempt to change a field that cannot change; if it does, a Order Cancel Reject <35=9> with CxlRejReason (102) = 2 should be sent.

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