On FIX 4.2 version, I would like to have the confirmation that the following workflow is not FIX compliant :
1 - Order new sent
2 - Execution report new received containing tags 39=0 and 150=0
3 - Later, execution report reject received containing tags 39=8 and 150=8
From my understanding, we should not receive an execution report reject but an execution report cancelled/eliminated containing tags 39=4 and 150=4
Without a fuller description of the actual use case, that is a valid sequence you listed for step 3. A “rejection” of an order for various reasons is a different activity than a “cancel” of an order. Sending 39=4 and 150=4 after the 39=0 and 150=0 implies the order was cancelled due to some instruction (e.g. cancel request was via voice, cancelled because of TimeInForce, etc.) This is distinctly different than the recever rejecting an order.
You might want to take a look at the Order State Change Matrices Order State Changes – FIX Trading Community for some guidance. Keep in mind that these are not meant to exhaustive.
What was the 39=8 and 150=8 ExecReport in response to?
Was it on a NewOrderSingle or was it on a Cancel (35=F) or a Cancel Replace Request(35=G)?
I’ve seen a 39=8 and 150=8 response on a NewOrderSingle Msg after the counterparty responds with a Pending New Status of 150=A and 39=A.
If it was in response to either a 35=F or 35=G Msg: Ona FIX 4.2 Connection we should get a Cancel Reject Msg: 35=9 in response to the cancel request itself, with the OrdStatus 39 = to the status of order prior to the C/R request.
A 35=8 with a 150=9 | 39=9 is a flat out Order Rejected Status to the 35=D Message and therefore the order is not live.
The Order State Change Diagrams for Exchanges shows the following transitions are possible:
New —> Cancel from Book → Canceled
New —> Reject of Accepted Order → Rejected
So that would suggest both scenarios are valid.
The difference between a cancel and a reject is that the order submitter cancels an existing order (with OrderCancelRequest(35=F)) and the receiver of an order can reject a new order (with ExecutionReport(35=8)). Orders may also be subject to an unsolicited cancellation initiated by the receiver of an order.
@martinat whilst it is correct that the order status can change from New to Canceled as well as from New to Rejected, the related workflows are quite different. The use case described by @coocz says that the workflow started with a NewOrderSingle(35=D), requesting the entry of a new order. FIX requires a response to this message and in this case it was an ExecutionReport(35=8) with OrdStatus(39)=0 (New) and ExecType(150)=0 (New).
That means that the order was accepted by the counterparty. It can no longer be rejected. As pointed out by @mparente2, this would only be possible if the first response had been with OrdStatus(39)=A (Pending New) and ExecType(150)=A (Pending New). An order status of 8=Rejected can thus not be reached with the given workflow.
An order status of 4=Canceled can be reached from a status of 0=New if the order submitter sends an OrderCancelRequest(35=F) or if there was an unsolicited cancellation. There was no such request between steps 2 and 3 in the workflow shown by @coocz. Hence, if step 3 represents an unsolicited cancellation by the order receiver, then the correct response would have been an ExecutionReport(35=8) with OrdStatus(39)=4 (Canceled) and ExecType(150)=4 (Canceled), together with ExecRestatementReason(378) to explain the reason behind the unsolicited cancellation.
@coocz can you confirm whether step 3 was indeed an unsolicited cancellation?
I beg to differ on this. I have seen too many cases of ExecType=0 (New) OrdStatus=0 (New) to mean a system level acceptance (e.g. at the FIX gateway) and still be rejected once the order reaches the application or goes through additional business level validation even before the OMS/EMS receives it. Unfortunately many implementations don’t use “Pending new” and likely it is because it is a little ambiguous as to what it actually means. The “pending new” gets skipped often even way back to the early days of FIX 3.0. And yes I agree the Order State matrices are silent on this particular scenario.
Hi,
Please find below the details of my case :
@ 9h35’40’’ we sent a new order on an US equities to our broker
@ 9h35’41’’ the broker sent us an execution report ack containing 39=0/150=0
@13h10’00’’ the broker sent us an execution report reject containing 39=8/150=8
So, we never received any pending new message.
And the broker explained that, due to the time, the order was placed in a queue (as the OMS managing orders on US exchanges was not up and running at this time).
The ack sent by the broker is more a “technical” ack and not an ack from the OMS.
Then, at the start of their OMS, the order was rejected (for a good reason) and an execution report reject was sent by the broker.
@coocz, I need to revise my earlier statement on not being able to reject an order once it has been accepted. Apologies for the confusion. The FIX Protocol Specification does foresee this possibility, both in general (see the table) and in the context of exchanges (see the diagram).
The OrdStatus(39) of 8=Rejected can be reached both from an OrdStatus(39) of A=Pending New and 0=New. However, those are the only ones. You need to find out if your counterparty uses A=Pending New or 0=New for a technical ack of an order that may still be rejected, e.g. because the market was not open yet. In both cases you hence have to be prepared for a rejection until OrdStatus(39) changes to another state.