# Article-24649-GrangerMTF-Causality-Detection

This repository is an article-derived reference project based on the original MQL5 article. It does not claim to reproduce the full original source code unless files are explicitly attached.

## Overview

This project documents a complete multi-timeframe causality detection pipeline for MetaTrader 5. Instead of assuming that a higher timeframe always informs the lower, the system tests that relationship statistically and uses the result to filter signals at runtime.

The pipeline automatically:

- Fetches historical EURUSD OHLC data for M5, M15, M30 and H1 directly from MetaTrader 5
- Converts prices to log returns and verifies stationarity with an ADF test
- Builds look-ahead-free design matrices aligned so each lower-TF bar only sees already-closed higher-TF bars
- Selects lag structure by BIC and fits restricted and unrestricted OLS models for each timeframe pair
- Runs a Granger F-test, cross-checks it against statsmodels, and adds an HC3 robust Wald test
- Scans rolling windows to measure how stable each relationship is over time
- Corrects for multiple comparisons across all four pairs with Benjamini–Hochberg
- Exports a calibration table to `Terminal\Common\Files` for the EA to read
- Repeats the same F-test live on a rolling window inside MQL5 at runtime
- Marks each pair VALID or INVALID based on both the offline table and the live result
- Generates BUY/SELL signals from the votes of causally valid pairs only
- Gates every trade through the live causality check before execution
- Manages positions with ATR-based stop loss and take profit
- Publishes pair statuses as terminal global variables for use by other EAs

The project demonstrates how a statistical test developed in Python can be reproduced exactly in MQL5 so that the offline research and the live system stay faithful to the same rules.

## Original Article

