I'd like to make my algorithm survive a situation when it hits a low-liquidity security. I will, of course, check volume and use 2.5% slippage defaults to be on the safe side, but I expect that sooner or later I may hit a bad volume print and end up entering an order for a very slow stock. How would you recommend dealing with such situation? Would you just abort the algo and manually exit, or have the algo exit?
The problem I see is that without callbacks it's very hard to deal with partial fills and synchronization of market/limit and stop order sizes.
Example: Let's say my algo placed an order to buy 100 with a stop loss sell 100. Due to low liquidity, after time X (end of day, or say, 5 minutes after the order is placed), the algo detects the following:
- 34/100 of the market order is filled
- 12/100 of the stop is filled
actions:
1. log alarm
2. cancel market order
3. reduce stop order size to the filled: cancel stop order, place new stop order for the remaining size (34-12 = 22)
at the next bar (after new orders have been sent out):
4. check that the cancellation of the market and stop orders have happened (alarm if not?)
5. since there may have been more fills between the initial fill observed and cancel orders (e.g. we got 36/100 and 15/100 before both got cancelled), I need to adjust the stop order size again (cancel stop of size 22 and place new stop of size 21)
It's just pretty clumsy and hard to do, considering that after placing new orders one needs to wait for the next bar, verify positions and order states and adjust again and again. It seems that having order modifications and partial fill events would help to code around things like that easier.
I am sure this problems comes up in any algo which tries to cancel a partially filled order and keep it working with a stop (without exiting right away).
What would you recommend? Am I overthinking this?