I'm running a strategy on a 10-minute timeframe using IQFeed data in AmiBroker. I wait for each 10-minute bar to fully close, then run the backtest. It shows expected results — for example, it might open a new Long or Short trade based on the last bar and then close it on the next one. Everything looks correct, and trades (e.g., on AMZN) appear as expected.
However, when I run the same backtest later (even after market close) with no changes to the code or settings, that trade sometimes disappears completely — as if it never happened. The script, timeframe, and symbol are identical.
How is it possible for trades to appear correctly during one run, and then vanish or change on a later run?
Could this be related to how IQFeed updates or overwrites historical intraday data?
This is the method I’ve been using to bridge backtesting and live trading. I run an OLE Automation loop to continuously backtest every scan cycle. When the backtest output shows a new Open Long or Open Short trade, I execute the trade live. If the next cycle shows the position has closed, I exit the trade.
However, this doesn't seem like the most reliable or efficient approach — especially if the backtest results change afterward and trades that were previously shown are later removed. This creates problems for live execution since I'm acting on signals that might not persist in future backtest runs.
I ran a quick test by uploading my own historical data into the same database AmiBroker uses, and the results came out differently — does this confirm that IQFeed sends inconsistent data or that the data varies in real time when accessed through AmiBroker?
Chatgpt Suggestion, not sure if accurate to go off or if a bigger issue:
Yes, you should execute trades when a signal appears at the close of a bar, provided you trust your strategy and your data feed is reliable. However, this approach requires careful handling of timing, execution assumptions, and data integrity.
Key Considerations:
Wait for Bar Completion
Execute only after the bar has closed. For 10-minute bars, wait until the exact bar end (e.g., 10:10, 10:20, etc.) and allow a few seconds for final ticks to ensure the bar data is complete.
Backtest Delay vs. Live Execution
Backtests with a one-bar delay simulate conservative execution. In live trading, executing at bar close is acceptable and may even yield better results. However, be consistent with your backtest model to avoid mismatched assumptions.
Data Drift Can Occur
Live bars and historical backfilled bars can differ slightly due to late ticks or revisions. A signal may appear during live trading but not show up when re-running the backtest later. This is normal and expected.
Recommendations:
Implement a Real-Time Trade Logger
Log trades using trace statements or file writes during live trading to preserve a record of what was executed.
Do Not Depend on Backtest Replays for Live Trade Confirmation
Treat the live signal as definitive and use the backtest for development only.
Consider Automation Tools
Use alert systems, broker APIs, or webhooks to manage and execute trades automatically and consistently.
Conclusion:
If a signal appears at the end of a bar and meets your criteria, you should take the trade. Do not be concerned if that trade later disappears from the backtest due to data revisions. Focus on consistent execution and proper logging to manage real-time trading effectively.
I would concentrate and start your investigative efforts, firstly on #3. I distinctly recall IQFeed revising bad ticks in real-time. Try to take a price history snapshot right before order generation, therefore you can compare the historical data series, if later trades don't match.
It is NOT that backtest results change. It is INPUT DATA that change. When input changes output changes too (obviously).
General rule is DO NOT backtest on live data, or at least don't expect consistency of results if you have live (ever changing) data.
With IQFeed unfiltered feed it happens that bad tick is passed thru. Bad ticks can be reported later and corrected later (after the fact) and corrections would be included in historical data. You can apply filtering (for example 3-bar Median()) to eliminate outliers from input of your system if you use live data.
I've been exploring how to transition from a backtested strategy to live alerts, and I’m wondering whether using Interactive Brokers data would offer any real advantage. Even if I were to use scan or exploration mode with IQFeed, wouldn’t similar issues still arise?
From what I’ve read, many discussions emphasize that going from backtesting to live alerts is not straightforward. They suggest that I need to use scan or exploration in a timed loop for real-time signals, but that seems to require a significantly more complex code structure compared to my current backtest strategy, which already works well.
What’s the best way to bridge the gap between a working backtest and reliable live alerts?
If you don't want to do any coding, you can just observe last lines of backtest (either trade list or detailed log). Entry and exits will be noted with current bar date (at the end of backtest). If you use trade delay == 1 then you can use "Add artificial future bar" to get those "next bar" signals displayed.
I like this concept but I've seen bad H and L prices continue on for more than 5 bars in a row. I just don't think there is a good way to make the unfiltered feed suitable for live trading. IQFeed should be reserved for backfilling and backtesting only, IMHO.
