Why your MetaTrader trades don't match your TradingView chart

You open MetaTrader, and there's a position on XAUUSD that your strategy never called. TradingView shows a clean backtest. MT5 shows a trade that shouldn't exist. The two are supposed to agree, and they don't.

This isn't a charting discrepancy or a data feed lag. When MetaTrader trades don't match your TradingView chart, the cause almost always lives in the pipeline between the two. Ghost positions, signal reordering, and stop-loss drift. Those three do most of the damage, and across a month of live trading, they compound into an equity curve that looks nothing like your backtest.

The signal pipeline between TradingView and MetaTrader

Before diagnosing what breaks, you need to see what the signal actually travels through. Four stages. Each one is a potential failure point.

Stage one: your Pine Script strategy detects a setup and calls strategy.entry() or strategy.close(). Stage two: TradingView fires a webhook carrying the alert message you configured. That's an HTTP request. Stage three: a bridge server receives it, parses the payload, and formats the instruction for the terminal. Stage four: an Expert Advisor running in MetaTrader picks it up and places the order with your broker.

Every stage is a potential failure point. The loud failures (webhook rejected, EA offline, broker error 10018) are obvious and you fix them in minutes. The expensive failures are silent. The signal goes through all four stages, a trade appears on your account, and nobody tells you it doesn't match what TradingView intended.

If you're building a TradingView to MT5 bridge yourself or trying to connect MT5 to TradingView with a generic tool, these silent failures are what you'll eventually hit.

Ghost positions: trades your strategy never asked for

A ghost position is a trade sitting on your broker account that your strategy never intended. It's the single most common reason MetaTrader trades don't match TradingView. And it's the hardest to detect because the trade looks normal in your terminal.

No error code. No rejection. Just a position that shouldn't exist.

Ghost positions happen because of a timing gap in how TradingView strategies work. Your strategy calls strategy.entry() the moment the setup triggers. TradingView fires the alert at that instant, not after the bar closes, not after the fill confirms. If the strategy recalculates on the next tick and the condition is no longer true, TradingView doesn't send a correction.

The alert is already gone. The webhook is already traveling. The bridge has already forwarded it. And now MetaTrader has a position your strategy doesn't even know about.

Duplicate webhooks are another common source. TradingView's alert system retries on timeout. If the bridge server is slow to respond (500ms is enough), TradingView may send the same alert twice. Two identical orders hit your broker. You now have either double the intended lot size or two separate positions on the same symbol, depending on whether your MT5 account is in netting or hedging mode.

A third cause: stale alerts. You modify your Pine Script, but the old alert configuration is still active in TradingView. The webhook keeps firing based on conditions that no longer exist in your current script.

None of these produces an error message. On a $2,000 account, a ghost XAUUSD position that moves 30 pips against you costs around $30. Not catastrophic. But if you're running an FTMO evaluation, that same ghost trade might eat half your daily loss allowance. You won't know until you check the firm's dashboard hours later.

Signal reordering: when close arrives after open

A reversal is two signals: close the current position, open a new one in the opposite direction. In your Pine Script, that's one line of code. On the wire, it's two separate HTTP requests traveling to your bridge server.

HTTP does not guarantee delivery order. The "open short" can arrive before the "close long." If the bridge forwards both in the order they arrived, your MetaTrader terminal processes them wrong.

The EA opens the short. Both positions sit on the account briefly. When "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. Your strategy thinks you flipped to short, but your broker is still long.

This failure is time-dependent. It happens most often during volatility spikes, when your strategy is most likely to reverse and when the network is most congested. Your TradingView webhook is correctly formatted. Your strategy logic is sound. The failure is in the transport layer, and no amount of Pine Script debugging will fix it.

Stop-loss drift: your risk isn't where your strategy placed it

Your strategy calculates a stop loss. Maybe it's structure-based: below the last swing low at 1.0842 on EURUSD. Or volatility-scaled, like 1.5x ATR from entry. The point is, your script knows where that stop should sit.

The problem starts when that stop loss travels through the bridge. Different strategies need different SL modes. A structure-based stop needs to land at an exact price, regardless of where you got filled. An ATR-based stop needs to preserve the distance from your actual entry, because the whole point is a volatility-scaled offset.

Most bridges only support one mode. If yours sends distance-from-entry and your strategy uses structure-based stops, the math breaks every time you experience slippage.

Your strategy places the stop loss at 1.0842, just below a support level. The logic is structural: if price breaks through support, you want out. If it bounces, your stop should be far enough below to survive the wick.

Entry was supposed to be 1.0870. You slipped to 1.0873. The bridge calculates the distance (28 pips) and applies it to the actual fill, placing your stop at 1.0845. That's 3 pips above the support level your strategy was trying to protect. The stop is no longer below support. It's sitting in the zone where bounces happen, and the next wick that tests the level takes you out of a trade your strategy intended to hold.

The reverse problem affects volatility-based strategies that use a bridge that only sends exact prices. Your ATR stop was supposed to be 20 pips from entry. You slipped 3 pips. The bridge sends the pre-calculated price, and now your stop is 17 pips from where you actually entered. Tighter than intended. You get stopped out on noise that your strategy was designed to absorb.

This is the hardest mismatch to spot. Your MetaTrader terminal shows a stop loss that looks reasonable. You don't check whether it's at 1.0842 or 1.0845. The drift is invisible until you have to deal with prop firm risk management rules and wonder why your live drawdown keeps exceeding what your backtest predicted.

Why most bridges don't catch any of this

The typical approach to building a trading bot for TradingView is forwarding: receive a webhook, pass the instruction to the EA. Some bridges are fast. Some handle symbol mapping well. But almost none of them compare what TradingView sent with what the broker actually did.

