I have a new idea that I am considering programming, but it is going to be very complex and time consuming to build. So before I invest the time and effort I figured I would punt the concept out there and see what everyone thinks of the concept. If it seems viable, then I will invest the time, but if people can find some obvious holes in this, I would appreciate the feedback... as the last thing I would want to do is invest the time assuming the concept is viable when I obviously overlooked something.
So with the introduction in mind here is a little background information:
From the enclosed image consider that there is always 2 sides in the market at any given point in time.
1. The Strong Side: This is the side that accumulates heavy limit order volume resting multiple price levels out.
2. The Weak Side: This is the side that does not benefit from having a queue of resting orders. When a new price level is created this side will spontaneous try to fill out resting orders for the first time, because there is no prior queue of resting orders for this side.
So naturally getting filled on the strong side becomes a challenge because only so many transactions can occur within a given price level and the line is quite long. By contrast getting filled on the weak side is fairly easy because the starting resting volume is non existent. In my experience trading live I have had no issues getting filled on the weak side nearly every time, but I get filled far less on the strong side.
Using an estimated place in the queue estimator such as NinjaTraders APQ, you can tell what your position in the queue is approximately. You can run this on as many price points as you want simultaneously theoretically. I recently punted a question about integrating the APQ into a strategy to be able to access this variable via programming. But technical complexities aside let's assume that one could theoretically gain access to this variable for any submitted entry on any number of price levels.
Here is the idea: The key points of the system consist of 3 main concepts:
1.. For each price level that clears I will keep a score of how many strong side contracts were transacted and added and canceled. (I already have this part of the code built). This will essentially quantify how many people got filled from the strong side over the last N number of price levels. From this population I can take an average, min, max, STD, etc. This will give me an idea of how high up I need to be in the queue to get to a certain level of confidence that I will transact. Let's say during a given price level we typically observe 300 transactions and 100 queue improvements due to cancellations (Net Cancellations above both transacted volume and added volume). So this will tell me that as long as I am in position 400 when I reach the working price level I will typically get filled based on the recent history. I can further quantify this down to how many cases over the last N number of price levels did this occur or not occur, but for simplicity let's assume 70% of the time as long as I am in position 400 or better I will get filled.
2. Knowing your estimated place in the queue. The APQ does this, and reverse engineering this will tell us where we are in line. The idea is to submit orders on each side 5-10 levels out and track the queue position improvements due to net cancellations as each works closer to the actual transaction price level. If I reach the transaction level and my place in the queue is > 400 from the step one analysis / outcome, I will simply cancel because I have a high probability of not getting filled and this is a waste of time. If my place in the queue is