Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 20 Apr 2024 14:11:17 +0000
Not Receiving Final Fill on Partially Filled Order using LMax FIX
View Count: 714
| [2018-09-06 17:46:53] |
| User60271 - Posts: 63 |
|
It appears that SC is not processing the final fill on a partially filled order in some cases where there is a pending modification request for that order but the order is completely filled while a modification is pending.LMax rejects the modification request but SC continues to show the order status as partially filled and ignores the LMax final fill report. I have attached Trade Activity log and the corresponding SC LMax FIX log showing an example with order ID 52807. |
Private File Private File |
| [2018-09-06 19:50:56] |
| |
|
We will look this over but two things: 1. It is a complete impossibility that Sierra Chart will not process an execution report which is identified as a "Trade". No possibility at all. That definitively will be a "Fill" you see in the Trade Activity Log. Unless it were calculated to be an "Overfill". But that kind of nonsense only occurs with Interactive Brokers. Actually all execution reports are processed. 2. We need to get the actual Trade Activity Log file. Not this incomplete export that you have provided. Instructions: Trade Activity Log: Providing Trade Activity Log File to Support More than likely, this is going to be an issue with the execution report data from LMAX affecting the order status. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2018-09-06 19:51:55
|
| [2018-09-06 20:16:40] |
| User60271 - Posts: 63 |
|
Unfortunately i cleared the trading activity log after I exported it but attached is the most recent version of the file from the Backup folder. Let me know if this is not the correct file and I'll re-upload another example tomorrow.
|
Attachment Deleted. |
| [2018-09-07 17:13:43] |
| |
|
That Trade Activity Log does not have the particular order in question. Anyway, we examined the FIX log primarily on its own and the Trade Activity Log text file that you provided and what we have reasonably determined at this point but we need to look at the cause, is that there was a loss of order ID synchronization. So around the point in time where there was order modification rejection, fills were processed as a new independent order. There can be no doubt that they were processed and you will see those fills in the Trade Activity Log for the symbol and account. The reason this happens is because LMAX changes the order ID with every order modification and also when there is an order modification rejection there is a change in the client order ID by LMAX. Inevitably this can lead to a loss of synchronization if there is an order fill during an order modification which was not yet processed by the LMAX server. (Update: this last sentence cannot be correct. There should not be a problem in this case) We are going to look into the specific reason why but really the way LMAX does order IDs and the fact that there is no constant order ID for an order, can mean that this issue can happen. There is a workaround but it is not regarded by us as a totally clean and solid solution but really there is no other way. We will have a solution implemented by the end of next week. The solution involves taking the leftmost part of the client order ID Sierra Chart provides to LMAX and using that as the Internal Order ID to perform an order look up when an execution report is received. The proper solution is for LMAX to use a constant order ID for an order. That is going to be the only rocksolid solution here. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2018-09-07 19:57:30
|
| [2018-09-07 19:55:58] |
| |
|
Actually our explanation of the apparent problem does not make sense. We need to go over this further in more detail but it is clear LMAX did not provide a matching order ID or client order ID. It does not make sense that there would be an issue when there is an order modification during a fill.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2018-09-07 19:56:21
|
| [2018-09-08 23:25:20] |
| User60271 - Posts: 63 |
|
Thanks for the update. Let me know if there’s any additional detail needed from my side.
|
| [2018-09-10 21:01:11] |
| |
|
We now know what happened. During an order modification 2 fills occurred and that restored the Sierra Chart set client order ID back to the previous one and changed the order status back to open. While this order modification was still outstanding there was another order modification from your side changing the client order ID again to a new client order ID. This second modification is where the problem began. The first order modification then completed but both the LMAX order ID and the client order ID did not match up to what Sierra Chart held at that moment for the order. At this point there was a loss of order id synchronization. We have implemented a solution to this already and that is in version 1803. We will be implementing another solution to prevent the order status from going back to open when there is a pending modify or pending cancel, and the order update is a fill and the new status is still considered an open status. There is no way we could anticipate a problem like this. It just has to be learned from experience and also the way that LMAX handles order IDs where they change on order modifications can lead to this kind of condition. Order ID handling should not be like this. There should be a constant fixed order ID throughout the life of the order. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2018-09-10 21:01:58
|
| [2018-09-11 15:01:55] |
| User60271 - Posts: 63 |
|
Thanks for the prompt response. Will upgrade to the 1803 build.In relation to the constant client order ID,from my understanding, FIX convention seems to be that new-replaces-old for client order ID on each CancelReplace message for an order. Some FIX implementations such as CME's iLink provide an additional custom field that tracks the original client order ID in all messages related to a single order. This field links all cancel/replaces back to the original order to avoid issues similar to the one identified.
|
To post a message in this thread, you need to log in with your Sierra Chart account: