# Why Backtests *Lie*: Fees, Spread, and Fills Author: Jiří Fabšic · Jul 11, 2026 · Category: Platform Canonical URL: https://www.binaryfintech.com/en/blog/why-backtests-lie/ > Why backtest results diverge from live trading: fees, spread, slippage, the fill queue, latency and partial fills. And the deeper trap — your order isn't in the historical data. How to get close to reality with event-driven simulation and the right data. ## TL;DR - **A backtest without fees, spread and slippage isn't a test — it's an advertisement.** The gap between the gross number and the net one usually decides whether a strategy makes money or quietly bleeds. - **The deepest lie isn't in the numbers — it's in an assumption:** your order isn't in the historical data. The market never reacted to you stepping in, and the price touching your limit doesn't mean you were filled. - **The faster the strategy, the more trades, the larger the position, the further the backtest drifts from reality.** You can't erase that gap — only shrink it with a faithful event-driven simulation and the right choice of data. We've watched plenty of "great" strategies burn like paper once they were tested properly. A gleaming equity curve, a handsome trade count — and then you add fees, spread and realistic fills, and the winner collapses into a line pointing down. It isn't bad luck. It's that **a naive backtest tests a different market than the one you actually trade** — friendlier, more generous, and non-existent. This article is about where exactly a backtest lies, why it hurts your best ideas most, and how to get as close to the truth as possible. You may know it in your bones, without writing a line of code: **you did better on the demo account than live.** Part of that gap is precisely the traps this article is about — a demo fills you perfectly, as if spread and slippage didn't exist. But let's be honest about the second cause too: demos are simplified and sometimes deliberately flattering, there to lure you into depositing real money. Both pull in the same direction — showing you a nicer world than the one waiting for you live. ## What exactly does a backtest leave out? Most testers assume the idealization "I buy and sell at the price on the chart." Between that sentence and a real trade lies a long road, and every step of it shaves off a piece of your return: - **Fees.** Every entry and exit costs something — and with frequent trading the fees stack up into an amount that decides profitability on its own. - **Spread.** You buy at the ask and sell at the bid. You pay that difference every single time, even when the price "on the chart" doesn't budge. - **Slippage.** The price you actually fill at isn't the price you saw at the moment you decided — especially in a fast market. And for a larger market order there's no single price at all: the order eats through several levels of the book, and the result is an **average trade price** weighted across the size available at each level. The price "on the chart" is only the first level; how deep you chew depends on the volume sitting at each one. - **The fill queue.** With a limit order you stand in line behind others. Whether you get reached depends on how much liquidity trades at that price and how many people were there first. - **Latency.** An order doesn't travel in zero time. Between your decision and the exchange there's a delay, and the market moves during it. - **Partial fills.** The market may not fill your whole order — part stays resting, or it fills in pieces at different prices. And beneath all of it sits a trap most tools never even mention: **your order isn't in the historical data.** The data recorded a market that didn't know you existed. When you "buy" in a backtest, you add an action to a world that never reacted to it — no offer rose because of you, no liquidity vanished, no other algorithmic players flinched. The smaller you are, the less it matters; the larger your position and the faster the market, the more this "invisibility" inflates your result. We'll devote a separate article to eliminating this effect, but in short: if your strategy has to buy or deploy a large size today, you simply can't drop it into the market all at once. A big position fills in pieces — and that's exactly where the price impact a backtest never sees is born. That whole way of thinking, the institutional one, deserves its own piece. The good news is that the effect can be dampened a great deal by sensible **diversification** — spreading capital across a reasonable number of instruments and [portfolios across segments and asset groups](https://www.binaryfintech.com/en/blog/strategy-portfolios/). When no single position is large relative to the market, its impact on price falls — and with it the error the backtest makes — down to a negligible level. But there's a ceiling: a point past which further splitting stops helping, and the benefit of diversification — whether through the lens of game theory or plain sustainability as the number of instruments grows — falls off the table. Where exactly that point lies is a topic of its own. ## Why "the price reached my order" doesn't mean I was filled This is the heart of the whole lie, and it's worth spelling out. The fact that **the price touched the level where you have a limit order doesn't mean you got the trade.** There's a queue at that price, and you're placed in it by when you arrived. For your order to fill, everyone ahead of you has to be "eaten" first — and whether that happens before the price jumps away is a question of liquidity, not of wishing. You may remember it from your own early days on an exchange: you hit "buy" — and nothing happened. The order hung there, waiting to fill, and your money was merely "locked" — blocked, but not spent. That's exactly it: a limit order isn't a purchase, it's a *request* to buy, waiting its turn in line. Sometimes it gets there; sometimes the price jumps away and the order keeps hanging. A naive backtest doesn't see this queue and fills you every time the price so much as touches the level. That's a systematic error *in your favor*: in the test you pick up trades you'd never have gotten live — and they tend to be the ones right at the edge of a move, the most lucrative ones. The result is an equity curve built partly from trades that never happened. *Figure: Within the queue at a given price, fills happen from the top (whoever arrived first). A naive backtest assumes you fill every time the price touches the level. Reality fills only those the actually traded volume reaches — you can walk away empty-handed, or only partially filled.* Can the queue be estimated? To a degree, yes — there are **prediction models that estimate your position in the queue and the probability of a fill**. But they can't be set once and forgotten: they have to be *calibrated to the live market* continuously. The principle is the same as [walk-forward analysis](https://www.binaryfintech.com/en/blog/walk-forward-analysis/) — the model is tuned on a sample and checked on data that hasn't arrived yet; here specifically on what actually prints in live trading. So we run the simulated fill alongside real execution, reconcile the two continuously, and wherever they diverge we retune the model. This logic — tune on the past, validate on the future, keep calibrating — holds across prediction models generally, not just for the queue. ## Maker vs. taker, limit vs. market — in plain terms Order type isn't a detail; it's a choice between two kinds of cost: - **Limit order (maker).** You add liquidity and pay a lower fee — but **you have no guarantee of a fill.** The price can fly past you and leave you standing in the queue. - **Market order (taker).** You take liquidity and your fill is near-certain — but you pay a higher fee and, above all, **slippage:** you buy through the spread, and with larger size you chew into worse levels of the book. A naive backtest takes the best of both and none of the cost: it fills like a market order (always), charges like a maker (cheaply), and ignores slippage. Such a strategy makes money on paper even when it would pay more live than it earns. Add **latency** on top — between your decision and the order reaching the exchange the market moves, so even a well-timed entry lands somewhere else. This, incidentally, is why maker and taker are priced differently at most exchanges: **the market maker supplies the liquidity the exchange needs**, so it rewards them with a lower fee. At the same time the exchange needs the other side too — the mover who "buys what's on display" — and that person pays more for the comfort of an instant fill. A backtest that erases this difference paints a world where nothing costs you anything: neither liquidity nor haste. We'll write more about exchange mechanics, price formation, the nooks of order types and special algorithmic orders in future articles. And note — this isn't just about fixing the backtest. It's a **mindset you have to design the strategy with from the very start.** There are strategies where you can almost ignore all this — long trades held for days, few entries, higher timeframes. But in algorithmic trading they're rather the exception: the whole advantage of an automated system is fast decisions, quality entries and more reliable profits where a human would open a position under the sway of emotion, fear or other — rational and irrational — impulses. And the more you lean on that advantage, the more costs and fills matter. We'll leave the psychology of trading — of the individual, the market and the crowd — to separate articles. But let's admit one piece of humility right away: even if we understand the role of a single ant and how it behaves, that still doesn't mean we understand the anthill as a whole. ## Why it kills your best strategies in particular Costs aren't a constant you can simply subtract — **they scale with how the strategy trades.** A simple proportion holds: the more trades, the shorter the timeframe and the larger the position, the more of the result is eaten by costs and fill uncertainty. A high-frequency strategy with a small average edge is the most cost-sensitive of all — a tiny fee and a couple of ticks of slippage are enough to turn a positive expectancy negative. The insidious part is that you get the worst fills precisely where the strategy most wants to trade: in a fast, agitated market. That's exactly where the spread is widest, the queue least predictable and slippage largest. An idealized backtest paints that moment rose-tinted — and the live market later hands you the bill. So we approach trading with humility: **by the time something is visibly happening, it's usually too late** — and catching a falling knife by hand isn't the best idea, because costs and slippage are at their highest in exactly that moment. And to keep from falling for the other side of the same coin — **FOMO** (the fear of missing out) — we also live by an old saying: **trading opportunities are like buses — if one leaves without you, another comes along shortly.** Patience for a good entry is cheaper than a rushed leap into a market already on the move. ## Vectorized vs. event-driven backtesting There are two basic approaches to testing, and they differ precisely in how honestly they treat time and fills: A **vectorized backtest** takes the whole history as a table and computes signals in one shot. It's fast and useful for a first rough scan — but it knows nothing of orders, queues or fees, and because the formula "sees" the whole row of data at once, it easily borrows, quietly, information you wouldn't have had at that moment. Speed is paid for in accuracy. An **event-driven backtest**, by contrast, replays the market *event by event*, in exactly the order things arrived: data comes in, the strategy reacts, sends an order, it passes through simulated execution, a fill comes back — and only then does the next event arrive. That ordering matters: at every moment the strategy knows only what it would know live, and fills happen in the context of real liquidity. Accuracy is paid for in compute — but **quality demands quality**, and for a test you're meant to trust with your money, that's the right investment. In practice the two families are routinely combined: you screen candidates quickly with a vectorized pass, then refine the promising ones event-driven. Our engine is event-driven by design; how exactly it simulates the exchange is the subject of [A Backtest That Behaves Like a Live Market](https://www.binaryfintech.com/en/blog/event-driven-backtesting/). ## Different data for different strategies A test's accuracy rises and falls with how fine the data you feed it is — and the right choice of data differs from strategy to strategy. A direct proportion holds: the finer the data resolution, the closer the test is to reality, but the more the data and the compute cost. From coarsest to most detailed: - **Candle (kline) data.** Often enough for slower, daily strategies. But inside the candle you don't know the order in which the price moved — whether it hit the high first or the low. You can sharpen it: from the shape of the candle you can estimate, with some probability, the sequence open → high → low → close, or the reverse, or use data that knows the true order. A candle can thus be enriched with the ordering (high first, or low first) while keeping high speed — and speed is essential for the million-run sweeps of [genetic optimization](https://www.binaryfintech.com/en/blog/genetic-optimization/) and the large walk-forward searches over an enormous parameter space. - **Lower timeframe.** Shortening the interval sharpens the sequence inside the original candle by itself — more candles, less ambiguity about order. - **Tick data.** The individual trades and quotes as they actually printed. From here up you're testing almost on what really happened — right for faster strategies, where order and fills matter most. Replaying the complete trade history on some instruments is time-consuming, though, and **data precision goes hand in hand with the number of tests you can run**: more detail means fewer runs in the same time. We'll write about test speed and benchmarks in a separate article. - **Order-book data.** From the best bid and ask (the spread) all the way to the full depth of the book — and even indicators built directly on the order book. Only here can you faithfully model the queue, partial fills and the behavior of larger size. For the vast majority of strategies — and for smart institutional traders too — a fraction of the book around the spread is plenty: roughly two percent of bids and asks off the best price, depending on the instrument's liquidity. Big institutions leave nothing to chance and opt for a wider view of the market, but the rule holds: **the further the volume sits from the spread, the less it matters.** Nastier still is what the candle hides entirely: **within a single bar the price can swing up and down several times.** When a strategy has both a stop-loss and a target on that same interval, it matters which one was hit first — and the candle won't tell you. Depending on the intrabar path the backtest assumes, the result can be **overstated** (it takes the target before the stop) or distorted the other way. These fast moves are hidden in the resolution of the data source; the finer the data, the less room for that guess. The rule is simple: **the faster the order cadence and the larger their nominal value, the finer the data a strategy needs** so the backtest doesn't lie to it. You can run a slow daily strategy on candles; there's no point testing spread scalping without order-book data. As in any domain, in algorithmic trading too, **context always matters.** ## How much data, and how many trades The more data you have to test on, the better — more material, more uncovered regularities, firmer statistics. With one condition: the data must be **representative and fit the era.** You can hardly take a chart from twenty-five years ago and declare that because it worked back then it'll repeat now — different fundamentals, different context, a different story. A backtest on old data, far removed from today's world, lies in that sense. But when we know about it, we give older results less weight — and still don't throw them away, because even old data carries informational value. The other side of the same coin is the **number of trades.** Few executed trades carry little evidential weight. A seasoned discretionary trader can make five trades a year and be successful; on an automated system that behavior is usually inadmissible, because five trades are like five coin flips — in the extreme you win them all or lose them all, and neither says anything about the quality of the strategy. The fewer the trades, the closer the "strategy" is to plain gambling. How many is statistically enough is a question in itself — related to [Monte Carlo](https://www.binaryfintech.com/en/blog/monte-carlo-simulation/), which turns a single result into a distribution of possibilities. ## Other backtest lies we know about Beyond costs and fills, a backtest is stalked by several more traps we've learned to recognize: - **The thin-market illusion.** On an illiquid instrument the backtest shows you beautiful fills at the price on the chart — except that liquidity isn't really there. Live, you wouldn't fill a larger position, or you'd move the price against yourself. And the thinner the market, the wider the gulf between a pretty backtest result and reality. A poor backtest shows you those fills; a good one, wary of results that look too good, would rather not open the position at all, or deliberately worsens the entry and fill so they match what you could actually get live. - **The overfitting illusion.** The best-known trap: you tune a strategy so perfectly to the past that out there, on new data, it fails. We defend against it with [walk-forward analysis](https://www.binaryfintech.com/en/blog/walk-forward-analysis/) and by analyzing the **transferability of [metrics](https://www.binaryfintech.com/en/blog/performance-metrics/)** from in-sample to out-of-sample — when performance doesn't carry over to unseen data, there's nothing to celebrate: it's a cue for caution, not a finished strategy. In detail in the article on [overfitting](https://www.binaryfintech.com/en/blog/overfitting/). - **The single-number illusion.** Tune purely for maximum profit and you'll pick the luckiest overfit run. That's why we optimize on robust composite metrics, not on bare profit — we cover it in [The Metrics You Optimize For](https://www.binaryfintech.com/en/blog/performance-metrics/). - **Survivorship bias.** You test only on what "survived" — on instruments that exist today, on markets that didn't go under. During the war, Abraham Wald studied returning bombers riddled with holes and recommended reinforcing the places where there were *no* holes — because the planes hit there never came back. A backtest sees only the returning aircraft; test only on today's winners and you measure a world without the fallen. More in the article on [instrument universes](https://www.binaryfintech.com/en/blog/instrument-universes/). - **The black-swan illusion.** A backtest can only stand up to risks we already know intimately from the past. Extrapolating past data and building a system that withstands exactly what has already happened is preparing for the last war — the next one comes from a different direction. So we build the system to survive even what isn't in the data. We cover it in the article on [black swans and fat tails](https://www.binaryfintech.com/en/blog/black-swans-fat-tails/). ## What we can never know about the market And now the most important part, because we don't want to fool ourselves. Even the most faithful simulation runs into a limit it can't cross: **we'll never know how the market would have behaved had we truly placed that position.** How the offer would have moved when we buy through the spread with a market order. How the other algorithmic players would have reacted in that instant. How our own trade would have changed the market's subsequent course. Historical data doesn't hold that answer — it recorded a world we weren't in. That uncertainty can't be removed. It can only be **shrunk** — with a faithful event-driven simulation, fine data, a probabilistic model of fills and slippage, fees and latency accounted for. Every such step moves the test result closer to what will actually meet you live. We never get the complete answer; but we can get close to the truth, right to the edge of the possible, and pull the statistics onto our side. ## Testing isn't just mathematics And one more admission, because it belongs to honesty. **No backtest is a hundred percent**, and every one runs into a particular market with some assumption about how it behaves — and that assumption is our decision, not a fact. Even the groundwork of building a strategy is a *soft craft*: where the breakpoint lies, how to split in-sample and out-of-sample, what we even look at and what we still consider good enough — all of it is guided in part by trading experience and feel, of course only **within basic, non-negotiable requirements**. Those hard guardrails always hold; but inside them there's room for judgment. Admitting this soft element isn't a weakness — it's a more accurate description of reality than the claim that testing is pure mathematics without a single decision. The final region of parameters we send into production is the intersection of hard data and years of experience with how markets behave. Anyone who pretends there's no judgment in their process has simply failed to notice their own assumptions. ## How to get close to the truth — and how much it costs Our answer to this whole chapter of uncertainties is a simple principle: **we don't cheat the market in the test, because the market can't be cheated.** Our backtest runs event-driven, over data at the resolution the strategy demands, with a simulation of the order book, the queue, fill probability, slippage, maker/taker fees, latency and partial fills — and because it has its own seed, every run can be reproduced exactly. The details of that execution are described in the article on the [event-driven engine](https://www.binaryfintech.com/en/blog/event-driven-backtesting/). *An illustrative example (an illustration, not our data):* take a strategy that makes 500 trades and, on paper — with no costs — earns 40 %. Add a taker fee of 0.075 % per trade and average slippage of, say, two ticks. The fees alone shave off roughly 500 × twice the rate (entry and exit) — and before you even get to slippage and missed limit orders, a fraction of that flashy number is left, and for more sensitive strategies even a negative one. It's exactly this gap between gross and net that separates strategies that make money from ones that looked like they did. [Which numbers we watch while doing so](https://www.binaryfintech.com/en/blog/performance-metrics/) is a separate topic. ## Conclusion: advertisement, or test? A backtest without fees, spread and realistic fills isn't a test — it's an advertisement a strategy makes for itself. An honest test begins where you admit that you aren't in the data, that a limit order needn't fill, and that the worst fills come in the fastest market. It's precisely these uncomfortable numbers that separate ideas which survive production from ones that burn like paper. We never hide them — [we show markets as they are](https://www.binaryfintech.com/en/blog/strategy-testing-protocol/), because only then does a test mean anything. **Reading:** More from our testing series: [A Backtest That Behaves Like a Live Market](https://www.binaryfintech.com/en/blog/event-driven-backtesting/) · [Overfitting](https://www.binaryfintech.com/en/blog/overfitting/) · [Performance Metrics](https://www.binaryfintech.com/en/blog/performance-metrics/) · [Monte Carlo](https://www.binaryfintech.com/en/blog/monte-carlo-simulation/). The full path of a strategy from idea to production: [the testing protocol](https://www.binaryfintech.com/en/blog/strategy-testing-protocol/).