Why your backtest looks nothing like your live results

Your strategy showed a 68% win rate on EURUSD over two years of backtesting. Clean equity curve, solid risk-to-reward, passed every drawdown scenario you threw at it. You went live.

Two weeks later, the numbers don't match. Win rate is sitting at 54%. Three trades are on the account that you don't remember your strategy calling for.

This isn't unusual. It's the norm. And most explanations you'll find online cover about half the actual problem.

The gap you already know about

Search "why backtest doesn't match live trading" and you'll get the same list everywhere: spread, slippage, data quality, look-ahead bias. Those are real. They're also the easy part.

TradingView's backtester uses a broker emulator. It simulates fills at the close of each bar, assumes a fixed spread you set in the strategy properties, and doesn't model requotes, partial fills, or queue priority. When you backtest a strategy on daily bars, every entry and exit fires at a single price point that never existed in real-time trading. The bid-ask bounce, intraday price action, the fact that your order has to compete with other orders at the broker: none of that shows up in the backtest.

Spread is the simplest example. A TradingView backtest on XAUUSD with a 20-point spread looks very different from running that strategy live on a broker charging 35 points during the London-New York overlap. Multiply that by a few hundred trades and you've found a chunk of your missing P&L.

Slippage works the same way. Your backtest assumes you get filled at the exact price the strategy specified. Your broker fills you at the next available price, which during NFP or an FOMC release might be 3-5 pips away on EURUSD. The performance metrics that actually matter (expectancy, profit factor, average R) all shift when the fill price shifts.

Most online guides stop at this point with the same general advice about running algorithms: account for spread and slippage in your backtest settings, test on lower timeframes, move on. That's fine as far as it goes.

But it doesn't explain the trades on your account that your strategy never asked for. It doesn't explain the stop loss that landed 12 points off target. And it doesn't explain the reversal that left you holding the wrong direction overnight.

Those problems come from somewhere else.

The gap you don't see: execution pipeline failures

Going from backtest to live adds more than market conditions. It adds an entire execution pipeline: TradingView fires a webhook, the webhook hits a bridge service, the bridge delivers the signal to your broker's terminal, the terminal sends the order, the broker fills it (or doesn't). Five moving parts, three network hops, at least two independent software systems that don't know about each other.

Your backtest has none of this. It's a single closed loop. Strategy logic in, simulated fill out, done. Every failure below happens in that pipeline, and none of them exist in the backtester.

Ghost positions. Your TradingView alert fires twice for the same bar. Or a webhook retry duplicates the signal. Or your script re-evaluates on a new tick and emits a stale entry after the strategy already moved on. The result: a position opens on your account that your strategy never intended. Your backtest can't model this because backtests don't have webhooks that retry.

Duplicate fills. Related but distinct. The signal was legitimate, but it arrived at the broker twice. Two positions open instead of one. Your risk is doubled on a trade your strategy sized for single execution.

Out-of-order reversals. Your strategy goes long, then reverses to short. That's two signals: close the long, open the short. In your backtest, those happen atomically on the same bar. In production, they're two separate HTTP requests traveling independently.

Sometimes the "open short" arrives before the "close long." The terminal opens the short first, then the close arrives and might close the new short instead of the old long. You wake up holding the position you were trying to exit. The difference between a simple copier and a proper execution system shows up here: most copiers don't handle sequencing at all.

Stop-loss drift. Your Pine Script calculates an SL at 1.0842 on EURUSD. The signal fires, the bridge converts it, the broker applies it. The SL ends up at 1.0845. Three pips off.

On one trade, it might not matter. Across a hundred trades, some of those drifted stops get hit early, and wins that should have held turn into losses. Try comparing what you see on your charts with what your terminal actually executed, and you'll find this is one of the differences that never shows up in feature tables.

Silent failures. The bridge goes down overnight. The terminal loses connection and doesn't reconnect. Auto-Trading toggles off after a VPS reboot. No trades fire for an entire session.

Your backtest assumes every signal executes. In production, you missed six entries because a process crashed and nobody told you.

None of these show up in a TradingView backtest. They can't. The backtester doesn't model the infrastructure between the strategy and the broker.

But live, that infrastructure is where most of the damage compounds. Each failure is rare per signal. Across a few hundred signals a month, they add up to an equity curve that looks nothing like what your strategy promised.

Why prop firm traders feel this the hardest

If you're running a personal $2,000 account, a ghost position costs you money you shouldn't have lost. Painful, but survivable. If you're in a prop firm evaluation, that same ghost position can end the run.

Prop firm rules leave no margin for pipeline errors. FTMO's daily loss limit is 5% of the initial balance. Funding Pips trails your drawdown from your equity high-water mark. The 5%ers use end-of-day balance on some phases and real-time equity on others. Each firm has its own math, its own reset timing, and its own definition of when you've crossed the line.

Now add execution pipeline failures to that environment. Your strategy backtests cleanly inside all the drawdown rules. You go live. A ghost position opens during the London session on XAUUSD. Gold moves 40 points against it before you notice.

That phantom trade eats 2.8% of your daily loss budget. Your actual strategy, running correctly, loses another 3.1% on a legitimate trade. Total: 5.9%. Daily limit breached. Evaluation over.

The strategy didn't fail. The pipeline did. And the firm's dashboard doesn't know the difference between "a trade your strategy took" and "a trade that appeared because a webhook retried." Both count equally.

Infrastructure failures belong in your plan for staying inside the firm's rules, right alongside market risk. Most traders don't realize this until after their first failed evaluation, when they're staring at a trade they never took and a rule they never meant to break.

