Guide

TradingView backtest accuracy

Last reviewed: 26 September 2026·Tradelyze

TradingView backtest accuracy is how closely the Strategy Tester's simulated trades match the fills you could actually have gotten. The Strategy Tester replays your Pine Script rules faithfully on chart bars, but by default it guesses how price moved inside each bar. Comparing a second backtest's trades with yours, one by one, shows where those guesses change the result.

New to this? Start with exporting TradingView trades and price data.

What do Match Rate, Matched, TV Only and BT Only mean?

Match Rate is the share of trades that Tradelyze's re-run and your TradingView export agree on. The re-run is Tradelyze backtesting your Pine Script a second time, on the price file you uploaded. Match Rate is the large percentage on the Backtest vs TradingView card. A higher figure means the two backtests are more likely to be testing the same strategy.

Tradelyze counts two trades as a match when both go the same direction and their entry times are within five minutes of each other. Exit times, prices and profits are not part of the test. Your trade list's times are converted to UTC from the Trade List Timezone you chose before they are compared.

Only trades inside your price file are compared, on both sides. A trade that entered before the file's first bar, or was still open at its last bar, is left out whole. When the price file runs on past your export's last trade, re-run trades that enter after that point are left out too, because TradingView's list says nothing about them. The start gets no such allowance. A re-run trade inside the price file but before your export's first trade counts as BT Only, so that exporting only your last few trades cannot score 100%. No trades are set aside as warmup.

TV Trades counts only the TradingView trades that were compared, so Matched plus TV Only equals TV Trades. BT Trades counts every re-run trade, including any left out of the comparison, so Matched plus BT Only can be smaller than BT Trades. At a 100% match the card drops the counts and shows the line "Every backtest trade matched TradingView".

Rounding matters near 100%. The card shows one decimal, so 99.96% displays as 100.0% while the counts still show the unmatched trades. The halt check reads the figure rounded to two decimals, so 99.96% still counts as below 100% and stops the run, while 20,001 matched trades and 1 unmatched re-run trade count as 100% and pass.

In that constructed example, 88.1% shows amber. 8 TradingView trades never happened in the re-run, and 10 re-run trades inside the export's dates have no TradingView partner. The other 6 BT Only trades come from the week of price data before the export starts; a trade list that also covered that week would give them TradingView trades to match.

For runs made now, the Backtest vs TradingView card shows these counts, not the trades themselves. Read them for a pattern. Matched far below both counts points to a clock problem, such as the wrong Trade List Timezone. A large BT Only beside a small TV Only points to re-run trades your export does not cover. After optimization, the TradingView Verification panel under a trial in the Top Trials table lists matched and unmatched trades for that trial's settings once you upload a TradingView CSV, on trials whose trade list was kept.

What match rate is good enough?

No published standard says what match rate is good enough. Tradelyze's colors for Match Rate are a display choice: green at 90% or more, amber at 80% or more, and red when lower.

The colors are separate from the decision to halt a run, which uses the required match stated on the Optimization stopped card. The Match % column on the strategies list and dashboard uses the same colors. The TradingView Verification panel on a trial uses its own: green at 90% or more, amber at 60% or more, red below 60%. The number of trades matters as much as the color. A green 90% of 40 trades leaves 4 unexplained trades, while 90% of 2,000 trades leaves 200.

What the unmatched trades were matters most. Suppose the TV Only trades include the biggest winners or the worst losing days. The re-run's profit and drawdown can then differ sharply from TradingView's, even with a green figure.

Why don't my trades match TradingView?

Trades usually fail to match TradingView because of a setting or the data, not because either backtest is broken. Check these causes roughly in the order they are quickest to rule out:

