I dont' need a perfect algo, I just need a safety switch to trigger when the algo does mess up. That switch is to go flat! I have play around with conditional check a bit more.
How about some sort of error-checking? Basically just have the algo run some sort of redundancy check each time it wants to execute itself. Like if QT kicks you an error in the log, have the algo instantly flatten all positions. If order = rejected/refused then flatten else continue, something like that.
That's what I'm tryin to figure out. Last change I did is to make sure everything's flat when i get the TP target hit. BUt today, target never was hit, so that code never got executed. I had a reverse order that was supposed to be cancelled (OCO) but did not cancel. Also I'm realizing that there seems to be an issue when all the orders are coming in sequence at the same time within few ms. The market might be taking its time to execute some orders (in Transit). WHile one order is in transit, the next squence is already filled, and it MAY cause some issues I'm assuming. I dont know if my code has order magic numbers like you see in MT5. Maybe it's built in QT, but I need to review that too. Things I need to check: -OCO logic -flat position checks when target hits TP, but somehow there is left over lots not filled -check for naked position (when TP has not been reached). I'm taking C# right now. So maybe the string concatenate lesson will help haha
Using QT, can you rerun the day in back-test mode? If so, use Visual Studio to compile a debug version so you can step through your code, or set some breakpoints to stop code execution so you can check variables, etc. Much easier to track down problems using the VS debugger. Otherwise, you're flying blind.
No I can't replicate live execution back in market replay. Market replay is basically demo environment and do not reflect real market execution/latency.
You need a "try catch". SOP for production code. Try something and then catch it, if it fails. Also use asserts as the baby step to the above. Seems like the Algo is OK but the order handling is buggy. Personally, I "eliminate" these types of issues by doing the simplest, least error prone order generation and handling. But I was a Test manager for MSFT. BTW: if the Dev did not litter the code with asserts around the order handling, which is basically transaction handling (with roll back) and race conditions, that is amateur hour. Best of luck.
I reviewed yesterday's event log and found the issue. Yesterday, the OCO process didn't work, I had a sell order that didnt' cancel when a buy order is triggered. SO the reverse+the sell stop got executed. The limit target on the buy stop was also not cancelled so that was weird too. How the algo can work for while and it encounters issues like this convince me that I need to have this code rewritten to where each trade (entry,s/l,target) has its own ID. With the current code, the stop/reverse and target executions can get cause I errors I think when the order routing goes off track or in "IN TRANSIT". So in addition to having each trade being separate, I need to implement check at each sequence to make sure specific order/position ID is reconciled. I have a clear understanding of what I need, just getting there is gonna be a challenge.
And this is in a normal market not a disorderly one. One needs to assume everything can go wrong. Even the "corrections" can go wrong. With these assumptions the code is very complex. It will be more than the algo code, way more. Examine transaction roll back methods. Draw up a framework for Algo wrong, Algo-broker wrong, broker exchange wrong, XXX wrong, but only delayed and then corrects. Basically for every transaction, you need to hold it in a sand box and compare it to the reported state, then keep all those until the entire transaction is complete. With OCO orders, this is a lot. With reversals, more and more with multiple contracts (positions). Do this on a branched version of the code base. There about 2x-3x more code to write for this. That is why your "dev" did not do it. Testing is even more work because, as you know, you cannot do it in Sim, but you will have to create the error conditions live and include the broker and exchange, such as loss connection or very large delays not only in the sending, but in the confirmation. If you want to go down this path, write a separate order handler that works with all algos not just this one. PS: I think the NASDAQ site has some information on order handlers and best practices that they implement between the exchange and the FCM-IB.
Yea the dev is probably not very detailed in his approach. You would probably laugh if i told you waht I paid to ge the algo done. BUt I did get about 20x out of the initial code investment.