Blog
Blog
Visual temporarily unavailable
This section's visual is under review and a replacement is being prepared.
Repainting indicators look perfect in backtest and fail in live trading. The mechanism is simple. Most retail signal products on TradingView have it. The five-minute test below catches almost all of them, and almost no one runs it.
This is not a scam in the traditional sense. The vendor is often not lying. The Pine Script language makes it easy to write repainting code by accident, and backtesting hides the mistake until you trade live. By then, you have already paid for the indicator. The signals that worked perfectly in history have shifted. The "73% win rate" was real for the past bars. It is not real for the future ones.
Most traders assume repainting is an obscure edge case. It is not. It is a structural property of any indicator that uses a lookback window to compute a result. The Pine Script language makes the mistake invisible to the author. The backtest shows what it should show. The live chart shows something different. The problem only becomes obvious after you have already paid for the subscription.
An indicator repaints when its historical values change after the fact. You screenshot a chart and see a buy signal on Tuesday's bar. You look again on Friday and that signal has moved or vanished. The chart history has been rewritten. This is not a display glitch. The calculation itself produced different output with more data available than it did when computed in real time.
The most straightforward version is look-ahead bias. The indicator is using data from bars that hadn't closed yet when the signal was drawn. The simplest example: an indicator that marks the "highest high of the last 20 bars." At bar 1 of the 20-bar window, the indicator doesn't know what the high will be at bar 20. It can only resolve that calculation once all 20 bars have closed. If the code draws a signal at bar 1 based on the eventual highest high, it is using future data. On a live chart, looking forward from bar 1, that signal does not exist yet. On a historical chart, looking backward, it appears perfectly placed.
Work through this concretely. Suppose you're on a 4-hour chart. It is Monday morning. The indicator marks support at the lowest low of the last 20 bars. At this moment, the 20-bar window runs backward from Monday and forward in time doesn't exist yet. The lowest point in that lookback window is some level set on Friday. By Thursday of the following week, 5 new bars have printed. Some of them may set a lower low. The indicator now redraws the support line at the new lowest low, and the historical location of that line on Monday's bar shifts. The signal that appeared at Monday's open now appears at a slightly different level, or is gone entirely.
This is not a contrived scenario. It is the normal behaviour of any indicator that uses a lookback window to identify a local extremum: support/resistance levels, pivot points, fractal-based signals, "swing high" and "swing low" markers. All of them are computing something that only resolves after the lookback period has fully elapsed. In backtesting mode, all bars are already closed, so the calculation is trivial. In live mode, only the bars that have actually closed are available.
There is a more subtle version that catches people who think they've avoided the obvious trap. Some indicators don't use explicit future data, but their calculations don't finalise until several bars after the signal appears. The signal appears on bar N. The algorithm continues adjusting its output for bars N+1, N+2, N+3 as new data comes in. The visible output on bar N's candle changes for the next several bars after it. In backtesting, you see the final, settled state. Live, you see the intermediate state, which is different.
The chart looks the same in both modes. The signal labels appear identical. The difference is invisible unless you record what the chart actually showed at each point in time and compare it to what it shows later.
Before you pay for any indicator, before you run a formal backtest, before you do anything else: run this test. It takes five minutes to set up and one week to produce a result. If you're not willing to wait a week, that is itself a problem.
If signals moved or disappeared, the indicator repaints. Stop there. Nothing else you test about it matters.
If signals are in exactly the same positions, the indicator passes this basic check. It does not repaint on this timeframe. This does not mean the strategy works, but it does mean you're working with stable signals.
There is a faster version using TradingView's bar replay mode. Rewind the chart to 30 bars back, start the replay, and advance bar by bar. Record what the indicator shows at each bar as the price unfolds. Then exit replay mode and compare to the settled historical view. Any difference is repainting.
Most traders never do either version of this test. The chart looks compelling right now, and that's enough to pull out a credit card. The vendor's marketing page shows a screenshot of the backtest. The screenshot looks perfect. The product ships, the subscription starts, and the live signals fail within days.
The test exists. Most people skip it.
The economic structure of the indicator marketplace is designed to produce exactly this outcome.
Many vendors do not know their code repaints. The Pine Script language makes the mistake easy: security() with lookahead=barmerge.lookahead_on, calculations on bar_index that do not account for live vs settled bars, signals triggered on close before the bar closes. The language is beginner-friendly, which means mistakes are invisible to authors who do not already understand the problem. A backtest that shows 70% win rate will look perfect. The backtest is not lying. It is showing what the code produces on settled data. The vendor publishes it and believes the strategy works. They have never tested it live.
Some vendors know. They have learned that backtest screenshots are the sales mechanism. Customers do not run a one-week verification test. An indicator marketed with 90% accuracy that is technically impossible to replicate live is more profitable than one with 55% actual live accuracy. The incentive structure is straightforward: publish what looks exceptional in backtesting, not what works in production.
TradingView's marketplace runs on a rental model. Sellers earn a share of every monthly subscription. This creates volume pressure: more subscriptions means more revenue, and subscriptions are acquired through marketing the backtest result. There is no mechanism in the marketplace to measure live performance versus marketed performance. A vendor whose indicator repaints catastrophically in live trading earns the same per-rental fee as one whose indicator does not. Refund policies do exist (TradingView Help Center, "Refund policy"), but enforcing them requires navigating the vendor's processes.
Private Telegram channels and Discord groups are the distribution layer beneath the marketplace. Here the product is sold not by TradingView but by the group owner, usually with screenshots of claimed live trades. These screenshots are almost always cherry-picked, sometimes fabricated. The buyer has no way to verify the claim without running the indicator themselves on historical data, where it will look excellent, because it repaints.
The buyer's discovery of the problem is structurally delayed. In the first few days of live trading, the indicator generates signals. The signals look like the historical signals because the recent bars haven't settled yet. The divergence between backtested performance and live performance only becomes obvious over two to four weeks, when enough bars have settled that the historical distortion is clearly visible. By then, the subscription has renewed once. Getting a refund requires navigating a vendor who has an incentive not to give one.
Some vendors are defrauding people. Many are not. The mechanism operates independently of intent.
"Smart Money Concepts" (SMC) has become the dominant retail trading framework over the last five years. The terminology comes primarily from the ICT (Inner Circle Trader) methodology (Inner Circle Trader, public materials), which is a real and substantial body of analytical work. ICT uses legitimate microstructure-adjacent concepts: institutional order flow, liquidity pools, imbalances in price structure. The underlying analytical framework has merit. The third-party indicator implementations of that framework frequently do not.
The specific problem with SMC-style indicators is that their core concepts are often defined retroactively.
"Order blocks" are supposed to identify institutional accumulation zones: the last bearish candle before a significant bullish move, or the last bullish candle before a significant bearish move. The definition requires knowing that a significant move followed. In live trading, you don't know yet whether the current move is significant. The indicator can only correctly identify an order block after price has moved far enough away to confirm the significance of the move. Many implementations draw the order block retrospectively, on historical bars, once the move has confirmed. What you see in history is a chart where every major move has a neatly-placed order block just before it. What you get live is signals that appear and shift as price moves.
"Fair value gaps" are actual price phenomena: inefficiencies where the market moved quickly enough that a range of prices was visited only once, leaving a gap in the two-sided auction. They are real. Price does return to fill them with statistically meaningful frequency. The problem is that many indicators draw fair value gaps after the move, not at the time the gap was created. A gap that appears in history on Tuesday's chart may not have been drawn on Tuesday's live chart because the confirmation bar hadn't closed yet.
"Breaker blocks" have a similar issue: they require identifying whether a previous order block "broke." This break confirmation is only available after subsequent price action confirms it. Indicators that mark breaker blocks often revise their historical marks as new bars confirm or invalidate previous structures.
The test from the previous section applies here without modification. Screenshot the last 30 SMC-style signals on any indicator you're using. Wait a week. Compare. If the order blocks shifted or the fair value gaps moved, the indicator is computing historical structures retroactively.
This is not an argument against the ICT methodology itself. The underlying concepts can be valid. It is an argument that third-party Pine Script implementations of those concepts are frequently calculating them in ways that only work on settled history. The gap between the theoretical concept and its code implementation is where the repainting lives.
Repainting is the clearest failure mode. But it is the most visible symptom of a deeper limitation that affects every indicator built on OHLCV data, whether it repaints or not.
A candle is a four-number compression of all trading activity within a period. Open, high, low, close. It discards the sequence in which prices were visited, the volume at each price level within the period, the direction of buying pressure at each moment, and the state of the orderbook at any point during the bar. A 15-minute candle on a liquid crypto pair summarizes tens of thousands of individual trades into four numbers. The information loss is enormous.
Any indicator built on those four numbers is working with a heavily compressed approximation of what actually happened. For slow strategies, the approximation is close enough. For anything intraday or faster, the compression destroys the information that would actually distinguish a good entry from a bad one.
There is also a timing problem specific to live execution. Indicators that trigger on bar close fire at the close of the candle. Your execution happens 2 to 10 seconds after that close, while other participants who also trade on bar close are already moving. The price you see at signal time is not the price you get. High-frequency participants who trade on tick-level data have already repositioned before your bar-close signal even fires.
This is not a complaint about high-frequency trading. It is a structural observation about candle data. Strategies that appear to execute at bar close in backtesting actually execute at the following open in live markets, because the close price is only available after the bar has already closed and the next bar has already started. The backtested entry price and the live entry price are different, systematically, in the direction that hurts your strategy.
Backtesting compounds this. A strategy that looks profitable on historical OHLCV data has been optimized on a dataset that does not contain the information a live trader needs: bid-ask spread at execution time, orderbook depth available at the intended price, or the sequencing of trades within each bar. The result is strategies that win in backtesting and lose live, not because the edge was imaginary but because the backtest was testing something that doesn't correspond to the actual execution environment.
Repainting is just the most egregious case of this problem. But even non-repainting indicators built on candle data carry these limitations. The candle itself is a simplification that systematically hides information.
The distinction that matters is not sophistication. It is whether the historical record and the live record are the same thing. Order flow data records what actually happened, at the resolution where decisions were made.
Every trade execution produces a record: price, size, direction (buyer-initiated or seller-initiated), and timestamp. The orderbook records the queue of resting limit orders at every price level, updated with each change. This data is not a summary. It is not a four-number compression. It is the event log of the auction.
Order Flow Imbalance (OFI) is the simplest useful metric from this data: the ratio of aggressive buying volume to aggressive selling volume over a rolling window. Cont, Kukanov, and Stoikov (2014) formalized its relationship to short-term price changes in the academic literature, but the intuition is straightforward. When buyers are hitting the offer faster than sellers are hitting the bid, price is about to move up. The signal precedes the price move because it is measuring the pressure, not the outcome.
Kyle (1985) introduced the concept that now carries his name, Lambda: the price impact per unit of signed order flow. It measures how much the market moves per dollar of net buying or selling. Higher Lambda means thinner, more vulnerable liquidity. Lower Lambda means deeper, more resilient liquidity. This metric is computed from execution data and cannot be approximated from candles.
OFI does not repaint. The aggressive buy at 14:23:07.412 is a historical fact. The order that was placed at price X, quantity Y, at that exact timestamp, was filled or it wasn't. Nothing that happens later changes that record. When you look at OFI computed over a historical window, you are looking at the same number you would have computed in real time at that timestamp. The signal you test is the signal you would have traded.
This is the actual distinction that matters. The candle's close price is also a historical fact and doesn't repaint. The difference is what each data source contains. The close price tells you one data point per bar. The order flow event log tells you the complete sequence of decisions by buyers and sellers throughout the period.
The honest caveat is that this doesn't guarantee any particular strategy works. Order flow data contains real information about market dynamics. Plenty of order flow strategies fail. The edge is harder to find than vendors of microstructure data tools will admit. But the epistemological situation is different: when you test an OFI-based strategy on historical data, you are testing the same signal you would observe in live trading. The test corresponds to the reality.
Purpose-built microstructure data infrastructure records these signals as they occur, with timestamps. The OFI value at 14:23:07 on any historical date matches the OFI value you would have computed in real time at 14:23:07 on that date, because it is the same underlying record. This is what it means for a data source to not repaint: the historical record and the live record are the same thing.
Run the screenshot test before anything else. One week. If signals move, stop. Do not use it for entries. A signal that changes after the fact has no predictive value for the moment you need to place the trade.
Some indicator categories are almost certainly safe. RSI, MACD, Bollinger Bands, and standard EMA crossovers all compute from settled bar data using calculations that finalize on bar close. A 14-period RSI at bar close uses only the 14 most recent close prices, all of which are settled. The calculation does not change when new bars arrive. These are legitimate tools with their own limitations, but repainting is not among them.
The categories that require testing are: anything claiming to identify "smart money" activity, order blocks, liquidity levels, breaker blocks, institutional accumulation, or market maker footprints from candle data. These are the categories where the definition of the signal requires confirming information that isn't available until after the moment the signal is supposed to fire. Also test: any indicator with a "signal delay" setting, any indicator that claims to repaint only on the current bar (many still repaint several bars back), and any indicator whose marketing focuses on historical backtest screenshots rather than independently verified live performance.
TradingView's marketplace has a refund policy for purchased indicators. If you've bought something within the last week and discovered it repaints, request a refund through the platform's support system. The process is not instant but it exists. Private Discord and Telegram vendors are less cooperative. Treat private vendor refund prospects as low from the start.
The harder conclusion is about backtesting as a methodology. Most retail backtests fail on three dimensions simultaneously. First, the data: candle data does not contain the information a live strategy needs. Second, the execution model: bar-close entries, no slippage, no spread, no order size. Third, the sample size: 200 trades on a single timeframe in a single market regime is not a statistically valid sample for an edge that produces 5 signals per week.
An indicator that doesn't repaint is necessary but not sufficient. A backtest that runs on realistic data with realistic execution assumptions is necessary but not sufficient. Statistical significance over a large sample across multiple market conditions is necessary but not sufficient. Most retail strategies fail before even reaching the first of those three requirements.
The repainting indicator is the most obvious failure. At least that failure is diagnosable with a one-week screenshot test. The deeper problems take longer to find and are harder to fix. Start with the obvious one.
It means the historical signal you see on the chart is not the same signal you had in real time. The marker moved, vanished, or appeared only after later bars closed.
No. Many common indicators such as RSI, MACD, and standard moving averages use settled bar data and do not repaint in the same way. The higher-risk category is anything that identifies future-confirmed structure from candle data.
Yes. That is exactly why the problem survives. The backtest only sees the settled historical chart, not the unstable signal state that existed while the trade decision had to be made.
Use the screenshot test or bar replay. Record the last 30 signals, wait, and compare. If signals shift, disappear, or appear later in the same historical area, the indicator repaints.
Use different data, not more versions of the same candle input. Order flow imbalance, market microstructure for traders, and why indicator-only trading fails are cleaner starting points.