That comparison is the part that matters. Without it, you don't know whether the trade on your account matches the signal from your strategy. You just assume it does. And most of the time, you're right. The problem is "most of the time" across 200 signals a month means four trades that went wrong without anyone noticing.

Most bridges also don't understand the strategy state. They see each webhook as an independent instruction, with no memory of what came before. They don't know that the close signal should precede the open. They don't know this alert already fired 400ms ago. Ghost positions and signal reordering pass right through.

One mismatch can end a prop firm evaluation

On a personal retail account, a ghost position or a drifted stop loss costs you money you didn't plan to lose. Bad, but recoverable. On a prop firm evaluation, the same mismatch can end the entire run.

Prop firm rules don't distinguish between a trade you intended and a trade your automation produced by accident. If a ghost position opens and moves against you, that loss counts toward your daily drawdown limit. FTMO gives you 5% daily. Funding Pips gives you 4% on some configurations. A single phantom XAUUSD trade that drops 50 pips can consume most of that budget in one shot.

The drawdown in prop firms math gets worse when automation adds trades that the strategy never called. Your strategy might risk 1% per trade, carefully staying inside the daily limit. But the ghost trade sits outside that model: unhedged, unsized, running on whatever default lot the duplicate alert carried. One bad hour and the evaluation is over.

FillEdge addresses this with compliance guardrails. You bind your account to a prop firm profile (FTMO, Funding Pips, Apex, TopStep, FundedNext, and others), and the bridge tracks your live drawdown, daily loss, and consistency state against that firm's specific rules. Every incoming signal is evaluated before it reaches your broker. If the trade would push you past a limit, FillEdge either blocks it entirely or reduces the lot size to fit inside your remaining risk budget.

How FillEdge makes MetaTrader trades match your TradingView strategy

FillEdge is a bridge that verifies, not just forwards. Every signal is reconciled against the resulting trade: what TradingView sent (the intent) versus what the broker did (the result). Mismatch? FillEdge tells you what happened.

Every signal gets a status badge. ✓MATCHED means the intent and fill agree on price, size, and stops. 👻CAUGHT means a phantom signal was intercepted before reaching the broker. 🛡️BLOCKED means a duplicate was stopped. 🔀REORDERED means out-of-sequence reversal signals were delivered in the correct order. 💀EXPIRED means a stale signal was discarded.

For ghost positions, FillEdge inspects every incoming signal against your strategy's current state. If the signal would produce a duplicate, a position the strategy contradicts, or a fill already accounted for, the bridge catches it before it reaches the terminal. You see the interception in your dashboard with the reason and what would have happened if it had gone through.

For signal reordering, FillEdge sequences reversal pairs deterministically. The close always completes before the open begins, regardless of which webhook arrived first. If one half of a reversal never shows up, the orphaned signal is held rather than executed alone.

For stop-loss drift, you choose per strategy. Exact-price mode places your stop at the literal level your script calculated, regardless of entry slippage. Distance mode preserves the offset from actual fill for ATR-based strategies. The right mode depends on your strategy logic, not the bridge's default. TradingView webhook automation carries the SL instruction through the full pipeline, and the reconciliation confirms the stop landed where your strategy intended.

Every signal in the dashboard shows intent versus result. When your MetaTrader trades don't match TradingView, you see exactly which signal diverged and why. No more comparing screenshots to trade history by hand.

FAQ

Why does my MT5 trade show a different entry price than TradingView?

TradingView calculates entries on historical bar data, and your alert fires at that calculated price. Your broker fills the order at whatever price the market is actually trading when the instruction arrives. The gap between the two is slippage, and it's normal. It gets worse during volatility spikes and on brokers with wider spreads, because the market moves further in the time it takes the signal to travel from TradingView through the bridge to your terminal.

Can a TradingView alert fire a trade that my strategy didn't intend?

Yes. Your strategy calls strategy.entry() the moment a condition triggers, and TradingView fires the alert immediately. If the strategy recalculates on the next tick and the condition is no longer true, TradingView doesn't send a correction. The alert is already traveling. The result is a position on your broker account that your strategy no longer wants. Duplicate webhooks (from TradingView retrying on timeout) and stale alerts (from old configurations you forgot to delete) cause the same problem.

Why does my stop loss land at a different price than my script calculated?

Most bridges send stop losses as either an exact price or a distance from entry, but not both. If your strategy uses a structure-based stop (placed at a specific level like just below support) and the bridge sends it as a distance, any entry slippage shifts the stop away from the level your strategy was protecting. The reverse happens with ATR-based stops: if the bridge sends the pre-calculated price instead of preserving the distance from your actual fill, slippage tightens the buffer your strategy designed into the trade.

How do I know if my live trades match my TradingView backtest?

You need to compare what TradingView sent (the signal) with what your broker did (the fill) on every trade. Most bridges don't do this. They forward the signal and assume the result is correct. FillEdge reconciles every signal against the resulting fill and tags each one: ✓MATCHED if they agree, 👻CAUGHT if a phantom signal was intercepted, 🛡️BLOCKED if a duplicate was stopped, 🔀REORDERED if reversal signals were sequenced correctly, or 💀EXPIRED if a stale signal was discarded.

Why did my prop firm evaluation fail when my strategy was profitable?

A profitable strategy can still fail an evaluation if automation adds trades the strategy never called. A ghost position that moves against you counts toward your daily drawdown limit. The prop firm's dashboard doesn't label it as a ghost. It shows a loss. If that loss pushes you past the daily limit (5% on FTMO, 4% on some Funding Pips configurations), the evaluation is over regardless of how well your actual strategy performed that day.