Realistic fills *feature request* Please vote [SOLVED]
Realistic fills *feature request* Please vote
I request that MultiCharts improve the fill models used in backtests. The current fill models in some cases are unrealistic, and can produce backtests which are dramatically different from what would happen in live trading.
Please vote for it here: https://www.multicharts.com/pm/viewissu ... no=MC-1672
::Limit Order Realistic Fill::
-Fill at Limit order price only.
*Notes*
Regardless of where price is, there should be no improvement. Even if there is a true gap in historical data, in real time, your order would probably fill that gap and be filled at its price.
-A fill will only happen once price has traded through the Limit price an inputted amount of ticks.
*Notes*
We have a feature for this already, but the fills are improved to the inputted tick amount instead of ensuring that price trading through our order the inputted amount.
::Market Order Realistic Fill::
-Fill at Market Price less an inputted amount of "spread" or "slippage". Buy market orders to be filled N ticks above market order price and Sell market orders to be filled N ticks below market order price.
*Notes*
Currently, the fill model in MultiCharts for Market orders adjusts them by a simple profit deduction. This is not adequate. In live trading, Market orders are filled at a different price than what they are placed at because of the bid/ask spread. If we place a buy market order at 100, we will get filled at 101. Just as if we place a sell market order at 100, we will get filled at 99. This miscalculates all profit targets, stop-losses, and everything else calculated off our fill price... which in a backtest makes profit targets much more likely to execute, and stoploss orders less likely to execute. Thus we get overly-optimistic backtest results, which are not accounted for by a simple profit deduction.
I realize that these issues could be remedied with bid/ask/trade data and the extended back-testing feature, but these are a couple easily implemented features for trade only data which is much more common and makes life a lot easier.
Suggestion:
Please vote for it here: https://www.multicharts.com/pm/viewissu ... no=MC-1672
::Limit Order Realistic Fill::
-Fill at Limit order price only.
*Notes*
Regardless of where price is, there should be no improvement. Even if there is a true gap in historical data, in real time, your order would probably fill that gap and be filled at its price.
-A fill will only happen once price has traded through the Limit price an inputted amount of ticks.
*Notes*
We have a feature for this already, but the fills are improved to the inputted tick amount instead of ensuring that price trading through our order the inputted amount.
::Market Order Realistic Fill::
-Fill at Market Price less an inputted amount of "spread" or "slippage". Buy market orders to be filled N ticks above market order price and Sell market orders to be filled N ticks below market order price.
*Notes*
Currently, the fill model in MultiCharts for Market orders adjusts them by a simple profit deduction. This is not adequate. In live trading, Market orders are filled at a different price than what they are placed at because of the bid/ask spread. If we place a buy market order at 100, we will get filled at 101. Just as if we place a sell market order at 100, we will get filled at 99. This miscalculates all profit targets, stop-losses, and everything else calculated off our fill price... which in a backtest makes profit targets much more likely to execute, and stoploss orders less likely to execute. Thus we get overly-optimistic backtest results, which are not accounted for by a simple profit deduction.
I realize that these issues could be remedied with bid/ask/trade data and the extended back-testing feature, but these are a couple easily implemented features for trade only data which is much more common and makes life a lot easier.
Suggestion:
Last edited by MAtricks on 29 Jul 2014, edited 2 times in total.
- Smoky
- Posts: 518
- Joined: 03 Dec 2010
- Location: Thailand
- Has thanked: 99 times
- Been thanked: 121 times
Re: Realistic fills *feature request* Please vote
As i already told you a realistic baktest would be work with tick datas bid/ask !
My backtest take a night to compute but if you ask MC customers if they prefer to have a true backtest even if the time calculation is long or a backtest with bad results ....
My backtest take a night to compute but if you ask MC customers if they prefer to have a true backtest even if the time calculation is long or a backtest with bad results ....
Re: Realistic fills *feature request* Please vote
Thank you. I'm just trying to get trade only data to work for us in a realistic manner. If I'm not back-testing a scalping system, I tend to only use Trade data and I'm sure others would agree that using bid/ask/trade data for a 10 year back-test on a swing system would be extreme overkill. These features would create very reliable tests on the widely available and used Trade data.I realize that these issues could be remedied with bid/ask/trade data and the extended back-testing feature, but these are a couple easily implemented features for trade only data which is much more common and makes life a lot easier.
Re: Realistic fills *feature request* Please vote
Also, some time ago I made the request for more realistic back test:
https://www.multicharts.com/pm/viewissu ... no=MC-1505
https://www.multicharts.com/pm/viewissu ... no=MC-1505
-
- Posts: 9
- Joined: 29 May 2014
- Has thanked: 3 times
- Been thanked: 1 time
Re: Realistic fills *feature request* Please vote
Hello Matricks,
I agree with you that the backtesting and trading results in realtime simulated modus are not realistic and to optimistic. Buying at the bid price and selling at the ask price is not what happens in the realtradingworld it has to be the opposite.
I agree with you that the backtesting and trading results in realtime simulated modus are not realistic and to optimistic. Buying at the bid price and selling at the ask price is not what happens in the realtradingworld it has to be the opposite.
Re: Realistic fills *feature request* Please vote
Monexx, I hadn't seen this before. Good job You posted that 7 months ago and it hasn't been reviewed yet. This affects all our work... Without them, our back-tests cannot be reliable. Seems like this should be priority in a trading platform.Also, some time ago I made the request for more realistic back test:
https://www.multicharts.com/pm/viewissu ... no=MC-1505
Re: Realistic fills *feature request* Please vote
The simple backtest needs tweaking as currently it's wrong. Smoky - I agree with you. Separately, it wouldn't take much just to correct the error on the simple backtest.
quoting Andrew from another thread:
"Backtesting, Bar Magnifier is on, an order is generated to be executed at next bar, next bar OHLC are 100-105-90-95. Let's assume, BM is set to 1 tick and there are only 11 ticks forming this bar: 100-94-92-90-98-102-105-101-99-97-95. When BM is on, MC can fill orders only at the known prices. In this case there are 15 known prices: OHLC of the main bar (that is luckily has the same OHLC as 11 ticks in our example ) and 11 ticks prices. It means that an order cannot be filled at 104, 103, 96 and 93 prices. The goal of such behavior is to exclude possible order executions at unknown prices assuming there were no such prices traded (104, 103, 96, 93) and of course it cannot be filled outside the bar in this case as well."
Execution at "unknown" prices should indeed be possible as your limit order fill would have created a "known" price. Therefore MC is incorporating an inappropriate price improvement right here.
The only time you can improve on a limit order price from the perspective of MC is if, at the point a fresh, brand new limit order is fired off to the exchange (e.g. on the first tick of the new bar, where a new buy condition has been met) the current offer is below the limit price specified. Or from a simple backtest perspective the open < buy limit price.
To conclude:
Please permit limit order fills at prices not historically traded within the bar's range.
quoting Andrew from another thread:
"Backtesting, Bar Magnifier is on, an order is generated to be executed at next bar, next bar OHLC are 100-105-90-95. Let's assume, BM is set to 1 tick and there are only 11 ticks forming this bar: 100-94-92-90-98-102-105-101-99-97-95. When BM is on, MC can fill orders only at the known prices. In this case there are 15 known prices: OHLC of the main bar (that is luckily has the same OHLC as 11 ticks in our example ) and 11 ticks prices. It means that an order cannot be filled at 104, 103, 96 and 93 prices. The goal of such behavior is to exclude possible order executions at unknown prices assuming there were no such prices traded (104, 103, 96, 93) and of course it cannot be filled outside the bar in this case as well."
Execution at "unknown" prices should indeed be possible as your limit order fill would have created a "known" price. Therefore MC is incorporating an inappropriate price improvement right here.
The only time you can improve on a limit order price from the perspective of MC is if, at the point a fresh, brand new limit order is fired off to the exchange (e.g. on the first tick of the new bar, where a new buy condition has been met) the current offer is below the limit price specified. Or from a simple backtest perspective the open < buy limit price.
To conclude:
Please permit limit order fills at prices not historically traded within the bar's range.
Re: Realistic fills *feature request* Please vote
hilbert,
I do agree with your requests, but lets keep this thread on the topic of Realistic Fills which in my opinion are very high priority to an automated trader.
Might I suggest removing that post and creating a thread for each of those topics? I'd gladly join those discussions.
I do agree with your requests, but lets keep this thread on the topic of Realistic Fills which in my opinion are very high priority to an automated trader.
Might I suggest removing that post and creating a thread for each of those topics? I'd gladly join those discussions.
- Andrew MultiCharts
- Posts: 1587
- Joined: 11 Oct 2011
- Has thanked: 931 times
- Been thanked: 559 times
Re: Realistic fills *feature request* Please vote
You are welcome to vote for the feature requests opened by MAtricks or to use Extended Mode of backtesting.Please permit limit order fills at prices not historically traded within the bar's range.
Re: Realistic fills *feature request* Please vote
Hello Matricks,Monexx, I hadn't seen this before. Good job You posted that 7 months ago and it hasn't been reviewed yet. This affects all our work... Without them, our back-tests cannot be reliable. Seems like this should be priority in a trading platform.Also, some time ago I made the request for more realistic back test:
https://www.multicharts.com/pm/viewissu ... no=MC-1505
I also think that this should be resolved with the highest priority!
Vote for your and my request should be summing.
-
- Posts: 6
- Joined: 24 May 2014
- Has thanked: 4 times
- Been thanked: 3 times
Re: Realistic fills *feature request* Please vote
I agree on limit orders (and stop orders for the same reason). OOEL lets you do this right now, by the way.
However, market orders should execute on the close. Otherwise there can be issues. For example, I am frequently the opening tick of the following bar when I place a trade. I avoid backtesting with fills at the next bar open because frequently those are my actual trades, so I'd be double-penalizing myself for slippage.
Also, changing the entry point will change the exit price calculations. Changing exit calculations can easily change the following trades. Imagine the chaos when significant numbers of historical entries and exits start changing simply because the slippage setting got changed!
The most valuable thing for me would be the ability to programmatically adjust fills on the fly (like OOEL lets you do) and programmatically set slippage for each trade on the fly (e.g. based on order type, time of day, etc.), which OOEL does not let you do (there is no Write method for slippage for some unknown reason).
The ability to do those two things would solve all of the issues raised here and many more.
However, market orders should execute on the close. Otherwise there can be issues. For example, I am frequently the opening tick of the following bar when I place a trade. I avoid backtesting with fills at the next bar open because frequently those are my actual trades, so I'd be double-penalizing myself for slippage.
Also, changing the entry point will change the exit price calculations. Changing exit calculations can easily change the following trades. Imagine the chaos when significant numbers of historical entries and exits start changing simply because the slippage setting got changed!
The most valuable thing for me would be the ability to programmatically adjust fills on the fly (like OOEL lets you do) and programmatically set slippage for each trade on the fly (e.g. based on order type, time of day, etc.), which OOEL does not let you do (there is no Write method for slippage for some unknown reason).
The ability to do those two things would solve all of the issues raised here and many more.
Re: Realistic fills *feature request* Please vote
Turn if off if you don't like it MC is great about giving us the on/off button.
Example:
Example:
- Attachments
-
- 2014-06-02_0931.png
- (69.75 KiB) Downloaded 2109 times
Re: Realistic fills *feature request* Please vote
Me again,
Firstly:
I was just wondering when you want MC to add a cost for crossing the spread. Without the historical bid/ask you simply can't know when you've crossed the spread, no?. If last traded is 100 which is the offer, if you buy you will be also trading the last price (100). So adding a spread cross cost here would be wrong. The best solution is historical bid/ask data. However I choose to add a fixed cost associated with every executed order. This is a figure that represents slippage and the occassional crossing of the spread. To be honest, unless you've got a low latency setup your estimations for the mentioned cost per trade should easily cover slippage and crossing the spread.
When trading live I monitor my "execution cost" and adjust my backtesting assumptions accordingly. Ie note when your live execution doesn't match the non live real time equivalent.... that's your "execution cost" (not inc brokerage). I run two identical charts for each system/symbol and monitor differences this way.
Secondly:
Please explain to me why the following request is subject to opinion.
"Please permit limit order fills at prices not historically traded within the bar's range."
Meaning, please explain to me why (as I may have the wrong end of the stick) why Multicharts is happy to proceed with the current simulation of limit orders in backtesting. Surely it's black and white, only filling limit orders on historically traded data points intrabar is wrong. I would appreciate it if you come back with a counter argument. The reason I haven't yet voted for MAtrick's proposal is that there is one point I don't understand/agree with. That is that, IMHO if a limit order is submitted at the start of the new bar it is possible you will get filled at a better price than the "equal to or better than" price specified by the strategy. Other than that I feel he's right on the money, as it were.
Thirdly
Firstly:
Hi Monexx,Also, some time ago I made the request for more realistic back test:
https://www.multicharts.com/pm/viewissue ... no=MC-1505
I was just wondering when you want MC to add a cost for crossing the spread. Without the historical bid/ask you simply can't know when you've crossed the spread, no?. If last traded is 100 which is the offer, if you buy you will be also trading the last price (100). So adding a spread cross cost here would be wrong. The best solution is historical bid/ask data. However I choose to add a fixed cost associated with every executed order. This is a figure that represents slippage and the occassional crossing of the spread. To be honest, unless you've got a low latency setup your estimations for the mentioned cost per trade should easily cover slippage and crossing the spread.
When trading live I monitor my "execution cost" and adjust my backtesting assumptions accordingly. Ie note when your live execution doesn't match the non live real time equivalent.... that's your "execution cost" (not inc brokerage). I run two identical charts for each system/symbol and monitor differences this way.
Secondly:
Andrew FYI you locked out the previous thread so I couldn't post there.You are welcome to vote for the feature requests opened by MAtricks or to use Extended Mode of backtesting.
Please explain to me why the following request is subject to opinion.
"Please permit limit order fills at prices not historically traded within the bar's range."
Meaning, please explain to me why (as I may have the wrong end of the stick) why Multicharts is happy to proceed with the current simulation of limit orders in backtesting. Surely it's black and white, only filling limit orders on historically traded data points intrabar is wrong. I would appreciate it if you come back with a counter argument. The reason I haven't yet voted for MAtrick's proposal is that there is one point I don't understand/agree with. That is that, IMHO if a limit order is submitted at the start of the new bar it is possible you will get filled at a better price than the "equal to or better than" price specified by the strategy. Other than that I feel he's right on the money, as it were.
Thirdly
If you won't listen to anyone else on this subject, then the least you can do is listen to Mathemagician's requests. He's something of an expert on these things.I agree on limit orders (and stop orders for the same reason).
Re: Realistic fills *feature request* Please vote
MATricks: love it! Come on MC make it happen. The limit order correction too please.
THANKS!!Turn if off if you don't like it MC is great about giving us the on/off button.
Example:
-
- Posts: 9
- Joined: 29 May 2014
- Has thanked: 3 times
- Been thanked: 1 time
Re: Realistic fills *feature request* Please vote
When backtesting or running a simulated strategy then a buy order is the lowest ask price and the sell order is the highest bid price.
-
- Posts: 6
- Joined: 24 May 2014
- Has thanked: 4 times
- Been thanked: 3 times
Re: Realistic fills *feature request* Please vote
This functionality is definitely needed, and I think we're simply approaching implementation differently. While a menu-style option for moving fills might be the simplest way to address your immediate need, it doesn't present a lot of flexibility. As an example, slippage rarely comes in full tick increments. Where would you put a fill with half a tick of slippage? a quarter tick?
Programmatic access to fill prices and slippage, however, provides every bit of this functionality along with the ability to do so much more...
P.S. As an aside please try to remember that stop orders suffer from the same "extra tick" issue as limit orders, though in the case of stop orders it's a penalty rather than a bonus.
Programmatic access to fill prices and slippage, however, provides every bit of this functionality along with the ability to do so much more...
P.S. As an aside please try to remember that stop orders suffer from the same "extra tick" issue as limit orders, though in the case of stop orders it's a penalty rather than a bonus.
-
- Posts: 9
- Joined: 29 May 2014
- Has thanked: 3 times
- Been thanked: 1 time
Re: Realistic fills *feature request* Please vote
A question to MC. When will this big bug be adjusted since it affects backtesting and real-time strategy testing a trading strategy?
- Andrew MultiCharts
- Posts: 1587
- Joined: 11 Oct 2011
- Has thanked: 931 times
- Been thanked: 559 times
Re: Realistic fills *feature request* Please vote
The status of the feature request will be updated when the improvements described there are scheduled for any particular version of MC. At the moment there is no ETA.A question to MC. When will this big bug be adjusted since it affects backtesting and real-time strategy testing a trading strategy?
- Andrew MultiCharts
- Posts: 1587
- Joined: 11 Oct 2011
- Has thanked: 931 times
- Been thanked: 559 times
Re: Realistic fills *feature request* Please vote [SOLVED]
The behavior of the feature "limit order assumption (when price goes beyond X points) for backtesting" will be improved in future version of MultiCharts. Please keep track of the following feature requests:
Re: Realistic fills *feature request* Please vote
Much appreciated Andrew. I look forward to this!!
Not to be a brat .. but I noticed that your post says nothing about the Market Order feature. Any progress there?
Not to be a brat .. but I noticed that your post says nothing about the Market Order feature. Any progress there?
- Andrew MultiCharts
- Posts: 1587
- Joined: 11 Oct 2011
- Has thanked: 931 times
- Been thanked: 559 times
Re: Realistic fills *feature request* Please vote
Market order assumptions are not in the schedule yet, but if something changes, i'll let you know.Much appreciated Andrew. I look forward to this!!
Not to be a brat .. but I noticed that your post says nothing about the Market Order feature. Any progress there?