1. Trade List Timezone. Beside the trade list upload, Tradelyze's form asks for "the timezone TradingView showed in the chart's bottom-right corner when you exported this trade list". Your trades are converted from it to UTC before matching, and the form warns that "the wrong zone shifts every trade and real matches read as mismatches." In one internal Tradelyze test, a 1,275-trade export measured 100.00% on its chart timezone (India Standard Time) and 16.24% read as UTC. The backtest had reproduced it trade for trade; only the clock differed. That was a single test, not a general accuracy rate. Chart Timezone is the clock your price file is read in, and the separate Exchange Timezone field sets where trading days start for prop-firm rules. The export guide's timezone section shows which zone to choose.
2. Indicator warmup. Indicators need a run of bars before they give values; a 200-bar moving average has nothing to say on bar 50. If your price file starts at a different point from TradingView's chart history, the two backtests start trading at different times. Tradelyze does not set those early trades aside: a re-run trade TradingView did not take counts as BT Only, and a TradingView trade the re-run missed counts as TV Only. Exporting the price data and the trade list from the same chart, with the same history loaded, avoids this.
3. Properties or Inputs changed only in TradingView. Tradelyze takes initial capital, commission, slippage, order size, pyramiding and input values from the script itself. They come from the strategy() header and the input() defaults. Did you change them in TradingView's Properties or Inputs tab? Then the upload form tells you to "update the defaults in your script to match and upload it again." TradingView strategy properties explains what commission, slippage and pyramiding each change. The export guide explains why script defaults must match what you ran.
4. Price data for a different range or timeframe. The price file must be for the same instrument and timeframe as the chart you exported from. Trades that cross the file's first or last bar are left out of Match Rate on both sides, and re-run trades before your export's first trade count as BT Only. If the two files cover separate dates, no trade can match.
5. Extra timeframe files for request.security(). When a script reads another timeframe, the upload form asks for a price file for that timeframe as well. Tradelyze has not yet confirmed that extra-timeframe data is applied correctly in every case. With a multi-timeframe script and a low match, check this early: compare trades around the higher timeframe's bar changes.
6. Fill settings. Bar Magnifier, process_orders_on_close and similar settings change which bar and price an order fills at. A setting that exists only in TradingView's Properties window is not in the script you upload.

Fill settings cause the most disagreement when a stop and a target both sit inside one bar. A chart bar records only four prices, its open, high, low and close. Those four prices cannot show which level price reached first.

After fixing a cause, submit the strategy again so Baseline Matching measures the corrected setup. What to fix first when trades do not match walks through a timezone example step by step.

Why does Tradelyze re-run my backtest before optimizing?

Tradelyze re-runs your backtest first because every later result is useful only if it tests the strategy you tested on TradingView. Backtest trade matching is how that is checked: the re-run's trades are compared with your TradingView export, trade by trade. The first stage of every run is Baseline Matching, which the app describes as "Backtesting your strategy and checking its trades against your TradingView export".

At Baseline Matching, Tradelyze backtests your Pine Script once on the price file you uploaded. It uses the script's own strategy() and input() defaults. The backtest runs on Tradelyze's own Pine Script backtester, and no AI rewrites your script. Its trade list is lined up against the trade list you exported from TradingView's Strategy Tester. The guide to exporting TradingView trades and price data covers both files.

If the match is lower than the figure Tradelyze requires, the run stops before optimizing anything. An amber card titled Optimization stopped shows the measured match and three counts: Matched, Backtest trades and TradingView trades. It also names the clock the trades were compared on. The explanation on that card begins "The backtest of your strategy reproduced" and normally states the percentage required. Two buttons follow: Continue anyway, and Review comparison, which opens the Backtest vs TradingView card with its counts.

What happens if I click Continue anyway?

Continue anyway lets a run that stopped at Baseline Matching go on to optimize Tradelyze's re-run of your strategy as it is. The Optimization stopped card states the consequence: "Every number the run reports will describe that build, not the one your TradingView export came from."

Clicking Continue anyway opens the optimization dialog. The run you submit from it skips the match check and nothing else. Optimization, walk-forward analysis, robustness scoring and prop-firm evaluation then all run on the re-run build.

