From our research notebook

Python, Cointegration and Machine Learning in MT5 Workflows

We explain how our research and integration work brought Python models, time-aware data preparation and MT5's execution responsibilities into one discussion.

Python gave us room to work on data, statistical relationships and predictive models. Connecting that work to MT5 introduced a different set of questions: what exactly did a result mean, when was it valid and how could the terminal interpret it consistently?

We aligned the observations before the outputs

A model built with cleaned bars may meet bid/ask prices, missing history and broker-specific sessions in the terminal. We therefore pay attention to price source, timezone, bar completion and calculation order. Without agreement there, comparing two final numbers can be misleading.

We treated time as part of the method

Cointegration asks about a relationship that may change. Machine learning adds fitted transformations and targets that can accidentally use later information. We work through estimation windows, chronological validation and the point at which a relationship or model output must be considered stale.

We defined what could cross into MT5

We describe the hand-off with a model or output version, source timestamp, feature meaning and expiry. Execution still has its own job: checking symbol conditions, risk permission and broker responses. The AI Lab follows the local-model and API branches of this wider journey in more detail.

Explore the technical detailOpen the full method, worked examples and implementation questions. We have kept this material here so you can follow the reasoning as far as you need.

Python is a strong research environment for cleaning data, estimating relationships, testing features, and comparing models. MT5 is the execution environment that must make a timely decision from broker data and handle real orders. A reliable workflow treats the boundary between them as a contract, not as an informal file exchange.

Cointegration and machine learning illustrate the same challenge in different ways. A statistical relationship can decay, and a predictive model can look convincing after leakage or repeated tuning. Neither should reach execution until its inputs, timing, validation, and failure behaviour are reproducible.

Engineering note · ENG-08

From research notebook to live decision

Each stage produces an artifact that the next stage can verify.

  1. 01
    DataFix symbols, timezone, bar policy, corporate or contract adjustments, and missing-data rules.
  2. 02
    ResearchEstimate relationships or features without future leakage and retain out-of-sample periods.
  3. 03
    ContractFreeze model version, inputs, transformations, outputs, timestamps, and fallback behaviour.
  4. 04
    ExecuteReproduce the decision in MT5, validate freshness, apply risk permission, and log the result.

Start with the data contract

Research and execution must agree on price source, timezone, bar close, spread treatment, symbol mapping, missing values, and calculation order. A model trained on clean midpoint bars can behave differently when MT5 receives bid/ask ticks, incomplete history, or a broker-specific session boundary.

Cointegration is a monitored relationship

A stationary spread in one sample is not a permanent trading law. Pair selection, hedge-ratio estimation, test windows, structural breaks, transaction costs, and re-estimation policy all affect the result. The operational question is not only whether a relationship existed, but when the live system must declare it stale.

Machine learning needs a time boundary

Feature scaling, target construction, cross-validation, and hyperparameter search must respect chronology. Random splits can leak market regimes across training and validation. Repeatedly selecting the best backtest also creates a hidden test set made from the researcher’s own decisions.

Deploy a reproducible artifact

The live system should receive a frozen model or an exact decision output with a version, timestamp, feature schema, and expiry. It also needs a safe response to stale files, unavailable Python processes, malformed values, or a model that lies outside its approved operating conditions.

  • Version the dataset, feature code, model, and MT5 adapter together.
  • Recreate research features from MT5 data before deployment.
  • Use chronological validation and untouched final periods.
  • Define freshness and fallback rules before live execution.
  • Monitor input drift, relationship decay, and decision parity.

Questions you may have

Does MT5 need to run Python for every decision?

No. Models can be exported, signals can be exchanged through a controlled interface, or Python can run as a separate service. The correct choice depends on latency, reliability, and maintenance needs.

Does cointegration prove two assets will converge?

No. It describes a historical statistical relationship under specific assumptions. The relationship can weaken or break, and trading costs can remove any apparent advantage.

POLARIS / R19

Keep the research clock intact when a model reaches MT5

Scroll the diagram horizontally or open it at full size.

Keep the research clock intact when a model reaches MT5
Educational design example — values and states are not live performance.

No future observations may feed the earlier selection step.

Open full diagram ↗

Evidence in practice

Keep the research clock intact when a model reaches MT5

A minimal cointegration workflow starts with two price series that are each plausibly I(1), applies the Engle–Granger test on the training window, estimates the hedge relation there and evaluates the spread later. A low training p-value is evidence against no cointegration under the test assumptions; it is not a permanent trading guarantee.

Walk-forward information split
Window Allowed work Fitted information Not allowed
Jan–Jun train Fit transformation, hedge ratio and rule candidates Only data through Jun 30 Using later prices or final scaler
Jul validation Choose among frozen candidates Training fits applied unchanged Repeated tuning without recording a new search
7-day embargo Remove overlapping labels/positions across boundary No decisions Treating overlapping outcomes as independent
Aug test One final comparison with simple baseline after costs Frozen data and artefact versions Refitting after seeing test result
Sep forward Observe MT5 messages and execution Only information available at each timestamp Revised bars or future joins

Compare the selected model with a simple baseline such as a fixed z-score rule using the same data, costs and position limits. If complexity does not add stable out-of-sample value, it has not earned an execution burden. Set re-estimation by calendar or predefined drift evidence, not because the latest P/L is uncomfortable.

The MT5 contract includes model version, feature schema, source cutoff, signal time, expiry and confidence interpretation. MT5 rejects stale or incompatible messages. A result can expire because data drift breaches a predeclared measure, the relation fails a scheduled recheck or operational parity fails—not because a preferred trade disappeared.

What to verify

  • Verify integration order and I(1) assumptions before interpreting the cointegration test.
  • Fit every transformation inside the training window and record overlapping-label embargoes.
  • Freeze a baseline, costs, expiry and re-estimation schedule before opening the test period.

Limits of this example

This workflow explains the research-to-execution boundary. It does not claim that cointegration or machine learning is suitable for every market pair.

Research quality record

Editorial ownership and primary references

Reviewed by POLARIS Research

Evidence scope

This article combines official platform behaviour with recurring, anonymized implementation patterns. Exact trading rules and client material are excluded.

Primary references

These references support platform behaviour or research concepts. They do not validate POLARIS performance and do not guarantee future results.

Related research and applications

Explore the next relevant layer

Move between focused research, system engineering and portfolio construction without losing the context of this page.

Expert Advisors and automated trading systems →Algorithmic trading portfolios →Risk controls inside every Expert Advisor →

Related research