MTF & Repainting

This is the most important trust page in the manual. If you read only one page beyond the Quick Start, it should be this one.

Written By Axiom Admin

Last updated About 1 month ago

MTF & Repainting

This is the most important trust page in the manual. If you read only one page beyond the Quick Start, it should be this one.

Multi-timeframe indicators on TradingView have a reputation problem, and it is deserved. Most community MTF scripts use request.security() in ways that introduce repainting β€” the historical chart shows clean, perfectly-timed readings that were never actually visible during live trading. Backtests built on those readings look good. The live experience is different. The gap between the two is where money and trust get lost.

Axiom BB Pro is designed to handle this correctly, but "correctly" is not the same as "automatically." The behavior depends on a setting you control: On Bar Close. Understanding what this setting does β€” mechanically, not just conceptually β€” is what this page teaches.


What repainting actually means

Repainting means the indicator's output on historical bars does not match what was visible on those bars during live trading.

Most traders first encounter this as a surprise: they find an indicator that looks great on historical data, build a strategy around it, go live, and discover that the readings they relied on were different in real time. The historical chart was revised after the fact β€” bars that showed one value during the live session now show a different value. The backtest was testing against information that did not exist at the time.

This is not always intentional or malicious. It is a consequence of how TradingView's request.security() function works when fetching data from higher timeframes. The default behavior, without careful handling, tends to show the final settled value of each higher-timeframe bar on all chart bars β€” even the ones that occurred while that HTF bar was still forming.


How Axiom BB Pro handles HTF data

Each slot computes its Bollinger Band inside the higher-timeframe security context. This means the basis moving average and the standard deviation are calculated on actual higher-timeframe bars β€” not on chart-timeframe bars that are then sampled or interpolated. This produces cleaner HTF values than the more common approach of requesting HTF data and computing on the chart timeframe.

But the cleanliness of the computation is not what determines repaint safety. What matters is which bar's data is used.


On Bar Close = true (the safe default)

When On Bar Close is on, the indicator uses the previous completed higher-timeframe bar's data.

Here is what that means concretely. Suppose you are on a 1-minute chart and a slot is set to the 60-minute timeframe:

  • The 60-minute candle for 10:00–11:00 AM closes at 11:00 AM.

  • Once it closes, the BB values are computed from that completed candle's data.

  • Those values become visible at 11:00 AM and remain stable until the next 60-minute candle closes at 12:00 PM.

  • During the 11:00–12:00 period, the bands reflect the 10:00–11:00 candle. They do not update.

  • On any 1-minute bar between 11:00 and 12:00, the bands show the exact same values that were visible at 11:00. No revision. No repainting.

What this looks like on the chart:

  • The bands step once per HTF candle close

  • Between steps, the bands are flat

  • Historical bars show the same stepped values that were visible in real time

  • What you see today on a bar from last Tuesday is the same thing you would have seen if you were watching last Tuesday

What this means for backtesting:

  • Safe. The historical representation matches the live representation. No future information is embedded in the historical bands.

What you give up:

  • Responsiveness. The bands do not react to what is happening during the building HTF candle. If price is crashing during the 11:00–12:00 hour, the bands still show the values from the 10:00–11:00 close. You are always looking at the previous completed candle, not the current one.

One edge case is worth naming directly. If a slot uses the chart timeframe β€” or you leave the timeframe blank so it inherits the chart timeframe β€” On Bar Close still returns the previous bar's Bollinger Band values. The history is still honest, but the slot is now a confirmed one-bar-lag view rather than a live chart-timeframe BB.


On Bar Close = false

When On Bar Close is off, the indicator uses the current building higher-timeframe bar's data.

Same scenario β€” 1-minute chart, 60-minute slot:

  • During the 11:00–12:00 candle, the BB is computed using the candle's data as it builds, updated with every new 1-minute bar

  • At 11:05, the BB reflects 5 minutes of the hourly candle

  • At 11:30, it reflects 30 minutes

  • At 11:59, it reflects 59 minutes

  • At 12:00, the candle closes, and the BB reflects the final settled value

The bands move continuously. They feel responsive. They react to what is happening right now.

The problem is what happens on historical bars.

TradingView does not store the mid-candle provisional values. When you look at the historical chart, every 1-minute bar during the 11:00–12:00 hour shows the BB values from the final settled 12:00 close. Not the provisional values that were visible at 11:05 or 11:30 β€” the final value.

This means:

  • Historical bars show a version of reality that did not exist in real time

  • The bands appear to have been perfectly aligned with the settled candle during the entire period

  • Backtests using these values are testing against information that was only available after the candle closed

  • The backtest results will overstate accuracy because they assume you knew the settled HTF value while the candle was still forming

How much overstatement? It depends on the candle's internal volatility. A quiet HTF candle settles close to its provisional values β€” the overstatement is small. A volatile HTF candle can have provisional values that differ significantly from the settled value β€” the overstatement can be large. On average, the busier the market, the worse the problem.


