Tick data records every individual trade or quote event with its own price and timestamp, while a 1-minute OHLC bar compresses everything that happened during that minute into only four numbers: open, high, low, and close. Because a plain OHLC bar cannot show whether the bar's high or its low printed first, a backtest running on bar data alone has to guess the intrabar sequence, and that guess only changes a trade's result when the strategy's stop and target both sit inside that same bar's range. This ambiguity affects fast scalping strategies constantly and barely touches slow swing strategies at all.
What Is Tick Data, Exactly?
A tick is one discrete market event: a single executed trade, or a single change to the best bid or offer, each carrying its own price, size, and timestamp. On CME futures, every trade and every top-of-book quote update that clears the exchange's matching engine gets published as its own timestamped record, and that raw event stream, not any chart, is the actual source every other form of "historical data" gets built from. Feed a backtest the full tick stream and, in principle, you can replay the market close to how it actually happened, order by order, which is why tick-level replay is the closest a backtest can get to knowing exactly when and at what price a resting stop or limit order would actually have triggered intrabar.
It helps to be precise about what tick data is and is not. A tick record is trade-and-quote data: price, size, side, and time. That is a different axis from market depth, which is why the choice between top-of-book and full order-book history is its own separate question, covered in our piece on Level 1 vs Level 2 market data. Tick prints are also the raw material behind order-flow tools like the DOM and footprint charts, since those are just different visual aggregations of the same trade-by-trade tape, something we get into in how order flow and the DOM actually work. None of that changes the point here: tick data is granular enough to reconstruct the actual path price took, and a bar, by design, is not.
What Is a Time-Based Bar, and What Does It Throw Away?
A time-based bar takes every tick that occurred during a fixed wall-clock window, a minute, five minutes, an hour, and reduces all of it to a small handful of numbers: the first traded price (open), the highest traded price (high), the lowest traded price (low), and the last traded price (close), usually alongside total volume. That compression is exactly why bars are useful. Four numbers per minute are compact enough to chart, index, and run indicators over across years of history, where the equivalent tick stream for the same period is a meaningfully heavier product to store and query.
But the compression is lossy by construction, and the information that gets lost is specifically the order and timing of what happened inside the bar. Two completely different intrabar paths can produce an identical OHLC bar. A bar printing open 5000.00, high 5003.50, low 4997.50, close 5001.00 is consistent with price rising to the high first and then falling to the low, or falling to the low first and then rising to the high, or any number of other paths that touch the same four levels in a different order. The bar itself carries no record of which happened. That is not a flaw in any particular vendor's product, it is what a bar is: a summary statistic over an interval, not a path.
Why Can't a Backtest on 1-Minute Bars Know Which Level Hit First?
Once a bar has erased the intrabar path, any backtest engine that only has access to bars has to adopt some rule, some assumption about the order in which the open, high, low, and close occurred, to decide which of two intrabar orders executed first whenever both a stop and a target sit inside that bar's range. This is not a hypothetical edge case. It is a documented, named behavior in major backtesting engines, and different platforms resolve it differently.
TradingView's own support documentation is explicit about its default behavior. Without Bar Magnifier mode enabled, TradingView's broker emulator assumes a fixed synthetic path through every historical bar, from the open to the low, then to the high, then to the close, rather than knowing the real intrabar sequence. Turn Bar Magnifier on and the emulator instead pulls real data from a lower timeframe than the one you are trading, for example the 1-minute bars underneath a 15-minute chart, to decide what actually filled first. That lower-timeframe view is meaningfully finer than the parent bar, but it is still bar data rather than a full tick-by-tick replay unless the underlying strategy itself is already running on very fine, second-level bars.
MetaTrader takes a related but distinct approach, and it is worth separating its modeling modes carefully because they are not all equally rough. MetaQuotes' own MQL5 documentation names four separate Strategy Tester modeling modes. Open Prices Only trades only at each bar's opening price, with no intrabar action modeled at all. 1 Minute OHLC steps through just the open, high, low, and close of each minute bar. Every Tick goes further and simulates additional synthetic prices between those four points, which the documentation says are generated "according to complex (but predefined) laws," not replayed from real history. Only Every Tick based on real ticks downloads actual historical tick prints from a broker's trade server, falling back to that same synthetic Every Tick simulation for any stretch where real ticks are missing. In other words, a mode literally named Every Tick is not, by itself, real historical tick data. A trader has to select the based-on-real-ticks variant and have genuine tick history loaded for a backtest to reflect the real market path rather than a modeled approximation of it.
cTrader documents the same tradeoff at the API level. Its Algo backtesting documentation lets a developer explicitly choose a backtest data source of tick (bid/ask), M1 open prices, or full OHLCV bars, meaning the same historical period, run through the same strategy code, can be represented at three different levels of fidelity depending purely on which data source setting is selected.
None of this means one convention is universally correct and the others are wrong. TradingView's open to low to high to close default is a documented, platform-specific choice, not an industry standard every backtester follows, and a trader moving a strategy between platforms should not assume the same historical trade resolves the same way on both.
Worked Example: A Stop and a Target Inside the Same Bar
Concrete numbers make this less abstract. Take a long entry in CME E-mini S&P 500 (ES) futures at 5000.00, with a protective stop at 4998.00 (2.00 points of risk) and a profit target at 5003.00 (3.00 points of reward). ES's contract specifications have been stable and widely documented for a long time, a $50 multiplier per index point and a minimum tick of 0.25 points, so one tick is worth 0.25 times $50, or $12.50 (always confirm the current spec sheet with CME Group or your broker before relying on it for live risk).
Suppose the 1-minute bar covering this trade prints open 5000.00, high 5003.50, low 4997.50, close 5001.00. Both the stop (4998.00) and the target (5003.00) sit inside that single bar's 4997.50 to 5003.50 range, so a backtest working from this bar alone genuinely cannot tell which was touched first.
Apply TradingView's documented default convention, open to low to high to close, absent Bar Magnifier: the assumed path is 5000.00 (open), down to 4997.50 (low), up to 5003.50 (high), back to 5001.00 (close). On that path, price crosses the 4998.00 stop on the way down to the low, before it ever reaches the 5003.00 target on the way back up. The trade is stopped out. The loss is 5000.00 minus 4998.00, or 2.00 points, which is 2.00 divided by 0.25, or 8 ticks, and 8 times $12.50 is a $100.00 loss per contract.
Now apply the opposite sequencing, the kind of path a genuine tick-level or 1-second-bar replay might actually reveal for this specific bar: open to high to low to close, 5000.00 (open), up to 5003.50 (high), down to 4997.50 (low), back to 5001.00 (close). On that path, price reaches the 5003.00 target on the way up before it ever drops to the 4998.00 stop. The trade wins. The gain is 5003.00 minus 5000.00, or 3.00 points, which is 3.00 divided by 0.25, or 12 ticks, and 12 times $12.50 is a $150.00 gain per contract.
Same entry, same stop, same target, same single bar, and the backtest's answer flips by $250 a contract depending only on which direction the software assumes price moved first.
Nothing about the trading rules changed between those two results. The entry, stop, and target are identical, and the bar's four printed numbers are identical. The only thing that changed is which intrabar sequencing convention the backtest assumed, and that single assumption is worth $150.00 (the gain) minus negative $100.00 (the loss), a $250.00 per-contract swing on one trade, purely from a data-representation choice. Run that same ambiguity across a full trade history of a scalping strategy and it stops being a curiosity and starts being a meaningful chunk of the backtested edge, or the backtested drawdown.
Most backtest engines do not flag which trades were affected by same-bar stop-and-target ambiguity, they just apply their convention and report one P&L number, so part of a strategy's backtested edge can be an artifact of the platform's default sequencing assumption rather than the trading rules themselves.
What Are Volume Bars and Tick Bars?
Time is not the only axis a bar can be built on. Tick bars and volume bars, described in detail in Marcos Lopez de Prado's Advances in Financial Machine Learning (2018), are constructed by sampling after a fixed number of trades (tick bars) or a fixed amount of traded volume or contracts (volume bars), rather than after a fixed wall-clock interval like a 1-minute bar. A tick bar might close after every 500 trades regardless of how long that takes, so during a fast, high-activity session it might close in seconds, and during a quiet overnight session the same 500 trades might take many minutes to accumulate. Volume bars work the same way but sample by contracts traded instead of trade count.
This is a real, established idea used by some quantitative researchers, and it solves a real problem: wall-clock bars sample time uniformly even though market activity is not uniform, so a fixed 1-minute bar during a quiet lunch hour and a fixed 1-minute bar during a news release contain wildly different amounts of information despite looking like the same unit. Volume and tick bars instead let the bar boundary track actual market activity.
What volume and tick bars do not solve is the core problem this article is about. A volume bar is still an OHLC-style summary of everything that happened between its boundaries, so it still only stores four price points, and the same which-came-first ambiguity applies inside any single volume or tick bar exactly as it does inside any single time bar. They are a useful, complementary way to sample non-uniformly, not a substitute for tick-level replay when you specifically need to know an intrabar sequence.
| Data type | Sampled by | What's preserved inside one unit | Typical use |
|---|---|---|---|
| Tick data | Every individual trade/quote event | Full price and time sequence | Exact fill simulation, order flow and DOM tools |
| Time-based bars (e.g. 1-minute) | Fixed wall-clock interval | Open, high, low, close only, no intrabar path | Charting, indicators, most retail backtesting |
| Volume/tick bars | Fixed traded volume or trade count | Open, high, low, close only, no intrabar path | Quant research sampling by activity, not clock time |
How Do You Match Data Granularity to Strategy Speed?
The practical question is not "which data is most accurate," tick data always wins that comparison, it is "which data is accurate enough for this specific strategy." The same-bar ambiguity matters in direct proportion to how much of a bar's typical range a strategy's stop and target actually consume. A swing strategy whose stop is a large multiple of a typical bar's range essentially never has both its stop and its target inside one bar. A scalp whose stop and target are each smaller than a typical 1-minute bar's range will run into this ambiguity on a real, meaningful share of its trades, because both levels regularly fit inside the same bar.
Go back to the worked example above: a 20.00-point stop on ES is essentially never affected by this issue, because a single 1-minute bar's range only rarely approaches 20 points in a normal session, so the stop and target are almost never both inside the same bar. The 2.00-point stop and 3.00-point target used earlier, by contrast, are affected whenever that single bar's range exceeds roughly 5.00 points, the sum of the stop distance and the target distance from entry, which is a realistic occurrence for an active-session 1-minute ES bar. That 5.00-point threshold is illustrative, built from this specific example's stop and target sizes, not a historical statistic, since realized bar range depends on the prevailing volatility regime and shifts across sessions and years; check current average true range yourself for whatever instrument and timeframe you actually trade.
The practical rule that falls out of this is straightforward. If your stop and target are frequently both smaller than a typical bar's range for the timeframe you trade, common for scalping and short-hold intraday strategies, plain OHLC bar backtesting is genuinely unreliable and you should be sourcing tick-level or fine sub-minute replay, or using a platform feature built for it like TradingView's Bar Magnifier or MetaTrader's real-tick mode. If your stop and target are wide relative to typical bar range, common for swing and position strategies, the same-bar ambiguity is close to a non-issue and plain bar data works fine. This is a separate question from whether a strategy is overfit to begin with, which is its own failure mode covered in our piece on backtesting overfitting and walk-forward validation; a strategy can pass every walk-forward test cleanly and still have its historical P&L distorted by which bar-sequencing convention the backtester happened to assume.
How Much Historical Tick Data Can You Actually Get?
Tick-level history is a meaningfully heavier product than bar data for the same calendar period, in raw event count and in storage and query cost, and it is generally bought, stored, and distributed separately from standard OHLC chart history. Exchanges publish the underlying raw feed as an event stream; CME Group's Globex matching engine, for instance, distributes market data as tick-level bid, ask, trade, and book events with precise, synchronized timestamps, and this raw feed is the actual source both tick-data vendors and any chart provider's bar aggregator ultimately build their products from. CME Group also distributes historical tick-level archives through a dedicated data platform separate from its standard real-time feeds, reflecting that tick history really is treated as a different, heavier product line rather than a byproduct of the regular chart data most platforms show by default.
What that means practically is that a trader who wants several years of full tick history on a specific contract often has to specifically source and pay for that history, rather than assuming it comes bundled with whatever charting platform or broker feed they already have. Exact formats, file sizes, pricing, and how many years of tick-level lookback any given vendor, broker, or platform retains vary meaningfully by provider and change over time, so verify current retention windows and cost directly with the data vendor, broker, or exchange before assuming a specific figure or building a research plan around it.
It is also worth being honest about what tick data does not fix. Tick-level replay removes the same-bar sequencing guess, but it does not remove every other source of backtest inaccuracy, slippage assumptions, resting-order fill logic, latency, and commission modeling still have to be estimated rather than observed. CFTC regulation 17 CFR 4.41 requires anyone presenting simulated or hypothetical trading results to disclose that such results do not represent actual trading and carry inherent limitations, including that they are designed with the benefit of hindsight, and that disclosure requirement applies just as much to a pristine tick-level backtest as it does to a rough one built on 1-minute bars. More precision is not the same thing as a real fill.
Given all of that, the honest tradeoff is this: tick-level backtesting is more accurate but far heavier to store, download, and process, and for a great many swing and position strategies the extra precision genuinely does not change the trading decision at all. Matching data granularity to how sensitive your specific strategy actually is to intrabar sequencing, rather than reflexively maximizing precision for every backtest, is the real skill here.
Frequently asked questions
What is the difference between tick data and bar data in backtesting?
Tick data is a full history of every individual trade or quote event with its own price and timestamp, while bar data, like a 1-minute OHLC candle, compresses everything that happened during that interval into just four numbers: open, high, low, and close. Because the bar has erased the exact sequence of prices, a backtest running on bars alone cannot know whether the high or low of that bar occurred first. Tick data preserves that sequence, so it lets a backtest simulate exactly when a stop or limit order would have triggered.
Why does 1-minute bar data give inaccurate backtest results for scalping strategies?
1-minute bar data gives inaccurate results for scalping because it only stores four price points per bar, so when a scalp's stop and target both sit inside that single bar's high-low range, the backtest has to guess which one was hit first. Different backtesting platforms make different guesses, some assume open to low to high to close, others use a different fixed path, and that guess alone can turn a backtested winner into a backtested loser on the identical trade. Wider swing strategies are far less exposed to this because their stops rarely fit inside a single bar's range in the first place.
How does TradingView decide which price hit first inside a backtested bar?
Without TradingView's Bar Magnifier mode enabled, its broker emulator assumes prices moved through each historical bar in a fixed synthetic path, from the open to the low, then to the high, then to the close, regardless of what actually happened intrabar. Enabling Bar Magnifier instead pulls real data from a lower timeframe than the one being traded, for example 1-minute bars underneath a 15-minute chart, to fill orders based on a much finer view of the market's actual path. This is TradingView's own documented default, not a universal industry standard, so other platforms can and do use different conventions.
Does MetaTrader's Strategy Tester use real tick data by default?
MetaTrader's Strategy Tester does not use real tick data by default, it only reflects genuine historical prices once you specifically select the "Every Tick based on real ticks" mode with real tick history loaded. Its other modes are rough in different ways: "Every Tick" generates synthetic intrabar prices using predefined, documented rules rather than real history, "1 Minute OHLC" only steps through each bar's open, high, low, and close, and "Open Prices Only" trades solely at each bar's opening price. MetaQuotes' own documentation is explicit about this distinction, so a trader who wants a truly tick-accurate MT5 backtest needs to pick that specific real-ticks mode rather than assume any setting labeled tick is real tick data.
What are volume bars and tick bars, and are they the same as tick data?
Volume bars and tick bars are not the same as tick data, they are still compressed OHLC-style bars, just sampled by a fixed amount of traded volume or a fixed number of trades instead of a fixed wall-clock interval like a 1-minute bar. Bar boundaries land more frequently during active markets and less frequently during quiet ones, but each individual bar still only stores open, high, low, and close, so the same which-came-first ambiguity still applies within any single volume or tick bar. The concept is described in detail in Marcos Lopez de Prado's work on financial machine learning, and is used by some quant traders as an alternative way to sample time, not as a substitute for tick-level replay.
Do I need tick data to backtest a swing trading strategy?
No, most swing strategies do not need tick data because their stops and targets are typically many times wider than a single bar's range, so the stop and target essentially never fall inside the same bar and the which-came-first ambiguity rarely if ever affects the result. Daily, hourly, or several-minute bar data is generally accurate enough for position and swing strategies with wide risk parameters. Tick-level precision matters most for fast strategies like scalping, where stops and targets are frequently smaller than a single bar's typical range.
How much historical tick data can I actually get for futures?
How much historical tick data you can get varies by exchange, broker, and data vendor, since tick-level history is generally sold and stored separately from standard OHLC chart data, being a much larger and heavier product to maintain. Exchanges like CME Group make raw tick-level market data available and also distribute historical archives through dedicated data platforms, but exact lookback windows, formats, and pricing differ by provider and change over time. Always verify current retention and pricing directly with your data vendor, broker, or the exchange rather than assuming a fixed number of years is available.
Can a backtest be wrong even if I use real tick data?
Yes, tick-level backtesting removes the same-bar sequencing ambiguity but it does not remove every source of backtest inaccuracy, things like slippage assumptions, fill logic for resting orders, latency, and commission modeling still have to be estimated. Regulators require exactly this kind of humility: CFTC rules mandate that simulated or hypothetical performance results be disclosed as not representing actual trading, in part because they are built with the benefit of hindsight. Tick data makes a backtest more realistic, not risk free.
What causes a backtested winning trade to become a loss when data granularity changes?
A backtested winning trade can flip to a loss purely because of which intrabar price sequence the backtesting platform assumes when a stop and a target both sit inside the same OHLC bar's range. If the platform's convention has price reaching the stop before the target, the trade backtests as a loss; if the convention, or the real tick data, shows the target being reached first, the identical trade backtests as a win. This is a data-representation artifact, not a difference in the trading rules themselves.
Is tick bar backtesting always more accurate than bar-based backtesting?
Not always in a way that changes your results. Tick-level backtesting is more accurate for simulating exact order fills because it preserves the real sequence of prices within what would otherwise be a single bar, but that added accuracy comes at a real cost in storage size, download time, and processing complexity. For a slow strategy whose stops and targets are much wider than typical bar ranges, the extra precision usually does not change the trading decision. Matching data granularity to how sensitive your strategy actually is, rather than always defaulting to the finest possible granularity, is the more useful skill.