Do we need to enforce the sequence of the execution messages ?

, ,
1

Imported from previous forum

2

An Exchange sends us multiple fills for one order in the same second (In different minisecond). Since our system is multi-threaded and multi processing, the fills’ sequence was slighted shuffled. Our client insists us to send to them the fills sequentially. This will dramatically impact our performance. I am wondering if there is anywhere in the FIX spec stating that the execution message sequence is not guaranteed.

Any advice?

Thanks a lot,

Jue

3

Execution Reports for a given order need to be processed and sent sequentially else there is a risk of trades being sent before trade acknowledgments, trade busts being sent before trades etc.

You can always perform parallel processing of Execution Reports for different orders.

An Exchange sends us multiple fills for one order in the same second (In different minisecond). Since our system is multi-threaded and multi processing, the fills’ sequence was slighted shuffled. Our client insists us to send to them the fills sequentially. This will dramatically impact our performance. I am wondering if there is anywhere in the FIX spec stating that the execution message sequence is not guaranteed.

Any advice?

Thanks a lot,

Jue

4

Sorry, but the order state (and qty field values) depend on the sequence. So unless your client is willing to ensure exact chaining before he processes your messages, I am afraid it will have to be you who does it. FIX sessions go over TCP/IP that guarantees the sequence. I am assuming that the Exchange sends messages to you in the business sequence. I did not look into the FIX spec but it may state somewhere the exact opposite of what you would like to find. You can run in parallel for different instruments but not arbitrarily.
Regards,
Hanno.

An Exchange sends us multiple fills for one order in the same second (In different minisecond). Since our system is multi-threaded and multi processing, the fills’ sequence was slighted shuffled. Our client insists us to send to them the fills sequentially. This will dramatically impact our performance. I am wondering if there is anywhere in the FIX spec stating that the execution message sequence is not guaranteed.

Any advice?

Thanks a lot,

Jue

5

Sequence numbers are an important part of session state management. Like others have mentioned already, they are also important for correct painting of the order book (hence order state) which is why you don’t have a workaround for messing with them. It would be better from a long term perspective as well for you to correct you application behavior and preserve the correct execution report sequence…

thanks,
Ashish G

An Exchange sends us multiple fills for one order in the same second (In different minisecond). Since our system is multi-threaded and multi processing, the fills’ sequence was slighted shuffled. Our client insists us to send to them the fills sequentially. This will dramatically impact our performance. I am wondering if there is anywhere in the FIX spec stating that the execution message sequence is not guaranteed.

Any advice?

Thanks a lot,

Jue

6

[ original email was from Mark Reece - mark.reece@hsbcib.com ]
The exchange may send fills in the same millisecond and even microsecond since an incoming agressive order may be considered to execute immediately with all the immediate trades carrying exactly the same time stamp.

However, they will have a sequence and FIX enforces maintenance of that sequence because of the Remaining Quantity Tag. Your customer may be using that Tag to spot missing fills. If you send the fills back in a different order, then their software may be continually raising alerts.

FIX 5.0 might help, if your exchange uses it because it allows multiple fills to be returned in a single Execution Report. But otherwise, I am afraid you need to process the fills in the correct sequence (or amend the Remain Quantity Tag correctly - which is probably more work than just processing them in the correct order and creates an opportunity for error).

Mark

An Exchange sends us multiple fills for one order in the same second (In different minisecond). Since our system is multi-threaded and multi processing, the fills’ sequence was slighted shuffled. Our client insists us to send to them the fills sequentially. This will dramatically impact our performance. I am wondering if there is anywhere in the FIX spec stating that the execution message sequence is not guaranteed.

Any advice?

Thanks a lot,

Jue