Order History In FIX4.2

, ,
1

Imported from previous forum

2

Hi All,
I have a question about the handling of an order history mechanism in FIX4.2 protocol. Following is the case in chronological order:

  1. Broker places an order with Quantity 10 which gets confirmed with the exchange.
  2. Broker places Order Cancel/Replace Request with Quantity 15 and immediately after placing the request he gets disconnected. The order is received and gets confirmed by the Exchange but the Replaced Execution Report could not be sent to the broker due to his disconnection.
  3. Subsequently, this order gets partially traded with executed Quantity 5.

My question is on subsequent connection, should the Broker receive three ERs with

  1. OrdStatus (Tag 39) = Replaced and ExecType (Tag 150) = Replaced (Order Execution Report in response to the previously placed Cancel/Replace Request just before disconnection).
  2. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Replaced with ExecTransType (Tag 20) = 3 (Status)(Final status report for an order on subsequent log on to the system).
  3. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Partially Filled (Trade Execution Report).

Or two ERs:

  1. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Replaced with ExecTransType (Tag 20) = 3 (Status)(Final status report for an order on subsequent log on to the system).
  2. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Partially Filled (Trade Execution Report).
3

A disconnection should not affect the application layer, only the session layer, i.e. the application should not behave any differently and rely on the FIX engine to close any gaps in the transmission. After the connection has been reestablished and the broker receives the next message, his FIX engine will detect the gap and request a retransmission of the messages he missed before handing the first message after the gap up to the application.

So it should be neither of your scenarios but 3 ERs and ExecTransType=New for all of them.

Hi All,
I have a question about the handling of an order history mechanism in FIX4.2 protocol. Following is the case in chronological order:

  1. Broker places an order with Quantity 10 which gets confirmed with the exchange.
  2. Broker places Order Cancel/Replace Request with Quantity 15 and immediately after placing the request he gets disconnected. The order is received and gets confirmed by the Exchange but the Replaced Execution Report could not be sent to the broker due to his disconnection.
  3. Subsequently, this order gets partially traded with executed Quantity 5.

My question is on subsequent connection, should the Broker receive three ERs with

  1. OrdStatus (Tag 39) = Replaced and ExecType (Tag 150) = Replaced (Order Execution Report in response to the previously placed Cancel/Replace Request just before disconnection).
  2. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Replaced with ExecTransType (Tag 20) = 3 (Status)(Final status report for an order on subsequent log on to the system).
  3. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Partially Filled (Trade Execution Report).

Or two ERs:

  1. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Replaced with ExecTransType (Tag 20) = 3 (Status)(Final status report for an order on subsequent log on to the system).
  2. OrdStatus (Tag 39) = Partially Filled and ExecType (Tag 150) = Partially Filled (Trade Execution Report).