Table of Contents
- Why Tick Data Backtesting Beats Bar Data for Accuracy
- Historical Tick Data: Sources, Coverage, and What to Verify
- Tick Data vs Minute Data: When the Extra Detail Pays Off
- Backtesting with Bid and Ask Data: Modeling the Spread
- Backtesting Slippage and Spread: Realistic Fill Assumptions
- Step-by-Step: A Reproducible Tick Data Backtesting Workflow
- Cleaning and Validating Tick Data at the Event Level
- Conclusion
- Frequently Asked Questions
Last Updated: October 19, 2026
Why Tick Data Backtesting Beats Bar Data for Accuracy
Using [tick data](/backtest-mt5-robots-real-tick-data/) for more accurate backtesting starts with one hard truth: a bar chart hides most of what happened.
Bar data smooths over the path price took.
At EZMT5, we care for a practical reason: a strategy that looks solid on minute bars can fall apart once real spreads and fill order are applied.
Here is the core argument: bar data tests the idea, tick data tests the execution. Most traders only ever test the idea.
The difference between a backtest and a realistic backtest is the execution model. Tick data is what makes a realistic execution model possible.
Historical Tick Data: Sources, Coverage, and What to Verify
Historical tick data comes from brokers, commercial vendors, and exchange feeds, each with trade-offs in cost, coverage, and cleanliness.
Before you trust any dataset, check these items:
- Date range and symbols covered. Gaps in coverage create silent holes in your test.
- Trade data vs. quote data. Some sources include only trades, not bid and ask.
- Timestamp precision. Millisecond or microsecond stamps matter for intraday work.
The SEC’s guidance on market data and trading systems is a useful starting point for understanding how market data is structured and regulated. For retail traders, broker-supplied tick history is the most common source, but its quality varies widely.
The most common mistake is assuming a tick file is complete because it opens cleanly. Missing ticks during high-volatility windows quietly distort every result that follows.
Tick Data vs Minute Data: When the Extra Detail Pays Off
Tick data wins when execution details decide the outcome. Minute data wins when you need speed and your strategy is not sensitive to intrabar movement.
Here is the split in plain terms:
| Factor | Tick Data | Minute Data |
|---|---|---|
| File size | Very large | Small |
| Processing speed | Slow | Fast |
| Spread modeling | Precise | Approximate |
| Fill realism | High | Low |
| Best for | Intraday, high-frequency | Swing, position |
For positions held for days, minute data is usually enough.
The practical rule: if your strategy’s edge depends on entry timing within the bar, you need ticks. If it depends on the daily trend, you do not.
Backtesting with Bid and Ask Data: Modeling the Spread
Backtesting with bid and ask data means testing against the price you would actually pay, not a midpoint that never existed. Buys fill at the ask, sells at the bid, and the gap is the spread, a real cost a trade-only dataset hides.
What quote data actually contains
A trade-only feed gives the last traded price. A quote feed gives the best bid and ask at each update, often with resting sizes. Most retail strategies execute against the quote, not the last trade, so without quotes you can only guess at the spread at fill time.
When you source quote data, verify three things:
- Bid and ask are separate fields with their own timestamps. A single “price” field with a spread assumption bolted on is not quote data.
- Sizes are present if you plan to model partial fills. Without size, you cannot tell whether your order would have been filled in full.
- The quote and trade streams are aligned in time. Mixing a trade timestamp with a quote from a different millisecond reintroduces the look-ahead problem you were trying to remove.
Fill logic by order type
The spread model is only half the job; the other half is the rule deciding whether and at what price an order fills.
Market orders. A buy fills at the ask, a sell at the bid, at the first quote at or after the order timestamp.
Stop orders. A stop triggers on the quote, not the last trade, then executes as a market order at the next available quote.
A spread-aware execution model in four steps
- Store bid price, ask price, and sizes as separate fields, each with its own timestamp.
- Normalize timestamps to one timezone and sort the combined stream before any rule reads it.
- Apply the fill rule for the order type against the quote at or after the order timestamp, never against a quote stamped later than the decision point.
- Add commission on top of the spread cost, not instead of it. Commission is a separate line item; folding it into the spread double-counts one cost and hides the other.
This single change often turns a profitable-looking bar-based test into a break-even one, accurate news, delivered before you risk capital.
The most common bid/ask modeling error is using the midpoint as the fill price and then adding a fixed spread cost. That double-counts the spread on one side and understates it on the other. Pick one method, fill at the quote, or fill at the mid plus half-spread, and apply it consistently across every order type.
Spread-aware execution is where the gap between a backtest and a live account shows up first. Model the quote, order type, and size together, or the equity curve is fiction. (Source: impact of data granularity on trading strategy performance)
Backtesting Slippage and Spread: Realistic Fill Assumptions
Backtesting slippage and spread is where most retail tests quietly cheat, assuming every order fills at the exact price requested, instantly, with no market impact.
Real markets do not cooperate. Fill assumptions need to reflect three costs:
- Spread cost: the bid-ask gap you cross on entry and exit.
- Slippage: the difference between expected and actual fill price.
- Market impact: the price move your own order helps cause.
A simple, honest model applies a fixed slippage allowance per trade plus a spread cost from the tick data at fill time; a stricter model walks the order book. Start simple, then tighten.
Test the same strategy with zero slippage, then with a realistic slippage assumption. If the edge disappears entirely, the strategy was never trading an edge. It was trading an assumption.
Step-by-Step: A Reproducible Tick Data Backtesting Workflow
A reproducible workflow means another trader could rerun your test and get the same result. Most tick-data guides stop at “clean the data and run the backtest.” Below is the sequence we actually use, with the artifacts and validation gates that make a result auditable.
Phase 1: Freeze the specification before touching data
- Write the strategy spec as a versioned document. Entry, exit, position sizing, max holding time, and the exact fields each rule reads (bid, ask, last, volume). If a rule reads “close,” define whether that means the last trade or the mid-quote at a timestamp.
- Record the parameter set and date range in the same file. A result without them is not reproducible; it is an anecdote.
- Declare execution assumptions up front, spread model, slippage model, commission per lot or share, and fill logic (market, limit, stop). Changing these after seeing results flatters backtests.
Phase 2: Acquire and stage the tick data
- Pull the full date range for every symbol, including any symbol used only for a filter or correlation check. Partial symbol coverage is the most common silent hole.
- Store raw ticks immutably in a columnar format such as Parquet or a compressed CSV, partitioned by symbol and date. Keep the raw file untouched so every later step can be rerun from source.
- Record a data manifest: source, pull date, row count per symbol per day, timezone of the raw timestamps, and schema version. The manifest is what lets you prove later which dataset produced a result.
Phase 3: Clean and validate at the event level
- Run the event-level validation checklist (duplicates, out-of-order stamps, zero or negative prices, bid greater than ask, weekend and holiday gaps, symbol mapping, timezone normalization). Log every rejected row with a reason code instead of silently dropping it.
- Produce a data-quality report, rows in, rows out, rejection counts by reason, and gap windows longer than a threshold you set (for example, more than 60 seconds during an active session). This report belongs with the backtest output, not in a separate folder.
Phase 4: Build and run the execution model
- Implement the fill logic as code, not as a spreadsheet assumption. Market orders cross the spread; limit orders fill only when the quote trades through the limit price; stop orders trigger on the quote, not the last trade. The bid/ask section below covers the mechanics.
- Log every fill with timestamp, side, requested price, filled price, spread at fill, slippage, and commission. A trade log you can audit line by line is the deliverable, not just the equity curve.
Phase 5: Validate and report
- Run the bias checklist, look-ahead, survivorship, and market microstructure, and record the result of each check in the report. A bias check that is not written down did not happen.
- Run a sensitivity pass on the execution assumptions: zero slippage, base-case slippage, and a stressed slippage assumption. If the edge only survives the zero-slippage case, the edge is an assumption.
- Forward test on demo data for a defined period before committing capital, and compare live fills against the modeled fills. Divergence between the two is the most useful diagnostic you will get.
Expected result: a versioned spec, an immutable raw dataset with a manifest, a data-quality report, a full fill-level trade log, a bias-check record, and a sensitivity table. Another trader with the same files should be able to reproduce your equity curve within the stated assumptions.
Treat the workflow as a pipeline with named stages and saved outputs at each stage. When a result looks too good, you can rerun a single stage instead of the whole test, and you can show exactly which stage changed.
This is also where EZMT5 fits naturally. Our systems ship fully built and optimized for MT5, so you can compare your own tick-level results against a tested baseline instead of starting from a blank file. Two license keys per system mean you can run the same logic on a demo account and a live account side by side.
Cleaning and Validating Tick Data at the Event Level
Event-level validation separates a trustworthy test from a decorative one: you check each tick, not just the file.
Run this checklist before every serious backtest:
- Duplicate timestamps removed
- Out-of-order ticks sorted
- Zero or negative prices flagged
Look-ahead bias sneaks in through timestamps. If a signal reads a tick stamped later than the decision point, your backtest is peeking at the future. Sort first, then test.
Survivorship bias is the quieter cousin. If your symbol list only includes instruments still trading today, you have already filtered out the failures. Market microstructure bias is the third trap: assuming a fill the order book could never have supported.
Clean data plus honest fills equals a backtest worth trusting. Skip either and the numbers mean nothing.
Conclusion
Tick data does not make a bad strategy good. It makes a good strategy testable and a bad one obvious.
The work is real: cleaning files, modeling spreads, checking bias. But the payoff is a backtest that resembles live trading instead of flattering it.
EZMT5 gives you 11 fully built MT5 trading systems and TradingView indicators, all future systems included, with no contract and two changeable license keys per system.
Sign up now and start testing with systems built for real execution, not ideal conditions.
Frequently Asked Questions
What is tick data in backtesting?
Tick data is a record of every individual price update and trade that occurs in the market, including the timestamp, bid price, ask price, and trade size. In backtesting, it lets you simulate order fills at the exact moment a price was available rather than at an aggregated bar close. This matters most for intraday and high-frequency strategies where a few seconds can change whether a trade is profitable. Using tick data backtesting gives you a more realistic view of execution quality and transaction costs than minute or bar data alone.
Is tick data better than one-minute data for backtesting?
It depends on your strategy’s holding period. For strategies that hold positions for hours or days, minute data is often sufficient because the entry and exit timing is less sensitive to sub-minute price moves. For intraday trading, scalping, or high-frequency trading, tick data vs minute data is not close: tick data captures the bid-ask spread, slippage, and order-fill dynamics that minute bars smooth over. The trade-off is file size and processing time, so match the data granularity to how your strategy actually triggers trades.
How do spreads and slippage affect tick data backtests?
Spreads and slippage are two of the biggest reasons backtests look better than live results. If you backtest only at the mid-price, you ignore the cost of crossing the spread on every trade. Backtesting slippage and spread means using the actual bid and ask at the moment of execution, then adding a realistic slippage assumption based on your order type and typical fill quality. A strategy that looks profitable at the mid-price can turn unprofitable once a one-pip spread and half-pip slippage are applied to every round turn.
How much historical tick data do you need to backtest a strategy?
A practical starting point is three to six months of continuous tick data for the instruments you trade, which is enough to cover different volatility regimes and session behaviors. For strategies with low trade frequency, extend the window to a year or more. More important than raw length is data completeness: a shorter, clean dataset with no gaps beats a multi-year file with missing hours. Always reserve a separate out-of-sample period for forward testing so you are not validating on the same data you used to develop the strategy.