Why your prop firm evaluation failed (and it wasn't your strategy)

You backtested for three months. Win rate held. Drawdown stayed inside the rules. You launched the evaluation, walked away, and came back to a failed account. The daily loss limit was breached on a Tuesday you don't even remember trading.

The strategy didn't change. The market didn't crash. Something between your TradingView alert and your broker's fill did something your strategy never asked for. And you have no way to prove it.

This is the part of prop firm trading nobody warns you about. The strategy can be solid, backtested, and profitable in every simulation, yet it still fails the evaluation because the execution layer between TradingView and your broker introduces errors the backtest couldn't predict. Not big, dramatic errors. Small, invisible ones that compound across dozens of trades until your drawdown budget is gone.

Here's what actually goes wrong, and what to do about it.

Ghost positions: trades your strategy never asked for

A ghost position is a trade sitting on your broker account that your strategy didn't intend. The name sounds dramatic. The cause is mundane.

TradingView fires a webhook the instant strategy.entry() is called. That happens before the fill is confirmed. If the fill doesn't come through, or if the script re-evaluates on the same bar and fires again, your broker now has a position that exists for no strategic reason. It's just there, taking risk, eating drawdown.

The same thing happens with webhook retries. Your bridge receives the alert, forwards it to the broker, but the HTTP response times out. TradingView resends. Now your broker has two entries where your strategy intended one.

On a $100K FTMO evaluation with a 5% daily drawdown limit (that's $5,000 as of this writing; check their current rules before relying on this number), a single ghost position on XAUUSD during a London session spike can eat $800–$1,200 of that budget in minutes. You won't see it until the damage is done. The trade just appears in your account history, without any corresponding logic in your script.

The worst part: prop firms don't care why the trade happened. Their system sees a position, a loss, and a rule breach. "My automation sent a phantom trade" is not an appeal they accept.

Signal reordering: when the close lands after the open

Your strategy reverses from long to short. In Pine Script, that's clean: close the long, open the short. Two signals, one intention.

In production, those are two separate webhooks traveling over HTTP. And HTTP doesn't guarantee delivery order. The "open short" can arrive at your broker before the "close long." When that happens, the EA opens the short first. Both positions sit on the account briefly. When the "close long" arrives a moment later, the EA looks for a long to close and finds two positions tagged with its magic number. If its close logic picks the most recently opened one, it closes the freshly opened short. The long stays. You end up holding the position your strategy was trying to exit.

Most bridges don't handle this directly. They either require you to rewrite your Pine Script so the reversal fires as a single atomic webhook, one strategy.entry() call that closes and opens in one message, or they rely on the EA's close logic to make the right choice when two positions are present. That works until it doesn't. When it doesn't, you don't get an alert. You just get the wrong position.

An inverted position on a trending day can breach your drawdown floor in a single session. Every prop firm has rules to manage exactly this kind of risk, but those rules don't help when the execution layer is the one creating the position.

Stop-loss drift: your risk doesn't land where you calculated it

Your Pine Script calculates a stop-loss at 1.0842 on EURUSD. The alert fires. The webhook carries that number. Your broker fills the entry at 1.0845 (three points of slippage). The bridge places the SL at 1.0842, exactly as the alert specified.

But your strategy calculated that SL as a distance from entry, not an absolute price. The intended risk was 30 pips. With the slippage, the actual risk is now 27 pips. That might sound like a gift (tighter stop), but the math goes the other direction just as often. Entry slips against you, the SL stays at the absolute price, and your actual risk per trade is wider than what the backtest assumed.

Even 2–3 points of drift per trade add up over 50 fills. On a $200K Funding Pips account with a trailing drawdown (rules vary by account type; verify their current terms), those extra points of exposure compound into real drawdown that your backtest never modeled. Perfect SL placement is what your strategy assumed. The live execution delivered something close. Close isn't good enough when you're running inside a 4% trailing corridor.

If your bridge doesn't reconcile the intended SL against the actual SL, you'll never know this is happening. The position looks normal. The stop is "close enough." But multiply that gap by every trade in the evaluation, and you get a drawdown curve that's consistently worse than the backtest, with no single trade to blame.

Duplicate fills: the same trade, twice

This one is simple. Your TradingView alert fires. The webhook hits the bridge. The bridge sends the order to your broker.

The response times out, so the bridge retries. Both orders fill.

Now you have twice the position size your strategy intended. Twice the exposure. If the trade goes against you, you lose double. On a prop firm evaluation, that doubled loss might be the one that breaches your daily limit.

Duplicate fills trace back to one root cause. The bridge handling your TradingView webhooks doesn't track order state, so it fires and forgets, happily sending the same order again.

On a $50K TopStep evaluation (their rules include specific daily loss limits per contract; always confirm the current schedule before trading), a single duplicate on ES or NQ during a volatile session can breach the daily limit outright. Not because the trade was bad. Because the trade happened twice.

Silent failures: the trades that never happened

Not all execution failures produce a bad trade. Some produce no trade at all. Your EA crashes overnight. The VPS reboots and doesn't re-enable AutoTrading. The webhook endpoint goes stale because your bridge session expired.

The result: trades your strategy intended to take simply don't fire. You wake up to a flat day when the strategy was supposed to take six positions.

For a simple personal account, missing trades are annoying. For a prop firm evaluation, it's different.

Most firms enforce consistency rules. At Funding Pips, for example, a single profitable day can't dominate your total P&L by more than a certain percentage (these rules change; check their current terms). Two flat days from a dead EA, followed by three big manual days, skews that ratio fast. The consistency violation triggers even if the total P&L is healthy.

The real pain is that silent failures leave no trace in your broker's trade history. There's no rejected order to investigate. The trade just didn't happen, and you have to figure out why by cross-referencing your TradingView alert log against your broker's statements. The more strategies you've automated in TradingView, the harder that detective work gets.

Stale signals: executing yesterday's trade today

Your VPS goes down for twenty minutes during the New York session. When it comes back up, the bridge has three queued alerts waiting. They execute immediately, at whatever price the market is showing right now.

The problem: those alerts were calculated by your strategy twenty minutes ago. The entries, the stops, the position sizes were all based on a market state that no longer exists. Your strategy wanted to buy EURUSD at 1.0850. It's now at 1.0870. The bridge executes the buy at 1.0870 with a stop at 1.0820 (the original distance), giving you a 50-pip stop instead of the intended 30.

Stale signals are the failure mode that causes live results to diverge from backtests in ways that appear random. Some trades work out anyway. Others get destroyed because the entry price is 20 points away from where the strategy calculated the risk-reward. Over an evaluation, this noise shows up as unexplained variance in your equity curve, wider drawdowns than expected, and a win rate that doesn't match your backtested numbers.

A well-built bridge discards signals older than a configurable threshold rather than executing them blind. But most DIY setups and several commercial bridges don't check signal age at all.

How FillEdge catches these before your broker sees them

FillEdge is a webhook execution bridge built for exactly this failure profile. Every signal travels through a pipeline with checkpoints at each stage, and each checkpoint is designed to catch a specific class of error before it reaches your broker.

For ghost positions, FillEdge inspects every incoming signal against your current account state. If the signal would produce a duplicate execution or a position that contradicts your strategy's current state, it's blocked. The signal log shows a 👻CAUGHT or 🛡️BLOCKED badge, the reason for the block, and what would have happened if the signal had passed through. No silent rejections.

For out-of-order reversals, FillEdge sequences the close-then-open deterministically. Regardless of which webhook arrived first, the close completes before the open begins. If a counterpart never arrives, the orphan is held, not executed in isolation. Sequenced reversals carry a 🔀REORDERED badge so you can see exactly when the bridge intervened.

For SL drift, FillEdge reconciles every fill against the original signal. The intended entry, the actual entry, the intended SL, and the actual SL are compared and logged. Any deviation shows up in your signal detail with the gap highlighted. If the SL landed exactly where your strategy calculated, the signal gets a 🎯LOCKED badge. You stop guessing whether your risk matched your intent.

For duplicate fills, the bridge tracks order state per signal. A webhook that arrives twice for the same bar, the same symbol, and the same direction doesn't produce two orders. It produces one order and one 🛡️BLOCKED entry in your log.

For silent failures, FillEdge runs synthetic test signals through the full pipeline on a regular cadence. If the round-trip completes, you get a healthy status. If it doesn't, you get an email or Telegram alert within minutes telling you which leg of the pipeline broke. Your EA went offline at 3 a.m.? You know by 3:05, not by the next morning.

For stale signals, any alert older than a configurable threshold is discarded rather than executed. It shows up in your log as 💀EXPIRED, with the reason and the signal's age.

Every trade feeds into an automatic journal. Per-strategy performance, slippage averages, latency, backtest-vs-live drift. No CSV exports. No spreadsheets. The data is there, sliced by strategy, by account, by symbol.

The bridge also ships with compliance profiles for the firms traders actually use, tracking prop firm drawdown across FTMO, Funding Pips, TopStep, FundedNext, The 5%ers, and others. Bind your account to a profile, and FillEdge tracks your drawdown floor, daily loss, and consistency state in real time. If a signal would breach a rule, it gets blocked or reduced to fit your remaining risk budget. Every decision is logged with the reasoning attached.

What to check before your next evaluation

Before you start another evaluation, run through these checks regardless of what bridge you're using.

• Send test signals. Fire a webhook manually and watch the full path: does it reach the bridge, does the bridge forward it, does the EA pick it up, does the broker fill it? If any stage is invisible to you, that's where the next failure will hide.
• Check your alert messages. A typo in the alert payload, a mismatched symbol name, or a missing account tag can route a trade to the wrong destination or produce a phantom entry. Of everything you set up when automating TradingView, the alert message is the most fragile piece.
• Test a reversal. Send a long entry, then immediately send a short entry. Watch whether the close lands before the open. If your bridge doesn't sequence them, you run the risk of a reversal-reordering that will show up on the worst possible day.
• Compare your SL placement. Open a trade through the automation, then check the actual stop-loss price on your broker's terminal against the value your strategy calculated. If they differ by more than a point, you have SL drift, and it will compound over the evaluation.
• Simulate a failure. Kill your EA mid-session and see what happens to queued signals. Do they execute stale when the EA restarts? Do they disappear? Does your bridge alert you that the EA went offline?

If nobody tells you the pipeline is broken, you'll find out from your equity curve instead.

If you're evaluating options, whatever bridge connects your TradingView to MT5 should pass all five of these checks before you trust it with a funded account.

Your bridge should surface what happened to each signal after it fired. Without that, you're trading without a receipt. That's fine on a personal account. On a $100K funded evaluation with a 5% drawdown limit, it's a bet you shouldn't take.

FAQ

Why do prop firm evaluations fail even with a profitable strategy?

Most of the time, the strategy isn't the problem. The execution layer between TradingView and your broker introduces errors that the backtest can't predict: ghost positions that eat drawdown budget, duplicate fills that double your exposure, and stop-loss placement that drifts a few points from where your script calculated it. Each one is small per trade, but across dozens of signals in an evaluation, they compound into a drawdown curve that looks nothing like your backtested results. The firm's system sees a rule breach and ends the evaluation. It doesn't care that the breach came from a phantom trade your strategy never intended.

Can webhook retries cause duplicate trades on my broker?

Yes. When your bridge sends an order to the broker and the HTTP response times out, TradingView or the bridge itself may resend the webhook. If the bridge doesn't track whether the first order already filled, both orders execute. You end up with twice the position size your strategy intended, twice the exposure, and twice the potential loss. On a prop firm evaluation with a tight daily loss limit, a single duplicate on a volatile symbol like XAUUSD or NQ can breach the cap outright.

Why do my live trading results differ from my TradingView backtest?

Backtests assume perfect execution: fills at the exact price the strategy calculated, stop-losses landing precisely where the script placed them, every signal executing instantly and exactly once. Live trading adds slippage, SL drift from requotes or bridge rounding, stale signals that execute at outdated prices, and the occasional ghost position or duplicate fill. None of these show up in the Strategy Tester. Over dozens of trades, they produce a live equity curve that's consistently worse than the backtest, with no single trade to blame. The gap isn't your strategy being wrong. It's your execution layer adding noise that the backtest never modeled.

How do I test my trading automation before starting a prop firm evaluation?

Send a test signal through the full pipeline and watch every stage: does the webhook reach the bridge, does the bridge forward it, does the EA execute the fill? Then test a reversal by sending a long entry followed immediately by a short entry, and check whether the close lands before the open. Compare the actual stop-loss price on your broker's terminal against the value your strategy calculated. Simulate a failure by killing the EA mid-session and checking whether queued signals execute stale on restart. Run this on a demo account for at least a week before going live, and use the minimum lot size when you switch. The goal is to see every edge case at a size where being wrong is cheap.