Concept · The simulator
Individual trade-level records from an exchange — every single transaction, timestamped to the millisecond — as opposed to the aggregated OHLCV (open, high, low, close, volume) candles used in most backtesting engines.
A standard 1h candle gives you five numbers: the price at open, the highest price touched, the lowest price touched, the closing price, and total volume. A lot happened inside that hour — thousands of individual trades — but the candle collapses them all into five numbers.
Tick data keeps every trade. For a 1h window on BTC perps, that might be 50,000–200,000 individual records, each with a timestamp, price, and size. Binance publishes this as aggregate trade data — trades at the same price and millisecond are compressed into one row, reducing the count but preserving timing.
Take-profit (TP — a preset price to auto-close in profit) and stop-loss (SL — a preset price to auto-close in loss) can both fall inside a single candle's high-low range. A 1h candle that spans 0.8% has both a high and a low that may each trigger one of them. OHLC data cannot tell you which happened first — the engine must guess. Tick data resolves this exactly.
The OHLC-range fill check (see limit order) tells you whether the candle's low touched your limit price, not when. Tick data gives the exact millisecond. Queue position (how many other orders were ahead of you) is still unknowable from public trade data — but timing is precise.
At high leverage, the exact sequence of price ticks determines whether a liquidation cascades to other positions. OHLC only gives the per-candle extremes.
Realistic slippage requires order book depth (L2), not tick data. This is a common misconception. Tick data shows the price path — every price at which a trade occurred. It does not show how much liquidity existed at each level. To model "I tried to buy 5 BTC and consumed the book up 0.15%", you need L2 snapshots: the full bid/ask ladder at every point in time. See slippage.
Tick data without L2 tells you the price visited your limit. It does not tell you how much of your order filled before price moved on.
Binance's aggregate trade data uses approximately 45 bytes per row (agg_trade_id, price, qty, first/last trade ID, timestamp, side flag).
| Symbol | Trades/day (agg) | 6-year rows | Raw size |
|---|---|---|---|
| BTC | ~1M | ~2.2B | ~100 GB |
| ETH | ~500k | ~1.1B | ~50 GB |
| SOL (~4 years active) | ~300k | ~440M | ~20 GB |
| 17 other alts | ~200k each | ~260M each | ~12 GB each |
| Total | ~4B rows | ~370 GB raw |
In Postgres with indexes: approximately 1 TB.
Comparison:
The replay engine iterates through events per strategy per symbol. Current 1h replay:
6 years × 365 × 24 = 52,560 candles per symbol
With tick data on BTC:
6 years × 365 × ~1M agg trades/day = ~2.2 billion events per symbol
That is a ~42,000× multiplier per symbol over current 1h replay. For 1,500 strategies × 20 symbols, tick-level replay in Postgres would take weeks per full fleet run. Viable only with a specialized columnar time-series engine (ClickHouse, QuestDB, TimescaleDB) and parallelized compute.
For 1h and 4h swing strategies — currently the only strategies with measured edge in this fleet — mostly no. A swing strategy hunting a 2–10% move does not gain meaningful fidelity from knowing its 1h-candle entry happened at 14:32 vs 14:58. The fill timing ambiguity is small relative to the target magnitude.
Tick data becomes valuable when:
For the specific TP/SL simultaneous-trigger problem, 1-minute candles are a tractable middle ground:
This delivers ~95% of the TP/SL resolution benefit of full tick data at ~0.01% of the storage cost.
wiki/qa-sessions/2026-06-29-session.md#q4 (first asked here)apps/backend/src/evaluation/position/fill-resolver.ts (current OHLC fill model)Related concepts
See it in a real result →Put it to the test
Spawn your variant, run it on the same engine, and read the edge-significance verdict — before you risk real money.