Continue anyway is reasonable once you can explain the unmatched trades and they are few. An example is a handful of trades at the very start of the file while indicators warm up. It is a poor choice when the cause changes the trades themselves. Examples are a wrong Trade List Timezone or Chart Timezone, Properties or Inputs changed only in TradingView, or a price file covering different dates. Fix those and submit again, because they change the trades the whole analysis is built on.

How does a low match change the rest of my results?

A low match means the rest of your Tradelyze results describe the re-run build. That build trades differently from the strategy in your TradingView report, and every later card inherits the difference:

• Best Metrics and Recommended Parameters are tuned on the re-run build. They are in-sample, meaning measured on the same prices they were tuned on. That makes them the most optimistic figures on the page; see why Tradelyze's best metrics are in-sample.
• Top Trials ranks settings of the re-run build, not of your TradingView version.
• The walk-forward badge (Confirmed or Not Confirmed, Consistent or Not Consistent, Inconclusive, or NO VERDICT) describes the re-run build. It rests on unseen data only when the method label beside it reads Re-tuned each window; see what makes a walk-forward result pass or fail.
• The robustness score and verdict stress-test the re-run build's trades; see what ROBUST, ACCEPTABLE, MARGINAL and FRAGILE mean.
• Each prop firm's Qualifies or Not Feasible badge is scored on the re-run build's days; see what Qualifies means.

A concrete case: the TV Only trades include the days with the largest losses. A Qualifies badge can then describe a build that never took those losing days. The daily loss rule it passed is not the one your TradingView strategy would face. Fix the cause of the mismatch, submit again, and judge the results only once the match is explained. Low trade counts weaken every one of these checks too, as overfitting and sample size explains.

What does TV Comparable From mean?

TV Comparable From is the first timestamp from which Tradelyze's figures can be compared with TradingView's own figures for the same strategy. Before that time, both backtests are still filling their indicators' lookback bars. They will disagree for reasons that have nothing to do with the strategy.

Tradelyze has a TV Comparable From tile on the Best Metrics card and a column in the Top Trials table. Its current backtester does not report the timestamp, so runs made now show a dash (—) in both places. TV Comparable From does not affect Match Rate. When you set a Tradelyze result beside your TradingView report, compare them from the first bar where your indicators have enough history, not from the first bar of the file.

Is TradingView backtesting accurate?

TradingView backtesting accurately simulates your Pine Script rules on the chart's bars. It is not a record of fills you could have gotten. The Strategy Tester uses a broker emulator, the part that plays the role of your broker. TradingView's Pine Script documentation on strategies says the emulator fills orders "using only the available chart data by default."

So "accurate" breaks into four separate questions:

• Are the fills realistic for how price moved inside each bar?
• Are the settings in the report the ones you meant to test?
• Does the script use only data it could have known at the time?
• Would a second, independent backtest of the same script on the same data take the same trades?

Trade matching answers only the last question. A low match is often the first sign that one of the other three has a problem.

TradingView's documentation also separates backtesting from live conditions. In forward testing, it says, trading costs, slippage and liquidity can meaningfully change performance. This matters for your money: a live account or a prop-firm challenge fee gets sized from the Strategy Tester's numbers. If a re-run cannot reproduce the trades, those numbers rest on details you may not have chosen on purpose.

How does TradingView's Strategy Tester decide when orders fill?

TradingView's Strategy Tester fills orders on historical bars by following a set of stated default assumptions. TradingView's Pine Script documentation on strategies sets them out:

• Orders wait for the bar to close. By default a strategy calculates once each bar closes. The earliest an order can then fill is the open of the next bar.
• The path inside a bar is assumed, not known. When a bar opens closer to its high, the emulator assumes open → high → low → close. When it opens closer to its low, it assumes open → low → high → close.
• Limit orders fill at their price or better. Once price reaches the limit level, the order fills there or at a better price. The backtest_fill_limits_assumption parameter can require price to move past the level first.
• Fills on the close are optional. With process_orders_on_close = true in the strategy() declaration, market orders fill on the close of the bar that created them. Without it, they fill at the next bar's open.

