TL;DR: A multi-timeframe trading strategy uses a higher timeframe for direction or regime and a lower timeframe for entries. The single most important rule is to use only completed higher-timeframe bars: at 13:00, the last 4H value you may read is the bar that closed at 12:00, not the one still forming. Get that wrong and the backtest quietly trades on future prices. In Trigr, each condition node can run on its own timeframe, and higher-timeframe values become visible only when their bar closes.
What is a multi-timeframe strategy?
Traders have long combined timeframes: decide the direction on a daily or 4-hour chart, then time the entry on an hourly or 15-minute chart. The logic is sound. The higher timeframe filters out noise and keeps you on the right side of the dominant move; the lower timeframe gives better entry prices and tighter risk.
Common structures:
- Trend plus pullback: 4H price above its 200 EMA, enter long on a 1H RSI dip.
- Regime plus breakout: 1D ADX above 25 (trending), enter on a 4H Donchian breakout.
- Volatility gate: only trade 15-minute signals when the 1H ATR is within a normal range.
Each of these reads two different bar series at every decision. That is where things go wrong.
Why is look-ahead bias so common in multi-timeframe backtests?
Consider a strategy on 1H bars that uses a 4H trend filter. At 13:00, your 1H bar has just closed. The 4H bar covering 12:00 to 16:00 is one quarter complete. Its eventual close, high and low are unknown.
Yet a naive implementation often uses exactly that bar. Three ways it happens:
1. Joining on the bar label. Many tools label a 4H bar by its start time (12:00). If you merge 1H and 4H data on timestamps, the 13:00 row finds the 12:00 4H bar, whose values include prices up to 16:00. The pandas resample documentation shows that for hourly-based frequencies the default is to label and close bins on the left edge, which is exactly this trap if you then join on the label.
2. Requesting the higher timeframe with look-ahead enabled. Charting platforms that let a script request another timeframe usually have an option controlling whether the in-progress bar is visible. TradingView's Pine Script documentation on other timeframes and data discusses how historical and realtime behavior differ, a common source of "repainting" signals that looked perfect in history and behave differently live.
3. Computing the indicator on the forming bar. Even with correct alignment, recalculating a 4H EMA on every 1H bar using the partial 4H candle's current price produces values that would never have existed at the 4H close. In live trading the value keeps changing until the bar completes.
The effect is not subtle. A 4H trend filter that sees three extra hours of price will look remarkably good at avoiding losing trades. The look-ahead bias guide has more worked examples, and the principle behind all of them is covered in the point-in-time backtesting guide.
What does "completed bars only" look like on a timeline?
Here is a 1H strategy with a 4H filter, bar by bar:
| 1H bar closes at | Latest completed 4H bar | 4H value the strategy may use | Order fills at |
|---|---|---|---|
| 12:00 | 08:00 to 12:00 | Close at 12:00 | Open of 12:00 to 13:00 bar |
| 13:00 | 08:00 to 12:00 | Still the 12:00 close | Open of 13:00 to 14:00 bar |
| 14:00 | 08:00 to 12:00 | Still the 12:00 close | Open of 14:00 to 15:00 bar |
| 15:00 | 08:00 to 12:00 | Still the 12:00 close | Open of 15:00 to 16:00 bar |
| 16:00 | 12:00 to 16:00 | New value: close at 16:00 | Open of 16:00 to 17:00 bar |
Two things follow. First, the higher-timeframe value is stale for most of its bar. That is not a bug; it is the honest cost of using a slower signal. Second, the higher-timeframe filter can only change state on its own bar boundaries, so it reacts slowly to sharp reversals. Design exits with that in mind: a 4H trend filter will not get you out of a 1H position quickly, so use the RISK node's stop, trailing stop or time stop for that.
How do you build a multi-timeframe strategy in Trigr?
A Trigr strategy is a node graph: one trigger, optional filters, a signal, a risk node and an execute node. The no-code strategy builder guide walks through the full structure. For multi-timeframe work, the relevant detail is that trigger and filter nodes can carry their own timeframe, independent of the strategy's primary timeframe. Supported timeframes are 5m, 15m, 30m, 1H, 4H, 1D, 1W and 1M.
The engine's rules for mixing them:
- Completed bars only. A node reads only data available at the bar's close. A higher-timeframe value becomes visible at the close of its own candle and is carried forward until the next one completes, exactly as in the table above. The engine is checked against a reference implementation for this case, including that no higher-timeframe value appears before its candle closes.
- Next-bar-open fills. Once the combined signal fires on a closed bar, the order fills at the next bar's open on the strategy's timeframe.
- Cross-asset works the same way. A 4H BTC filter on a 1H SOL strategy is both multi-timeframe and cross-asset; alignment follows the same carry-forward rule. The cross-asset signals guide covers that side.
- Warmup is real. An indicator needs its length times its timeframe of history before it produces a value. A 200 EMA on 1D needs about 200 days. On 1W it needs about four years, which may exceed the available history for newer assets.
An illustrative example
An idea to test, not a recommendation. It trades BTC on 1H bars.
- Trigger: BTC 1H RSI(14) < 35 (a pullback).
- Filter: BTC 4H price above its 50 EMA (intermediate trend up).
- Filter: BTC 1D price above its 200 EMA (long-term trend up).
- Signal: long when all three hold.
- Risk: 10% size, 2x leverage, long only, max 1 position, 3% stop-loss, ATR trailing stop, time stop at 48 bars.
Three timeframes, each with a job: the daily defines the bull regime, the 4H confirms the intermediate trend, the hourly times the entry. If you cannot give a timeframe a job in one sentence, it probably does not belong in the graph. For a fuller trend-following build, see the BTC trend-following strategy guide.
How do you choose the timeframes?
A few principles hold up better than any specific combination.
- Keep a meaningful ratio. Roughly 4 to 6 times between levels (15m and 1H, 1H and 4H, 4H and 1D) is a common rule of thumb. Timeframes that are too close add little; timeframes too far apart make the higher one react very slowly.
- Match the holding period. If trades last a few hours, a weekly filter is essentially a constant. It will not hurt, but it will not help either.
- Mind the costs of the lowest timeframe. Lower timeframes produce more trades. Fees and the builder fee are always applied in Trigr, but slippage and funding are opt-in; turn them on, because a 15-minute entry layer can multiply cost drag.
- Do not tune the timeframes. Trying every combination of three timeframes across eight options is hundreds of variants. Pick them from the holding period and the hypothesis, then iterate on other parameters as labeled experiments inside one strategy so the trial count stays visible.
How should you check the backtest?
Multi-timeframe strategies deserve a few extra checks beyond the usual net-of-costs read.
- Trade clustering around higher-timeframe boundaries. If many entries happen on the first 1H bar after a 4H close, that is expected. If entries seem to anticipate 4H changes, suspect a data problem in whatever tool produced the result.
- Filter-on versus filter-off. Run the strategy without the higher-timeframe filter. A genuine regime filter usually cuts drawdowns and trade count; a leaking one cuts losing trades with suspicious precision.
- The audit trail. Trigr's backtest shows the equity curve, monthly returns, the full trade log and an audit trail that flags real versus simulated inputs and names cross-asset references. The how to read a backtest guide covers the rest.
Keep two limits in mind: a plain backtest does not compute the Deflated Sharpe Ratio (ML optimization runs do), and the shaded trailing 25% in Studio is a recent-period diagnostic rather than an out-of-sample holdout. Real out-of-sample evidence comes from a frozen strategy on a paper agent.
What this means for you
You get multi-timeframe logic without writing resampling code, and without the most common way that code goes wrong. The same alignment rules apply in the backtest, on paper and live, so the filter that looked right in history reads the same values in production.
Backtests are not guarantees; perps are leveraged and can lose more than expected.
Next steps
Take a single-timeframe strategy you already have, add one higher-timeframe filter with a stated purpose, and compare net results. The backtesting docs explain fills and costs in detail, and the marketplace has verified strategies you can study for structure.