TradingView fills: next bar open by default, bar close with process_orders_on_close

[Fairman]

TradingView fills: next bar open by default, bar close with process_orders_on_close

Before trusting a TradingView backtest, check when it assumes your orders fill. The setting is in the strategy declaration.

Code: Select all

//@version=5
strategy("Cross test", overlay=true, process_orders_on_close=false,
     commission_type=strategy.commission.percent, commission_value=0.0,
     slippage=0)
fast = ta.ema(close, 9)
slow = ta.ema(close, 21)
if ta.crossover(fast, slow)
    strategy.entry("L", strategy.long)

By default, the script calculates when a bar closes, creates the order then, and the order is filled at the next bar's open. With process_orders_on_close=true the market order is filled at the close of the bar that produced the signal. In a historical test that looks fine, but in live trading the close isn't known until the bar is finished, so the real order would go out afterwards at a different price. The TradingView documentation mentions that this can be unrealistic.

Commission and slippage both default to zero. The slippage argument is in ticks, so on a 5 digit EURUSD feed 3 means 3 points, or 0.3 pips.

A test to run: use the same script with the setting off and on, and compare the net result and number of trades. If the profit mostly disappears when the fills move to the next open, the system is relying on the close price it couldn't get.

Then put your real costs into the declaration and run again.

[Fairman]

On how to set the costs: commission_type has options for percent, cash per order and cash per contract. For a forex symbol on TradingView, what a contract means depends on the instrument, so check one trade by hand. Run a single entry and exit, read the commission in the list of trades, and compare it with what you expect to pay your broker. If you expect $7 on a round turn for one lot and the report shows a different number, change the setting until they match, before you trust the equity curve.

[Fairman]

Slippage in ticks needs a conversion. With a symbol that has a minimum tick of 0.00001, 10 ticks is 1 pip. So to model 0.3 pip of slippage on each fill you'd set slippage=3. On a symbol with a 0.001 tick, like a JPY pair on some feeds, the ticks are 0.1 pip each. Read the symbol's minimum tick in the settings and write the conversion as a comment next to the line so you don't mix it up later. And remember the slippage is applied against you on market and stop orders.

[Fairman]

Be careful with the bar magnifier and intrabar logic. If your strategy has a stop and a target both inside one bar's range, the tester has to decide which was hit first, and it uses an assumption about the path inside the bar. Check the documentation for the version you use, and test the extreme by assuming the stop comes first. For scalping on 1 minute charts, those bars are common, so the answer can move the result noticeably. If the result survives the pessimistic ordering, I trust it a little more.

[Fairman]

A last check against reality: forward test the script on the same instrument for two weeks on a demo account, and compare the entries to what the backtest would have produced on the same dates. If the live fills are consistently 0.5 pip worse than the backtest on market orders, set the slippage in the declaration to match, and rerun the history. This calibrates the model to your broker's fills instead of to a default of zero, and it is the single change that makes TradingView results closer to what happens in the account.