Why Multi-Timeframe EAs Repaint (And Why You Should Care)
I've lost count of how many "profitable" EAs I've downloaded from forums that looked amazing in the backtest—then fell apart in forward testing. Nine times out of ten, the culprit was repainting. The EA looked at future data to decide when to enter, and the backtest happily showed perfect entries because MT4's tester doesn't punish you for peeking ahead.
When it comes to multi-timeframe EAs, the repainting problem gets worse. You're pulling data from higher timeframes onto a lower timeframe chart, and if you don't handle buffer synchronization correctly, your EA will fire signals based on incomplete or forward-shifted data. The result? A backtest equity curve that looks like a rocket launch, followed by a real account that looks like a cliff dive.
In this post, I'll walk you through building a non-repainting multi-timeframe MA crossover EA in MQL4. We'll use proper buffer synchronization techniques so your EA only sees data that was actually available at the time of the bar. No cheating. No false hope. Just honest code that behaves the same in backtest as it does on a live chart.
The Core Problem: Timeframe Data Alignment
Let's get specific. You're running your EA on an M15 chart. You want to check if the MA on H1 just crossed. The obvious approach is to call iMA(NULL, PERIOD_H1, ...) inside your OnTick() function. Looks clean, right?
Wrong. Here's the trap: when your M15 bar closes, the corresponding H1 bar might still be open. The H1 close price you're using for your MA calculation includes the last 15 minutes of data that didn't exist yet when your M15 bar actually closed. Your EA is seeing the future—just by a few minutes, but that's enough to ruin your backtest reliability.
Most traders overlook this because MT4's Strategy Tester in "Open prices only" mode doesn't reveal the issue. It assumes each bar's OHLC data is available at the open, which is false for higher timeframe data. The fix isn't complicated, but it requires discipline. You need to synchronize your buffer access so you're only reading completed bars from higher timeframes. In MQL4, that means using iClose(NULL, higherTF, shift) where shift accounts for the fact that the higher timeframe's current bar isn't finished yet.
Why "Open Prices Only" Mode Lies to You
Here's a concrete example. Say you're on M15 and checking H1 MA crossover. In "Open prices only" mode, the tester processes each M15 bar as if all data for the corresponding H1 bar is available. So when M15 bar at 10:45 closes, the tester assumes the H1 bar from 10:00 to 11:00 is complete—but it's not. The H1 bar still has 15 minutes to go. Your EA would see the H1 close at 10:45 and think the MA crossed, when in reality the H1 close at 11:00 might show no crossover at all. This is repainting, plain and simple.
I've seen EAs that show 80% win rates in "Open prices only" backtests drop to 45% in "Every tick" mode. The difference is entirely due to this timeframe misalignment. Always test on "Every tick" with real ticks if your broker provides them—or at minimum, use "Control points" mode which is more accurate than "Open prices only".
Building the Non-Repainting EA: Step by Step
Step 1: Define Your Timeframe Hierarchy
First, decide which timeframes you're using. For this example, we'll use M15 as the execution timeframe and H1 as the signal timeframe. The EA will check the H1 MA crossover but only act on M15 bar closes.
You need to handle the fact that H1 bars are four times longer than M15 bars. When the M15 bar at index 0 closes, the H1 bar at index 0 might be only 25% complete. So you can't use iMA(NULL, PERIOD_H1, ... , 0)—that gives you the current (incomplete) H1 bar's MA value. Instead, you shift to index 1 (or higher) to get a fully closed H1 bar.
Here's the rule: never read buffer index 0 from a higher timeframe. Always use shift = iBarShift(NULL, higherTF, Time[barShift]) + 1 to ensure you're looking at a completed bar. The +1 is critical because iBarShift returns the index of the bar containing the given time—which could be the current open bar.
Step 2: Implement Proper Buffer Synchronization
Let's write the synchronization function. This is the heart of the non-repainting logic. I prefer to make it robust against edge cases like missing bars or weekend gaps.
//+------------------------------------------------------------------+
//| Get synchronized higher timeframe MA value |
//+------------------------------------------------------------------+
double GetMTF_MA(int tf, int maPeriod, int maShift, int maMethod, int appliedPrice, int barShift)
{
// barShift is the M15 bar index we're checking
// We need to find the corresponding completed H1 bar
datetime barTime = Time[barShift];
// Handle edge case: if barShift is beyond available data
if(barShift < 0 || barShift >= Bars)
return 0;
int higherTFShift = iBarShift(NULL, tf, barTime, false);
// If the current higher TF bar is still open, shift back one
// We check if the barTime falls within the current higher TF bar
datetime currentH1Open = iTime(NULL, tf, 0);
datetime nextH1Open = iTime(NULL, tf, 1);
if(barTime >= currentH1Open)
{
// We're inside the current open H1 bar - use the last completed one
higherTFShift = 1;
}
else if(higherTFShift > 0)
{
// barTime is in a past H1 bar, but we need the completed bar
// iBarShift returns the bar that CONTAINS barTime
// We want the bar that CLOSED at or before barTime
higherTFShift = higherTFShift + 1;
}
else
{
// barTime is before the first H1 bar - shouldn't happen normally
higherTFShift = 0;
}
// Safety clamp
if(higherTFShift >= Bars)
higherTFShift = Bars - 1;
return iMA(NULL, tf, maPeriod, maShift, maMethod, appliedPrice, higherTFShift);
}
//+------------------------------------------------------------------+This function ensures that no matter which M15 bar you're checking, you're always reading a fully-formed H1 bar. The iBarShift function finds the H1 bar that contains the M15 bar's opening time, then we add 1 to skip the current (potentially incomplete) bar. I added explicit checks for edge cases like missing bars during weekends or broker data gaps.
Step 3: The Crossover Detection Logic
Now we need to detect a crossover using synchronized data. We'll check two consecutive H1 bars (after synchronization) to see if the fast MA crossed above or below the slow MA.
//+------------------------------------------------------------------+
//| Check for MA crossover on higher timeframe |
//+------------------------------------------------------------------+
bool CheckMTF_Crossover(int tf, int fastPeriod, int slowPeriod, int maShift, int maMethod, int appliedPrice, int barShift)
{
double fastMA_prev = GetMTF_MA(tf, fastPeriod, maShift, maMethod, appliedPrice, barShift + 1);
double slowMA_prev = GetMTF_MA(tf, slowPeriod, maShift, maMethod, appliedPrice, barShift + 1);
double fastMA_curr = GetMTF_MA(tf, fastPeriod, maShift, maMethod, appliedPrice, barShift);
double slowMA_curr = GetMTF_MA(tf, slowPeriod, maShift, maMethod, appliedPrice, barShift);
// Bullish crossover: fast crossed above slow
if(fastMA_prev <= slowMA_prev && fastMA_curr > slowMA_curr)
return true;
// Bearish crossover: fast crossed below slow
if(fastMA_prev >= slowMA_prev && fastMA_curr < slowMA_curr)
return true;
return false;
}
//+------------------------------------------------------------------+Notice we're checking barShift and barShift+1. This gives us two consecutive completed H1 bars. The crossover happens when the relationship changes from fast <= slow to fast > slow (bullish) or fast >= slow to fast < slow (bearish). We use <= and >= on the previous bar to catch cases where the MAs were exactly equal—rare but possible with certain MA methods and periods.
One thing I've learned the hard way: always check both directions even if you only trade one. If you're debugging later, seeing both signals helps you understand if the MA relationship is trending or whipsawing. You can always filter out one side in the EA logic.
Step 4: The EA Shell
Here's the complete EA structure with input parameters. I've kept it minimal—just the crossover logic and basic trade management—so you can adapt it to your own risk rules. Note the new bar detection using a static variable, which is more reliable than using Volume[0] for this purpose.
//+------------------------------------------------------------------+
//| MTF_MA_Crossover_EA.mq4 |
//+------------------------------------------------------------------+
#property copyright "Your Name"
#property version "1.00"
#property strict
// Input parameters
input int FastMAPeriod = 9; // Fast MA Period
input int SlowMAPeriod = 21; // Slow MA Period
input int MAShift = 0; // MA Shift
input ENUM_MA_Method MAMethod = MODE_EMA; // MA Method
input ENUM_Applied_Price MAPrice= PRICE_CLOSE; // Applied Price
input ENUM_TIMEFRAMES SignalTF = PERIOD_H1; // Signal Timeframe
input double LotSize = 0.1; // Lot Size
input int StopLoss = 50; // Stop Loss (points)
input int TakeProfit = 150; // Take Profit (points)
input int MagicNumber = 202401; // EA Magic Number
input bool TradeLong = true; // Allow long trades
input bool TradeShort = false; // Allow short trades
// Global variables
int ticket = 0;
//+------------------------------------------------------------------+
//| Expert initialization function |
//+------------------------------------------------------------------+
int OnInit()
{
// Validate input: SignalTF must be larger than chart timeframe
if(SignalTF <= Period())
{
Print("Error: SignalTF must be larger than chart timeframe");
return INIT_PARAMETERS_INCORRECT;
}
return(INIT_SUCCEEDED);
}
//+------------------------------------------------------------------+
//| Expert tick function |
//+------------------------------------------------------------------+
void OnTick()
{
// Only trade on new bar
static datetime lastBarTime = 0;
if(Time[0] == lastBarTime) return;
lastBarTime = Time[0];
// Check for signal on M15 bar close (index 1 is the completed bar)
// We use barShift = 1 because index 0 is the current forming bar
bool bullishCross = CheckMTF_Crossover(SignalTF, FastMAPeriod, SlowMAPeriod, MAShift, MAMethod, MAPrice, 1);
bool bearishCross = CheckMTF_Crossover(SignalTF, FastMAPeriod, SlowMAPeriod, MAShift, MAMethod, MAPrice, 1);
// Note: above both are the same call - you'd separate them in a real EA
// For now, let's just check bullish
if(CheckMTF_Crossover(SignalTF, FastMAPeriod, SlowMAPeriod, MAShift, MAMethod, MAPrice, 1))
{
// Determine direction based on MA relationship
double fastMA_curr = GetMTF_MA(SignalTF, FastMAPeriod, MAShift, MAMethod, MAPrice, 1);
double slowMA_curr = GetMTF_MA(SignalTF, SlowMAPeriod, MAShift, MAMethod, MAPrice, 1);
if(fastMA_curr > slowMA_curr && TradeLong)
{
// Bullish crossover detected - enter long
if(OrdersTotal() == 0)
{
double sl = (StopLoss > 0) ? Ask - StopLoss * Point : 0;
double tp = (TakeProfit > 0) ? Ask + TakeProfit * Point : 0;
ticket = OrderSend(Symbol(), OP_BUY, LotSize, Ask, 3, sl, tp, "MTF MA Cross", MagicNumber, 0, clrGreen);
if(ticket < 0)
Print("OrderSend failed: ", GetLastError());
}
}
else if(fastMA_curr < slowMA_curr && TradeShort)
{
// Bearish crossover detected - enter short
if(OrdersTotal() == 0)
{
double sl = (StopLoss > 0) ? Bid + StopLoss * Point : 0;
double tp = (TakeProfit > 0) ? Bid - TakeProfit * Point : 0;
ticket = OrderSend(Symbol(), OP_SELL, LotSize, Bid, 3, sl, tp, "MTF MA Cross", MagicNumber, 0, clrRed);
if(ticket < 0)
Print("OrderSend failed: ", GetLastError());
}
}
}
}
//+------------------------------------------------------------------+
// Include the synchronization and crossover functions from above
//+------------------------------------------------------------------+Testing the Non-Repainting Behavior
Before you run this on a demo account, you need to verify it's actually non-repainting. Here's my testing method, which I've refined over years of building EAs:
- Run the EA on a demo account for at least a week. Note every trade entry time and the H1 bar it was based on. I use a CSV logger for this—just a simple
FileWrite()call that records timestamp, price, and signal parameters. - Go back to the same period in the Strategy Tester using "Every tick" mode (not "Open prices only"). Use the same symbol and broker if possible, or at least the same data source.
- Compare the entry times. If they match exactly, your EA is non-repainting. If the backtest shows entries that happen before the H1 bar closed, you have a synchronization issue.
I've seen EAs that look fine on "Open prices only" but fail miserably on "Every tick" because the tick-level data reveals the forward-looking behavior. Always test on "Every tick" with real ticks enabled if your broker provides them. If your broker doesn't offer tick data, at least use "Control points" mode—it's more accurate than "Open prices only" and catches most repainting issues.
Common Backtest Pitfalls
Even with proper synchronization, you can get false positives in backtests if you're not careful. Here are three I've encountered:
1. Data gaps during holidays. Some brokers have gaps in historical data, especially around Christmas or New Year's. The iBarShift function returns -1 if the time doesn't exist in the higher timeframe. Always check for that and skip the signal if data is missing.
2. Incorrect bar index when using Time[0]. In OnTick(), Time[0] is the current forming bar. If you're checking signals on the completed bar, use Time[1] in your GetMTF_MA call. The code above uses Time[barShift] where barShift=1 for the completed bar—that's correct.
3. Broker differences in bar open times. Some brokers start their H1 bars at :00, others at :15 or :30. If your EA relies on exact bar alignment, test on multiple brokers. The iBarShift function handles this automatically, but it's worth verifying.
