Slippage, Spread and Execution on a Prop Firm Server: Why Live Never Matches the Backtest
Key takeaways
- A backtest is a reconstruction of the market under assumptions, not a recording of it, so a live account that matched it exactly would be the suspicious result.
- Slippage is not a defect, it is the price of demanding an immediate fill, and it applies to your stop loss just as much as to your entry.
- Most testers freeze the spread at a single value, while a live spread widens exactly when an active strategy is most likely to be trading.
- One sided deviation that grows with order size points at infrastructure, while deviation that only appears when you compare a small live sample to a long optimised backtest points at expectation.
- On a prop account the same slippage costs more, because it moves the equity number your firm measures against its own loss limits, not just your P&L.
- Size the position for the worst plausible fill rather than the average one, and re-run the backtest with realistic spread and commission before you decide the edge is real.
Your backtest was a simulation, not a recording
The strategy tester does not replay what happened. It rebuilds an approximation of the market from stored data and then assumes your order was filled at the price that approximation produced. Every assumption inside that rebuild is a place where a live account can disagree, and they nearly all disagree in the same direction. This does not make backtesting useless. It means the test answers a narrower question than most traders think: does this logic have an edge under these assumptions, not what this account will do next month on this firm's server.
By default the simulation is generous in several ways at once. Ticks are often generated from minute bars rather than taken from real tick history. The spread is frozen at a single figure. The fill lands at the exact price the order requested. There are no requotes, no rejections, no connection drops, and no commission or swap unless you configured them. A live prop account carries all of that simultaneously, on every trade, forever.
So the real question is never whether live differs from the test. It always will. The question is whether the size of the difference is explainable. Explainable divergence is an engineering problem with a checklist. Unexplainable divergence usually means the strategy was fitted to a dataset rather than to the market.
The four costs that separate a tester fill from a live fill
Before diagnosing anything, name the pieces separately, because traders blame one word, slippage, for four different costs that behave differently and have different fixes.
- Spread. The distance between bid and ask at the moment you transact. It is a real, recurring cost, it is variable, and in most testers it is a constant.
- Commission and swap. Commission is charged per lot on raw spread accounts, swap for holding overnight. Neither exists in a test unless you switched it on, and both quietly reduce the edge of a high frequency system.
- Slippage. The difference between the price your robot asked for and the price it received. It can be negative or positive, and it grows with volatility, size and delay.
- Latency. The time between the robot deciding and the order reaching the matching engine. Latency does not cost money directly. It converts into slippage, because the book keeps moving while your order is in transit.
Slippage is the price of demanding immediacy
A market order says one thing: fill me now, at whatever is available. Between the instant the robot reads a quote and the instant the order arrives, the order book can change. If it moved against you, you get a worse price. If it moved in your favour, you get a better one, and positive slippage is real, but most traders never notice it because they only inspect the fills that hurt.
That symmetry is the useful diagnostic. Roughly balanced deviation around zero is normal friction. Deviation that is consistently one sided across many trades is worth investigating, especially if it scales with your lot size, because size interacts with the liquidity available at the top of the book.
The part that catches people out is the stop loss. On most platforms a stop is not a resting guarantee, it is an instruction that becomes a market order once the level trades. It slips too. A trader who says the risk on this trade is fixed is describing an intention, not a fact, and on a fast move the realised loss can exceed the planned one.
Spread is a variable your test probably froze
Most backtests run on a single spread value, a fixed input or an average, and that value quietly becomes the strategy's foundation. Live spread does not behave that way. It widens at the daily rollover, around scheduled releases, at session opens and closes, in thin holiday liquidity, and in the seconds after any sudden move. Those are frequently the same moments an active robot chooses to trade.
Account type changes the shape of the cost too. A raw spread account shows a tighter quote and charges commission separately, while an all in account bundles the cost into a wider quote. Neither is automatically cheaper, and comparing a test on one structure to a live account on the other produces divergence that has nothing to do with execution quality. Symbols matter as well: metals, indices and exotic pairs typically carry wider and more volatile spreads than major pairs, and the same symbol name on a prop firm server can point at a different contract specification than the one you tested.
Latency belongs in the same discussion, because it is less a separate cost than a multiplier on this one. The chain runs from the robot's logic, through your terminal, across the network to the broker, and back with a confirmation, and hosting only shortens the network leg. A terminal loaded with charts and several robots can take longer to decide than the network takes to deliver, and a machine that sleeps or reboots does not slip a trade, it abandons one. If you are still running a challenge from a laptop, [the hosting question deserves its own decision](/blog/vps-for-prop-firm-ea) before you blame execution.
A prop firm server is not your retail broker account
This is the step most traders skip. The account where you developed the strategy is almost never the account where the challenge runs. The firm's environment has its own price feed, trade server, symbol list and often its own execution model, so contract sizes, minimum stop distances, maximum lot per position, permitted order types and the exact quote you receive can all differ from the broker where the numbers looked good.
Platform matters too. MT4, MT5 and the newer web based platforms many firms now offer each handle orders, partial fills and stop placement in their own way, so the same logic can behave differently across them. If your firm runs something other than MetaTrader, read up on [how a robot behaves on TradeLocker, DXtrade and cTrader](/blog/run-ea-on-tradelocker-dxtrade-ctrader) before assuming the results transfer.
Rules are the other moving part. Firms change execution terms, permitted instruments and news policy regularly, so what a forum post said last year is not evidence. Read your firm's current rulebook, and confirm your account type allows automated trading at all.
How to tell an infrastructure problem from a wrong expectation
Almost every complaint about live performance lands in one of two buckets, and the fixes are different: either something in the execution path is broken, or the comparison was never valid. Work through both lists before you change a setting.
Signals that point at infrastructure:
- Deviation between requested and filled price is one sided across many trades, rather than scattered around zero.
- The deviation grows noticeably as you increase lot size, which suggests you are consuming more of the available book than the test assumed.
- The terminal log is full of requotes, off quotes, invalid stops, or connection messages clustered around the times the robot trades.
- Deviation concentrates in a specific window every day, which usually means a feed or liquidity condition rather than a strategy flaw.
- The same robot on the same settings behaves differently on two accounts running at once, which isolates the difference to the environment.
The expectation problems nobody wants to hear about
The second bucket is less comfortable, because the fix is not a purchase. These comparisons were never going to hold, no matter how good the hosting is.
Signals that point at expectation:
- You are comparing a live sample of a few dozen trades to a multi year backtest. Small samples swing wildly around their own average, in both directions.
- The test used generated ticks and a frozen spread, and you are now measuring the live account tick by tick against it.
- The strategy targets moves so small that ordinary transaction cost consumes a large share of every winner.
- The parameters were optimised on the exact data that produced the equity curve, so the result describes the past rather than predicting anything.
- The backtest period contained a market regime, a volatility level or a trending phase that simply is not present right now.
On a prop account, slippage costs more than money
On a personal account, execution cost is exactly that: a cost. It makes the curve flatter. On a challenge or a funded account it does something worse, because it moves the specific number the firm evaluates you against. A stop that slips widens the realised loss, pushing equity closer to a limit that was calibrated on the assumption that the stop would fill where you put it. Many firms measure intraday equity rather than closed profit and loss, so the worst fill of the day can matter more than the day's result. If those limits still blur together for you, the difference between [daily loss and maximum drawdown](/blog/daily-loss-vs-max-drawdown) is the most valuable thing to get straight.
This is the reason PraxAI is built as two engines rather than one: one side works to pass the challenge, the other to protect the account inside every rule once it is funded. PraxAI GUARD is the part that watches the rulebook in real time, and the Built-In Drawdown Lock is a brake written into the code, meant to shut the system down before it reaches the firm's daily limit rather than reporting a breach afterwards. PraxAI FUNDED carries that job into the funded stage, where a breach costs an account you already earned. No system removes execution uncertainty, and none should claim to.
The principle generalises beyond any product. Because your fill is uncertain, the reserve you keep between your risk and the rule has to be deliberate. A risk model that assumes perfect execution is not conservative, it is untested.
What to do before you blame the robot
Run this sequence in order. Most divergence stops looking mysterious in the first three steps, and none of it requires buying anything.
- Log every trade's requested price against its filled price. In MetaTrader the Experts and Journal tabs record what the robot asked for and the History tab records what it got, so the raw material is already on your machine. Without that record you are arguing from memory, and memory keeps only the painful fills.
- Measure the live spread on the firm's own server, at the exact hours your system trades, rather than trusting the figure on a marketing page.
- Re-run the backtest using that observed spread plus commission and swap, then check whether the edge is still there. If it disappears, the problem was never execution.
- Set the slippage tolerance deliberately instead of leaving the default. Too tight produces rejections and missed entries, too loose accepts fills you would have refused.
- Forward test on the firm's own demo or trial environment first, on the same symbol name and settings, so you are comparing the environment rather than the strategy.
- Reduce exposure around scheduled releases if your firm permits trading through them at all, since spread widening and slippage tend to spike together there.
- Size for the worst plausible fill rather than the average one, and treat the difference as the cost of a real account.
- Give any change enough trades to mean something. Reacting to three bad fills is how a working system gets dismantled.
Frequently asked questions
Why does my EA make money in backtest but lose money live?
Usually because the test assumed a frozen spread, perfect fills, no commission and no delay, while the live account has all four working against it at once. The second common cause is optimisation, where the parameters were tuned on the same data that produced the equity curve. Re-run the test with realistic spread and commission, and if the edge disappears there, the problem is the strategy rather than the execution.
Is slippage the broker's fault or the EA's fault?
Often neither. Slippage is the normal cost of asking for an immediate fill in a market that keeps moving, and it goes in both directions. It becomes worth investigating when the deviation is consistently one sided across many trades, when it grows with your lot size, or when it clusters in a specific window each day. Balanced deviation around zero is friction, not a defect.
Does slippage count against a prop firm daily loss limit?
In practice, yes. The firm evaluates your account as it actually is, not as your strategy intended it to be, so if a stop slips and the realised loss is larger than planned, the larger number is the one measured. Firms differ in what they measure and when the limit resets, so confirm the details in your own firm's current rulebook. Either way, the reserve between your risk per trade and the limit needs to be deliberate rather than assumed.
How much slippage is normal on a prop firm account?
There is no universal figure, and anyone quoting one is describing their own broker, symbol and session rather than yours. What matters is your own baseline: log requested price against filled price for a meaningful number of trades, look at whether the deviation is balanced or one sided, and compare it across the hours you actually trade. Your own log is the only benchmark that means anything.
Can a VPS fix slippage?
It can reduce one component of it. Hosting close to the broker's trade server shortens the network leg, which reduces how far the price can move while an order is in transit. It does nothing about spread, commission, thin liquidity or an overloaded terminal, and it cannot rescue a strategy whose target is smaller than its transaction cost. Better hosting reduces execution noise, it does not create an edge.
Should I backtest with real tick data or are modelled ticks enough?
For a strategy that holds positions for hours or days, modelled ticks are usually acceptable. For anything scalping, using tight stops, or entering on intrabar movement, real tick data with a variable spread is closer to honest, because the way price moved inside each bar is exactly what determines whether your stop or your target was reached first. Either way, add commission and swap before drawing conclusions.
Why do live results differ between two prop firms running the same robot?
Because each firm has its own broker, price feed, execution model and symbol specification. Contract sizes, minimum stop distances, maximum lot per position and permitted order types can all differ, and the platform itself handles orders differently across MetaTrader and the newer web based platforms. Running the same settings on two firms and expecting identical curves assumes an equivalence that does not exist.
Want the bot that runs this discipline for you?