Higher Timeframe Confirmation

Filter trades by confirming signals with a higher timeframe trend using request.security().

One of the most effective filters you can add to any strategy is requiring the higher timeframe to agree with your trade direction. If you are trading on the 1-hour chart and the daily chart is in a downtrend, you are fighting the dominant market force — and your win rate will suffer for it. Most of the losing trades in a single-timeframe strategy are against the larger trend. HTF confirmation eliminates a large portion of them.

The core idea is straightforward: signals generated on the current timeframe are only acted on when a higher timeframe agrees with the direction. Long signals are only taken when the HTF is bullish; short signals only when the HTF is bearish. The noise of the lower timeframe gets filtered through the structural clarity of the higher one.

In Pine Script, `request.security()` is the function that gives you access to price data and indicator values from any timeframe within your script.

Why timeframe alignment matters

Most trading strategies generate signals on one timeframe and ignore everything else. The problem is that a bullish crossover on the 15-minute chart means very little if the daily chart is in a strong downtrend. The 15-minute signal might work for 30 minutes, then get crushed by the dominant daily selling pressure.

Higher timeframe confirmation forces your strategy to answer a prior question before entering: does the trade direction make sense in the larger picture?

This filters two types of losing trades that single-timeframe strategies cannot avoid:

• Counter-trend trades — shorts in established uptrends and longs in established downtrends
• Noise trades — small signals that form during consolidation within a larger directional move

When a strategy stops taking these, its win rate typically improves materially even though the total number of trades decreases. Fewer trades, better trades.

Choosing your timeframes

A common guideline is to use a higher timeframe that is 4–6× larger than your entry timeframe. This gives the HTF enough distance to represent a genuinely different market perspective without being so far removed that it becomes useless as a day-to-day filter.

| Entry Timeframe | Suggested HTF | |---|---| | 1-minute | 5-minute or 15-minute | | 15-minute | 1-hour or 4-hour | | 1-hour | 4-hour or Daily | | 4-hour | Daily or Weekly | | Daily | Weekly |

The exact ratio is less important than the principle: the HTF should represent trend, not entry timing. If the HTF changes direction every few bars, it is not functioning as a trend filter — it is just adding lag.

What to confirm at the higher timeframe

HTF confirmation works best when it is used to define trend direction, not to generate entry signals. Common HTF filters include:

• Price above/below a moving average — is price above the 50-period EMA on the daily chart?
• Moving average slope or crossover — is the daily fast EMA above the slow EMA?
• ADX level — is the HTF ADX above 20, indicating a trend is actually present?
• Swing structure — is the HTF making higher highs and higher lows (uptrend) or lower highs and lower lows (downtrend)?

The example code uses an EMA crossover at the higher timeframe. The daily fast EMA being above the daily slow EMA is treated as bullish context — only long signals from the lower timeframe are accepted.

Understanding request.security() behaviour

`request.security()` takes four main arguments: ticker, timeframe, expression, and lookahead setting.

The lookahead setting controls when the HTF value updates on your chart. With `barmerge.lookahead_off` (the default), the value only updates after the HTF bar has closed. This means if you're on a 1-hour chart and requesting daily data, the daily value only changes once per day when the daily candle closes — exactly as it should be for backtesting.

With `barmerge.lookahead_on`, the HTF value reflects the final close of the HTF bar as soon as the bar opens. In backtesting this allows the script to "see" the future value of a bar that hasn't closed yet, which inflates performance results. Always use `barmerge.lookahead_off` unless you have a specific, well-understood reason to do otherwise.

Practical impact on strategy performance

Adding an HTF filter to an existing strategy almost always reduces the total number of trades. This is by design — you are removing the trades that conflict with the larger structure. The expectation is that the trades you do take have a higher probability of success.

The key metrics to watch when adding HTF confirmation:

• Win rate — should increase as counter-trend losers are removed
• Average trade duration — may increase as you only trade in the direction of larger moves
• Maximum drawdown — should decrease as losing streaks driven by trending-against-you periods are avoided
• Profit factor — should improve even if total P&L stays similar, because you are losing less on losers

//@version=6
strategy("Multi-Timeframe Strategy", overlay=true)

// Inputs
htf = input.timeframe("D", "Higher Timeframe")
fastLen = input.int(9, "Fast EMA")
slowLen = input.int(21, "Slow EMA")

// Higher timeframe trend
htfFast = request.security(syminfo.tickerid, htf, ta.ema(close, fastLen))
htfSlow = request.security(syminfo.tickerid, htf, ta.ema(close, slowLen))
htfBullish = htfFast > htfSlow

// Current timeframe signals
ltfFast = ta.ema(close, fastLen)
ltfSlow = ta.ema(close, slowLen)

// Only trade in direction of HTF trend
longSignal = ta.crossover(ltfFast, ltfSlow) and htfBullish
shortSignal = ta.crossunder(ltfFast, ltfSlow) and not htfBullish

if (longSignal)
    strategy.entry("Long", strategy.long)
if (shortSignal)
    strategy.entry("Short", strategy.short)

// Visual feedback
bgcolor(htfBullish ? color.new(color.green, 95) : color.new(color.red, 95))
plot(ltfFast, "Fast", color=color.green)
plot(ltfSlow, "Slow", color=color.red)