Strategies with tight stops and targets that often fit inside a single bar depend most on this assumption. They are also where two backtests of the same script most often disagree. A small difference in how a bar is read flips the trade's result.

process_orders_on_close matters for trade matching too. It moves fills for orders placed at a bar's close one bar earlier, from the next open to that same close. TradingView's documentation says the "Order execution delay" setting in the Properties tab overrides it. The "Limit order execution" setting overrides backtest_fill_limits_assumption in the same way. Changed only in Properties, either setting is missing from the script you upload. Entries can then shift by a bar and fall outside Tradelyze's five-minute matching window.

What does Bar Magnifier change, and who can use it?

Bar Magnifier is a TradingView setting that looks at smaller bars inside each chart bar to decide which price was hit first. Without it, the Strategy Tester follows the fixed rule in TradingView's Pine Script documentation: price reaches whichever of the high or low is nearer the open first. TradingView's Help Center article on bar magnifier backtesting mode says the setting makes results "more similar to what would happen during forward testing" over the same period.

Bar Magnifier is not on every TradingView plan. TradingView's Pine Script documentation limits this extra intrabar detail to Premium and Ultimate plan users. TradingView changes its plans from time to time, so confirm on TradingView's own pricing page.

The setting goes by two names. TradingView's Help Center calls it Bar Magnifier and says it is toggled in the strategy's Settings/Properties window. The Pine Script documentation calls it Bar detalization, with a "High" option in the Properties tab and at the top of the strategy report. A script can switch it on by default with use_bar_magnifier = true in its strategy() declaration.

Bar Magnifier has a ceiling on long histories. TradingView's Help Center says a strategy cannot request more than 200,000 lower-timeframe bars. The Pine Script documentation adds that bars without intrabar data fall back to the default assumed path. Worked example (constructed arithmetic, not measured data): on a 5-minute chart each bar holds ten 30-second bars. That allows about 200,000 ÷ 10 = 20,000 of the most recent chart bars to be magnified. With 40,000 bars loaded, roughly the older half still uses the assumed path.

Bar Magnifier matters most when a strategy's stop and target often sit inside the range of a single chart bar. A strategy whose stop and target are usually many bars apart rarely meets a bar where the order of the high and low decides the trade. Before paying for a plan to get Bar Magnifier, check how often one bar in your trade list touched both the stop and the target.

For trade matching, the practical point is where the setting lives. Tradelyze builds its run from the script's own strategy() and input() defaults, not from TradingView's Properties window. A setting you switched on only in that window, Bar Magnifier included, is not part of the file you upload. Tradelyze has not confirmed whether its re-run applies use_bar_magnifier = true from a script header, so treat trades on wide bars as the likeliest mismatches either way.

What is Deep Backtesting, and is there a trade limit?

Deep Backtesting is a TradingView Strategy Tester mode that tests a chosen date range on all the history TradingView holds for a symbol, not only the bars loaded on the chart. TradingView's Help Center article How Deep Backtesting works says it starts when you open a strategy and select a time range, marked by a pink icon. Clicking Reset to chart session stops it.

• Which plans. The same Help Center article lists Deep Backtesting for Premium and higher plans.
• How much data. That article gives a limit of "up to two million bars and one million trades." A second Help Center article says a period longer than 2 million bars runs on its most recent 2 million bars.
• How many trades are kept. TradingView's documentation on the trade limit says a regular test keeps individual data for only the latest 9,000 trades and trims older closed trades. Trimmed trades are missing from the report's trade list and from downloaded CSV files. Deep Backtesting keeps every trade.
• Where results show. Only in the Strategy Report tab, not on the chart, according to TradingView's Help Center.
• Different numbers. TradingView's Help Center notes that a regular report and Deep Backtesting can give different results for the same strategy.

