Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Limit Order Fill Probabilities for different Entry Types?
I am looking for some advice from traders who have experience with limit orders in live markets. There are 4 different types of limit entries that I could use interchangeably in my NinjaTrading strategy but I believe that they would all have varying degrees of success getting filled in the real market. I was wondering if someone could confirm my thinking, or provide me with some insight as to where I may be off. Here are the types and my assumptions about the fill probabilities. (1 through 3 will use an on bar update event to reset and 4 will create a resting limit that waits N number of bars)
1. EnterLongLimit(1,GetCurrentBid,"") or EnterShortLimit(1,GetCurrentAsk,"") I assume you have 0 to 10% chance of getting filled using the current best price.
2. EnterLongLimit(1,Close[0]-2,"") EnterShortLimit(1,Close[0]+2,"") This would place an order 2 ticks away from the current price, so there would be a higher probability of getting filled here. My guess is 25% to 50%.
3. EnterLongLimit(1,Close[0]-4,"") EnterShortLimit(1,Close[0]+4,"") Same as above but you are moving further away from the current price (4 ticks) I assume this would increase your odds even further, though I have no clue by how much.
4. Resting Limits: In this case you could use the syntax for 2 or 3 above but instead of firing it on each bar update, keep it in play with something to the effect of EnterLongLimit(0, true, 1, Close[0]-1, "Long Entry"); Then add a block of code to keep this limit active until X bars then cancel and create a new limit. My assumption is that this type of resting limit if placed far enough away from the current action would likely get filled at close to 75%.
Anyway, these are just theories, and I have not been able to find any real information from NinjaTrader on the actual probibilities of success with each strategy, so I was hoping to hear from some traders out there with experience. If anyone would like examples of my code, I am happy to share.
Thanks for your input!
Ian
Can you help answer these questions from other members on NexusFi?
If I'm understanding what you are trying to do, it works the opposite way. Let's say you have an "x" expectancy per trade buying/selling at midpoint (Bid-Ask)/2 and let's assume you could get filled 100% of times in each case.
In the first case you will have an expectancy of x +0.5 ticks.
In the second case you will have an expectancy of x +2.5 ticks.
In the third one the expectancy will be x + 4.5 ticks.
The answer is the filling rate goes down if you put prices further away from the current price.
The chance for a fill will depend on :
- the instrument (it's associated liquidity
- the time of the day (cash session has more liquidity than overnight
- momentum and direction of the market
- market footprint
Thank you for the quick feedback! I appreciate everyone's input. Let me clarify my question a little bit more. What I am really curious about is cue position (Place in line). So in my 4 examples what I am really trying to understanding is where each order would be in the proverbial line. While I understand the concept of expectancy and the fact that moving limit triggers further away from the current price would result in less likely-hood to get in the first place, I meant to assume that in all cases the limit prices got hit. So with that in mind my theory is that if price would move through the limits in my examples, based on cue position I would expect to see the following:
1. Placing a getcurrentbid, or getcurrentask right on top of the action would put you in the back of the line
2. Placing a non-resting limit a little further away from the action by 1-4 ticks may get you closer to the front of the line
3. Placing a resting limit order that is far away from the action and that sits for 10 bars before it fills would put you in the front of the line.
Is this thinking correct or am I missing something. Again I am assuming that in all cases price would move through my hypothetical limits, so I am mainly speaking to cue position with this example.
any options are greatly appreciated. Thanks everyone!
You are correct, generally speaking, you will advance in the cue as time passes, so theoretically putting orders fars away from the price will get you into a better position when price comes to that level, but as rleplae said there are a lot of factors affecting this.
Aside from the fact that your probability of being filled is proportional to how close your limit price is to the bid/ask, I think you also need to factor the extent to which you believe your buy/sell signal is time sensitive. In my case, I ended up coding my own dynamic limit order as I wanted a good balance between speed of execution and price (i.e.: not buying at the bid/ask)
but there are numerous complications to the logic dependent on the market participants.
for example, here are two variations of an up move
strong price action up on low volume can jump price levels not clearing out the standing limit order queue leaving unfilled orders and subsequent limit orders would be queued behind them (FIFO)
strong price action up high volume can absorb (trigger) all the standing limit orders creating a vacuum/void, in which case new limit orders would be first in line per say (FIFO)
now factor in latency, size, time of day, reports, etc.... various outliners that can and do muck up simple logic, not to mention the flip side where programs play on/against these