Why the default matters

On Bar Close defaults to on because backtesting safety is more important than real-time responsiveness for the majority of use cases.

A user who turns On Bar Close off and does not understand the consequence will produce backtests that look better than reality. They will attribute that performance to the indicator or their strategy, when it is actually an artifact of future information leaking into the historical chart. By the time they discover this β€” usually after going live and seeing worse results β€” trust is damaged and time is lost.

The default protects against this. You can choose to turn it off for specific slots when you have a specific reason and you understand what you are giving up. The indicator does not hide that option β€” it is right there in the settings, one toggle per slot. It just does not make the risky choice for you silently. And when you do turn it off, the rest of the indicator continues to work with whatever On Bar Close setting each slot has. You can mix confirmed and live slots on the same chart, which is useful when you want one "live view" slot alongside confirmed slots that anchor your structural reads.


The cross-ticker dimension

When a slot uses an Optional Ticker (a different symbol), the cross-ticker scaling ratio is also governed by On Bar Close.

On Bar Close = true: The ratio uses the confirmed (previous completed) close of both the chart symbol and the target symbol. The ratio is stable between HTF candle closes. The projected bands step once per close, like everything else.

On Bar Close = false: The ratio uses the current live close of both symbols. The ratio updates every chart bar. This introduces two layers of provisional data β€” the BB values are provisional (because the HTF candle has not closed) and the scaling ratio is provisional (because the close values are still moving). The result can be visually unstable as both the BB and the scaling multiplier shift with each bar.

For cross-ticker slots, the case for keeping On Bar Close on is even stronger than for chart-symbol slots. Two provisional inputs multiplied together compound the instability.


Verification walkthrough

This is a step-by-step procedure you can run yourself to confirm that On Bar Close works as described. It takes about 5–10 minutes with a live chart.

Step 1 β€” Set up a clear test case

  1. Open a 1-minute chart on an actively trading instrument during market hours.

  2. Make sure Slot 1 is enabled, set to the 5-minute timeframe, with On Bar Close = true.

  3. Disable other slots or set them to the chart timeframe to reduce visual noise.

Step 2 β€” Watch the confirmed behavior

  1. Note the current position of Slot 1's bands.

  2. Watch the chart for one full 5-minute cycle (five 1-minute bars).

  3. During the cycle, the bands should be completely flat β€” they do not update until the 5-minute candle closes.

  4. When the 5-minute candle closes (at the :05, :10, :15, etc. mark), the bands should step to a new position. This is the new confirmed value.

  5. After the step, the bands are flat again for the next 5 minutes.

What you are confirming: The bands update only at HTF candle close. They are not influenced by the building candle.

Step 3 β€” Compare with live (On Bar Close off)

  1. Open settings and toggle On Bar Close to off for Slot 1.

  2. Watch the same 5-minute cycle.

  3. The bands should now update with every 1-minute bar. As each new bar adds data to the building 5-minute candle, the BB recalculates and the bands shift.

  4. Note the band position at approximately 2 minutes into the cycle.

  5. Wait for the 5-minute candle to close.

  6. The bands settle on their final value. Compare this to what you noted at the 2-minute mark β€” they will likely differ, especially if the last few bars of the cycle were volatile.

What you are confirming: With On Bar Close off, the bands are provisional during the candle and may change at the close.

Step 4 β€” Check the historical difference

  1. Leave On Bar Close off and let a few 5-minute cycles complete.

  2. Scroll back to a 5-minute period you watched live. Note the band values.

  3. Now toggle On Bar Close back on.

  4. Look at the same 5-minute period. The bands should show a flat, stepped value for the entire period β€” the confirmed value from the previous 5-minute candle.

  5. Toggle On Bar Close off again. The historical bars now show the settled value for each 5-minute candle across all the chart bars in that period.

What you are confirming: Historical bars with On Bar Close off show the settled value, not the provisional values you saw live. The chart has been "rewritten" β€” not maliciously, but because TradingView does not store the mid-candle states. This is the repainting mechanism.

Step 5 β€” Return to safe defaults

Toggle On Bar Close back to on for all slots. You now have direct, personal evidence of what the setting does and why the default matters.


Summary: when to use each setting

Scenario

Recommended setting

Reason

Backtesting or strategy development

On Bar Close = true

Historical bars must match live behavior for reliable results

Discretionary trading with live monitoring

On Bar Close = true for most slots; optionally off for one "live view" slot

Confirmed values for decision-making, with an optional live reference you know is provisional

Exploring how the HTF candle is developing

On Bar Close = false (understanding the tradeoff)

You specifically want to watch the bands respond to the building candle

Cross-ticker slots

On Bar Close = true (strongly recommended)

Two provisional inputs (BB + scaling ratio) compound instability

Any situation where you want to trust the historical chart

On Bar Close = true

The entire trust model depends on this setting