For example: Let's say that a bid / ask level just changed and price moved up by 1 tick. Typically the first side to get served will be the line of Bids. So let's say that I join the line immediately after the level change and run a GetCurrentBidVolume() to see the number of cars ahead of me. The GetCurrentBidVolume in this example is 200. So I place a limit order in the same code block, so I will assume that I immediately become car # 201. Now we wait. In theory 200 cars ahead of me have to move before I get my number 201 called and I get a fill.
In most cases I have tested however, I will get a fill prior to the bid volume declining (Implies the 200 cars ahead of me got filled), and in around 50% of cases I tested I will see the same exact GetCurrentCurrentBidVolume() when I initially submit my order, when I actually get filled and even on the next bar update after. This implies that the 200 cars ahead of me haven't even gotten filled yet, but it shows that I am filled.
Obviously there are cases where the volumes rise and fall, and you can say it's fair that I would have gotten a fill, but the scenario I am describing should not ever happen and it does quite often.
So the behavior that I would like to see before a fill can be given is this:
1. Snapshot of the CurrentBidVolume or CurrentAskVolume at the time that an order is placed (Depending on if I am short or long). This gives a count of how many contracts are ahead of me and must clear before I get a fill. I know in the real market some of these will cancel, and there are complex rules where orders with larger size can skip ahead, but I would be satisfied if we just start with a snapshot of how many contracts are ahead when an order is placed and use this as step 1.
2. Only after the volume declines by a magnitude = to the number of contracts ahead of me when I ran CurrentBidVolume or CurrentAskVolume should I be able to get my order filled. This figure would calculate net of any changes in the level 1 volumes (New contracts added and transacted existing contracts) So in this example if there were 100 transacted bids since I joined the queue but 50 more cars that joined the queue after me. I would move from 201 to 101 and expect to see the next GetCurrentBidVolume update at 151 with my position being 101 in line.
3. We will need to assume that any added volume goes behind me in the queue and my position moves up as transacted volume increases towards my number. I realize that larger size can cut in line, but that will add a whole other level of sophistication that I don't think will be easy to implement, so for now we will keep it simple.
I hope I am making this request clear, but let me know if you have any questions, or if you need me to provide a code that could highlight this and recreate the scenario I am describing and show how this current logic is not in place.
Thanks,
Ian
Comment