For trade matching, a trimmed report means an exported trade list that can begin later than your price file. Tradelyze's re-run then takes trades before TradingView's first exported trade. Those trades count as BT Only and lower Match Rate. That is deliberate: otherwise exporting only your last few trades could score 100%. The cleanest fix is to export a date range that covers the same period as the price data you upload. For a strategy with more than 9,000 trades, that usually means exporting from Deep Backtesting, the mode that keeps every trade.

Can repainting or request.security lookahead make a backtest look better than it is?

Yes: repainting is when a Pine Script calculates differently on historical bars than it would have in real time. The dangerous kind in a backtest is a future leak, such as request.security() with lookahead on and no one-bar offset, which TradingView's documentation says returns "data from the future on historical bars." Tradelyze does not check scripts for repainting, so a high Match Rate shows only that two backtests agree on the same historical bars. Pine Script repainting and look-ahead bias explains how to test your script and write a non-repainting request.

Stage 1 · step 3 of 18. Next in the learning path: How to read a Tradelyze report

Frequently asked questions about TradingView backtest accuracy

Sources

• TradingView, Pine Script documentation, Concepts / Strategies: sections Broker emulator, Adjusting historical bar detail (including the Bar detalization setting and the 200,000-bar lower-timeframe limit), Limit orders, process_orders_on_close, Slippage and unfilled limits, Backtesting and forward testing, and Trade limit. Retrieved 15 September 2026.
• TradingView, Pine Script documentation, Concepts / Repainting: sections Introduction, Future leak with request.security(), and Strategies. Retrieved 15 September 2026.
• TradingView Help Center, What is bar magnifier backtesting mode, including the chart-to-intrabar timeframe table and the 200,000-bar limit. Retrieved 15 September 2026.
• TradingView Help Center, What is Deep Backtesting. Retrieved 15 September 2026.
• TradingView Help Center, How Deep Backtesting works. Retrieved 15 September 2026.
• TradingView Help Center, How much data is available for Deep Backtesting. Retrieved 15 September 2026.
• Tradelyze implementation, reviewed 26 September 2026, trade matching: the Baseline Matching stage backtests the uploaded Pine Script once with the script's own strategy() and input() defaults; the trade list is converted to UTC from the Trade List Timezone; trades are paired when they share a direction and their entries fall within five minutes of each other; only trades that enter and exit inside the uploaded price file are compared, on both sides; re-run trades that enter after the trade list's last trade are left out when the price file runs past it; re-run trades before the trade list's first trade count as BT Only; no trades are set aside as warmup; Match Rate is matched trades divided by the larger of the two compared trade counts, rounded to two decimals before the halt check and shown to one decimal; the card's TV Trades counts compared TradingView trades and BT Trades counts every re-run trade; the card lists trades one by one only on results from the earlier matching flow; the current backtester does not report TV Comparable From.
• Tradelyze implementation, reviewed 26 September 2026, display, halt and email: Match Rate on the Backtest vs TradingView card, and the Match % column, are green at 90% or more, amber at 80% or more and red otherwise; the TradingView Verification panel is green at 90% or more, amber at 60% or more and red otherwise; a match under the required figure halts the run before optimization, with Continue anyway and Review comparison actions; the below-target email, stating the match is "below your 100% target", was sent only by the earlier matching flow and is not sent for runs submitted now; upload-form and card wording is quoted as shown in the app.
• Tradelyze implementation, reviewed 26 September 2026, stage and verdict wording: the app's one-line description of the Baseline Matching stage; the Optimization stopped card's wording, including "The backtest of your strategy reproduced" and "Continuing optimizes this backtest of your strategy as-is"; the walk-forward badges Confirmed, Not Confirmed, Consistent, Not Consistent, Inconclusive and NO VERDICT, with Re-tuned each window as the only method label whose windows are tested on prices their settings were not tuned on; the four scored robustness checks.
• Tradelyze testing record, reviewed 14 September 2026: a 1,275-trade TradingView export that the backtest reproduced trade for trade measured 100.00% on its chart timezone (India Standard Time) and 16.24% read as UTC. This is a single internal test, not a general accuracy rate.