Imported from previous forum
Thanks Cindy, but it the flow “legal” according to FIX Protocol?
35=D -->
35=G -->
<–150=A,39=A
<–150=E,39=0
<–150=5,39=5
any partial fill <–150=1,39=1
and finally fully fill <–150=2,39=2
tag39 describe the overall order status while tag150 describe the current execution report
Hi Guys, I have a broker that is sending my EMS a strange message flow and from all my research I am still not clear if this is an acceptable flow according to FIX Protocol.
35=D—>
35=G—>
<—150=E, 39=E
<—150=5, 39=A
<—150=0, 39=5
<—150=1, 39=1
I realize that the message flow makes sense if reading as just normal logic flow, but is it in accordance with FIX Protocol?
Mark,
first, two general comments. Please always indicate the FIX version (apparently FIX 4.2) and use names of messages, fields and valid values instead of only the values. That makes it much more legible.
NewOrderSingle 35=D—>
OrderCancelReplaceRequest 35=G—>
<—150=E (Pending Replace), 39=E (Pending Replace)
<—150=5 (Replace), 39=A (Pending New)
<—150=0 (New), 39=5 (Replaced)
<—150=1 (Partial Fill), 39=1 (Partially Filled)
The answer to your question needs to include the FIX rules governing the flow. “Compliant” is a better term than “Legal” to express whether something follows the standard or not.
Use case: A new order is entered, followed by a request to modify it prior to receiving any response from the recipient. Additionally, the order is partially filled by the recipient before/after(?) the modification.
Definitions: ExecType(150) contains the reason for the ExecutionReport to be sent (message-specific). OrdStatus(39) contains the status of the order at the time the ExecutionReport was sent (entity-specific). Note the subtle differences between the names of valid values that look identical.
Rule 1: Responses have to be provided in the order that the actions were taken by the recipient.
==> Rule was violated as an order cannot be pending replace before it is has been created. Recipient confirms the actions in the wrong order.
Rule 2: In FIX 4.2, actions have to be reported separately (no bundling allowed)
==> Rule was violated in multiple ways. The order was never confirmed as a new order with OrdStatus=New. The ER with ExecType=New had OrdStatus=Replaced which combines an entry with an immediate replacement.
If I take your use case then the recipient seems to have started his processing with the latest request from you. It needs to start with the first request. I do not see a need to use an OrdStatus “Pending New” (which would also require a second message with OrdStatus=”New”). If the partial fill happens AFTER the modification it looks very easy.
NewOrderSingle 35=D—>
OrderCancelReplaceRequest 35=G—>
<—150=0 (New), 39=0 (New)
<—150=5 (Replace), 39=5 (Replaced)
<—150=1 (Partial Fill), 39=1 (Partially Filled)
If the partial fill happens BEFORE the modification (but after receiving the modification request), you need to respond with the pending nature of the order first before comfirming the partial fill and then also the modification. Note that the partial fill is reported with a different order status due to the order status precedence rules as defined for FIX 4.2.
NewOrderSingle 35=D—>
OrderCancelReplaceRequest 35=G—>
<—150=0 (New), 39=0 (New)
<—150=E (Pending Replace), 39=E (Pending Replace)
<—150=1 (Partial Fill), 39= E (Pending Replace)
<—150=5 (Replace), 39=5 (Replaced)
Maybe the exact use case is neither of the above but that would require information from the recipient. Please also take a look at the examples in the FIX 4.2 specification Appendix D (http://www.fixtradingcommunity.org/pg/file/fplpo/read/30027/fix-42-specification-documents-pdf)