**Article ID:** 24649
**Author:** Hlomohang John Borotho
**Category:** Experts
**URL:** [https://www.mql5.com/en/articles/24649](https://www.mql5.com/en/articles/24649)

## Repository Purpose

This repository should be treated as a reference or reconstruction project derived from the article content.

Its purpose is to:

- Test whether higher timeframes statistically Granger-cause lower timeframes before trading on that assumption
- Demonstrate look-ahead-free multi-timeframe alignment in both Python and MQL5
- Reproduce an F-test and rolling causality monitor natively in MQL5 without external libraries
- Provide a reusable causality-filtering framework that works on any symbol or timeframe pair
- Serve as a foundation for regime-aware Expert Advisor development

## Key Concepts

### Timeframe Pairs

The system tests four lead → lag relationships. The lead must always be the higher timeframe.

| Pair | Lead | Lag | EURUSD Result |
|------|------|-----|---------------|
| H1 → M15 | H1 | M15 | INVALID (F ≈ 0, stab 9%) |
| M30 → M15 | M30 | M15 | VALID (F = 9.64, stab 43%) |
| M15 → M5 | M15 | M5 | INVALID (F = 4.84, stab 20%) |
| H1 → M5 | H1 | M5 | INVALID (F ≈ 0, stab 6%) |

### Look-Ahead-Free Alignment

For each lower-TF bar opening at time `t`, only higher-TF bars whose open time is at or before `t - lead_period` are used as regressors. This rule is identical in Python and MQL5. Any deviation between the two stages would make the offline coefficients meaningless at runtime.

### Granger F-Test

Two OLS models are compared per pair:

- **Restricted model** — constant plus `q` own lags of the lower-TF return
- **Unrestricted model** — restricted model plus `p` lags of the completed higher-TF return

If adding the higher-TF lags reduces the residual sum of squares by more than chance would allow, the F-statistic is large and the pair is a candidate for VALID status.

### Rolling Stability

The F-test is repeated on every consecutive window of `WINDOW` bars, stepping forward by `STEP`. The fraction of windows where the pair is significant is its stability score. A pair passes only when both its adjusted p-value and its stability clear their thresholds.

### VALID / INVALID Decision

| Condition | Required |
|-----------|----------|
| Adjusted p-value (BH) < ALPHA | Yes |
| Rolling stability ≥ STABILITY_MIN | Yes |
| OOS directional edge > 0 | Optional (REQUIRE_OOS_EDGE) |

## Algorithm / Architecture Summary

### 1. Data Fetch (Python)

OHLCV data is pulled from MetaTrader 5 using `copy_rates_range` for all four timeframes. `copy_rates_from_pos` is not used because it fails with Invalid params at the bar counts required for M5 over 150 days. The last (forming) bar is always dropped before any calculation.

### 2. Feature Engineering (Python)

Prices are converted to log returns in basis points (`SCALE * np.log(close / close.shift(1))`). ADF tests confirm prices are non-stationary and returns are stationary. The design matrix is built with `np.searchsorted` to enforce the look-ahead-free cutoff without any forward fill.

### 3. Label Generation (Python)

The target for each lower-TF bar is its own log return, in basis points. This is a regression problem, not a classification problem. The "label" is the raw return the model is trying to forecast. Sign of the forecast becomes the vote direction; magnitude relative to return std controls the threshold via `InpMinEdgeSigma`.

### 4. Granger F-Test (Python)

Lags are selected by BIC over a grid of `p` from 1 to `MAX_P` and `q` from 1 to `MAX_Q` on the training 70%. The hand-written F-test is cross-checked against `sm.OLS(...).compare_f_test(...)` with an assert. An HC3 robust Wald test on the higher-TF coefficients is run alongside to flag cases where heteroskedasticity inflates the classical F.

### 5. Rolling Stability and Correction (Python)

The rolling scan uses the same `WINDOW` and `ALPHA` the EA will use live. Benjamini–Hochberg is applied across all four pairs to control the false discovery rate.

### 6. Export (Python)

The calibration table is written to `Terminal\Common\Files` with `\r\n` line endings and plain ASCII so the EA can read it with `FILE_TXT | FILE_ANSI`. One row per pair: `lead_tf, lag_tf, p, q, window, alpha, f_stat, p_value, p_adj, stability, oos_hit, oos_edge_bps, status`.

### 7. EA Deployment (MQL5)

The EA reads the CSV on `OnInit`. On each new signal bar it re-runs the F-test on the most recent `WINDOW` bars per pair (every `InpRetestBars` lower-TF bars), computes a return forecast from the fitted coefficients, and casts a vote. Votes from VALID pairs only are aggregated into the final signal. A trade opens only when the signal changes.

### 8. Position Management (MQL5)

Stop loss and take profit are set as ATR multiples on the signal timeframe at entry. The opposite-signal exit is optional via `InpCloseOnOpposite`.

## Signal Generation

**Buy signal** — at least `InpMinVotes` VALID pairs forecast a positive return, zero forecast a negative return

**Sell signal** — at least `InpMinVotes` VALID pairs forecast a negative return, zero forecast a positive return

## Risk Management

Stop loss distance:

```
SL = ATR(InpATRPeriod) × InpSL_ATR
```

Take profit distance:

```
TP = ATR(InpATRPeriod) × InpTP_ATR
```

## A/B Testing

Setting `InpUseCausalityFilter = false` disables the causality gate entirely. The EA then signals from all pairs regardless of VALID/INVALID status, acting as the unfiltered baseline. Running both configurations over the same tester period isolates the filter's contribution to performance.

Note: because the filter changes the signal frequency significantly, the two modes may require separate optimisation passes. Applying filter-OFF optimised inputs with the filter ON often results in no trades.

## Granger Causality: Concept Mapping

| Granger Term | Trading Interpretation |
|---|---|
| Lead series | Higher timeframe bar returns |
| Lag series | Lower timeframe bar returns |
| Restricted model | Forecast from own past returns only |
| Unrestricted model | Forecast from own past returns plus completed higher-TF returns |
| F-statistic | Evidence that the higher TF adds predictive information |
| p-value (adjusted) | Probability of the observed F under the null of no causality |
| Rolling stability | Fraction of time windows where the relationship is significant |
| VALID | Pair cleared all thresholds — allowed to vote |
| INVALID | Pair failed — blocked from voting when filter is on |
| Vote | Sign of the forecast: +1 BUY, -1 SELL, 0 flat |

## Mentioned or Attached Files

**Primary Components**

- `GrangerMTF_Causality.ipynb`
- `GrangerMTF.mq5`
- `README.md`

**Generated Artifacts**

- `granger_mtf_causality.csv` — calibration table written to `Terminal\Common\Files` by the notebook

## Statistics

**Pipeline Components**

- Data Fetch Module: 1
- Stationarity Check Module: 1
- Alignment and Feature Engineering Module: 1
- Granger F-Test Module: 1
- Rolling Stability Module: 1
- Multiple Testing Correction Module: 1
- Export Module: 1

**EA Components**

- CSV Loader: 1
- OLS Solver (Gaussian elimination): 1
- Live F-Test Engine: 1
- Forecast and Vote Engine: 1
- Signal Aggregator: 1
- Trade Execution Module: 1
- Panel and Visualisation Module: 1
- Global Variable Export Module: 1

**Timeframe Pairs**

- Total pairs tested: 4
- Pairs marked VALID on EURUSD (150 days): 1

## Tags

`MQL5` `MetaTrader5` `GrangerCausality` `MultiTimeframe` `StatisticalFilter` `OLS` `F-Test` `TimeSeries` `Expert-Advisor` `Algorithmic-Trading` `Python` `Statsmodels` `Scipy` `Feature-Engineering` `Strategy-Testing` `RollingWindow` `BenjaminiHochberg`

## Difficulty

Moderate to Advanced — requires familiarity with:

- MQL5 Expert Advisor development
- Python data science toolchain (pandas, numpy, scipy, statsmodels)
- Linear regression and F-test mechanics
- Time series stationarity concepts
- Multi-timeframe bar alignment and look-ahead bias
- Rolling window statistical analysis
- Multiple hypothesis testing correction

## Limitations

- Causality is tested on a single symbol — same-symbol timeframes share the same price process, so a VALID result means longer history adds predictive information beyond short own lags, not that an external driver exists.
- Rolling stability at 43% for M30 → M15 means the relationship is absent in more windows than it is present. The live re-test mitigates this but does not eliminate it.
- The 150-day calibration window overlaps the backtest period in the article. Offline VALID/INVALID labels are partly in-sample relative to what the EA traded.
- Out-of-sample directional hit rate for the one VALID pair was 50.0%, below the restricted-model baseline. Statistical significance did not translate to bar-by-bar directional accuracy.
- The OLS solver in MQL5 adds a small ridge term (1e-9) for numerical stability. This is not present in the Python version and introduces a negligible but non-zero difference in coefficients.

## Future Improvements

Potential enhancements include:

- Calibrating the notebook on data that ends before the backtest starts for a fully out-of-sample test
- Regime-specific VALID/INVALID thresholds (trending vs. ranging conditions)
- Cross-symbol Granger tests where lead and lag are different instruments
- Adaptive `STABILITY_MIN` that tightens in low-volatility regimes
- Confidence-based position sizing proportional to the forecast magnitude
- Periodic notebook recalibration and automatic CSV refresh
- Multi-symbol training to identify which pairs Granger-cause each other across instruments
- Integration with the Part 10 AutoML pipeline to use Granger-filtered signals as ML features

## Reference

Original MQL5 article: [https://www.mql5.com/en/articles/24649](https://www.mql5.com/en/articles/24649)