CODEWITHSUNDEEP
fix-protocol
user12595630
user12595630

Reputation: 1

How FIX Protocol handles chain of request

I have a question regarding FIX Protocol and I'm quite new to it.

A client sent an order and it got accepted by the broker. After that, the client sent a request (request #1) to modify the quantity to x. However, before request #1 is accepted, the client sent another modification request (request #2) to modify the quantity to y.

I search the documentation of FIX Protocol and find these.

  • 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 "Order State Change Matrices" for examples of this)

However, I still don't understand how FIX Protocol handles request. Will the quantity be modified to y? Or does it depend on which request is being accepted last?

Upvotes: 0

Views: 902

Answers (1)

Christoph John
Christoph John

Reputation: 3283

You need to understand that the FIX Protocol is a set of guidelines on how someone who implements the protocol should handle certain scenarios. In practice there are differences in how counterparties handle this.

In your example the quantity should be modified to y in the end. But the quantity will be modified to x first since that message was received at first.

Here are some chaining examples taken from the spec: https://www.onixs.biz/fix-dictionary/4.4/app_d.html (search for sequencing or chaining)

Here are examples specific to your question where two consecutive replace requests are handled: https://www.onixs.biz/fix-dictionary/4.4/app_dD.2.a.html
https://www.onixs.biz/fix-dictionary/4.4/app_dD.2.b.html

Upvotes: 4

Related Questions