Closing the gap: how FillEdge reconciles your backtest with your broker

FillEdge is built specifically for the execution pipeline failures described above. Not the spread-and-slippage gap (that's between you and your broker's liquidity), but the pipeline gap (that's between TradingView and your broker's terminal). Here's what it does.

Every signal that passes through FillEdge gets reconciled against the trade that follows it. What TradingView sent, what your broker executed, and whether the two agree. The reconciliation produces a status badge on every signal:

• ✓MATCHED — TradingView sent it, the terminal executed it, price, size, and stops all agree.
• 🎯LOCKED — your stop loss landed at the exact price your strategy calculated, even if the entry slipped.
• 👻CAUGHT — a phantom signal was intercepted before it reached your broker. The ghost position never happened.
• 🛡️BLOCKED — a duplicate execution attempt was stopped.
• 🔀REORDERED — reversal signals that arrived out of sequence were delivered in the correct order.
• 💀EXPIRED — a stale signal was discarded rather than executed late.

Ghost interception works by checking every incoming signal against what your strategy is currently doing on your account. If a signal would create a duplicate, contradict the strategy's current state, or repeat a fill already accounted for, FillEdge blocks it. The trade never reaches your broker. You see the interception in your dashboard with the reason and what would have happened if the ghost had gone through.

Reversal sequencing is deterministic. When two signals would flip the side of an open position, FillEdge ensures the close completes before the open begins, regardless of which webhook arrived first. No more waking up on the wrong side of a trade.

For prop firm traders, the compliance guardrails go further. Bind your account to your firm's profile (FTMO, Funding Pips, Apex, TopStep, and others are built in), and FillEdge tracks your drawdown floor, daily loss used, and profit target in real time. Every incoming signal gets checked against your remaining risk budget before it reaches the broker. If a trade would breach a rule, FillEdge blocks it or reduces the lot size to fit.

The result: your live account executes the trades your strategy intended. Ghosts are caught. Reversals land in order. Stops land where your Pine Script calculated them. The backtest-to-live gap narrows to the things the market actually controls (spread, slippage, fill timing), not the things your infrastructure was silently breaking.

Most tools that act as signal copiers, connecting TradingView to your broker, can forward alerts. But forwarding isn't the problem. Verification is. FillEdge delivers your trades and confirms they're the right ones.

What you can fix right now, without any tool

Not everything requires a product. Some of the backtest-to-live gap shrinks with better habits.

Run on demo first. Not for a week. For at least a hundred signals. Compare every demo fill against what TradingView's backtest says should have happened on that bar. Track the delta. You'll spot the spread and slippage gap within the first twenty trades. If you also see trades that shouldn't exist, you've got a pipeline problem.

Check your stop loss on every trade. Open the trade on your broker terminal. Look at where the SL actually sits. Compare it to what your Pine Script calculated. If they don't match, SL drift is part of your gap. If you've recently set up your TradingView automation with your broker, this is the fastest way to verify it's actually working.

Watch for ghosts manually. Keep your TradingView strategy tester open next to your broker terminal. When a new position appears, check whether the strategy actually generated it on that bar. If you spot a trade the strategy didn't call for, note the cause: alert firing twice, script re-evaluation, connection retry. That's the failure mode to fix.

Log your latency. Note the time TradingView fires the alert (visible in the alert log) and the time the trade appears on your broker (visible in the terminal journal). If the gap is consistently over a second, your bridge or terminal connection is the bottleneck. If the gap spikes during volatile sessions, your infrastructure is struggling exactly when execution quality matters most.

These habits won't eliminate the gap. Some failure modes can only be caught by an automated system watching every signal around the clock. But they'll tell you where your gap lives, and that's the first step to closing it.

FAQ

How much slippage should I expect between my TradingView backtest and live trading?

It depends on your broker, symbol, and the sessions you trade. On major FX pairs like EURUSD during liquid hours, expect 0.5-2 pips of slippage per fill on a standard retail account. On XAUUSD or during news events (NFP, FOMC), 3-8 points is common. Multiply your average slippage by the number of trades your strategy takes per month, and that's the baseline P&L drag your backtest doesn't show you.

Can I make my TradingView backtest more realistic?

Yes, partially. Set your strategy's commission and slippage fields to match your broker's actual spread and typical slippage (check your trade history for real numbers rather than guessing). Use bar magnifier on lower timeframes to get better intrabar fill simulation, and avoid backtesting on daily bars if your strategy trades intraday. These adjustments close the spread-and-fill gap, but they can't model execution pipeline failures such as ghost positions, duplicate signals, or out-of-order reversals, because those occur entirely outside the backtester.

Why did my prop firm evaluation fail when my backtest passed all the rules?

Backtests only model market behavior. They don't model the infrastructure between TradingView and your broker, where phantom trades, duplicated signals, and SL drift occur. A single ghost position during a volatile session can eat enough of your daily loss budget to trigger a breach, even while your actual strategy is performing within the rules. The firm's dashboard counts every trade equally, whether your strategy intended it or not.

How do I check if my stop loss is landing at the right price?

After each trade opens on your broker terminal, compare the SL price shown in the terminal to the value your Pine Script calculated for that bar. You can find the intended SL in your TradingView alert message (if you include it) or by checking the strategy tester's order list for the same entry. If the two don't match consistently, the gap is either in your bridge's SL conversion (pips vs price distance vs absolute level) or in your broker rounding to the nearest tick size.