You have a trained Python ML model. It works in a Jupyter notebook. The challenge is getting it to produce live signals inside MetaTrader without breaking on the first NFP release.
This service handles the full integration pipeline — from a trained Python model to a production-ready MQL5 Expert Advisor that runs inference natively inside MT5, without requiring a Python runtime during live trading.
What You Get
- ONNX model export and validation: Your trained model converted to `.onnx` format and verified against MQL5’s input/output shape requirements
- Feature normalization embedding: Scaler statistics (mean, standard deviation) from training extracted and hard-coded into MQL5 — the #1 failure point in Python-to-MT pipelines
- MQL5 inference code: `OnnxCreate()`, `OnnxSetInputShape()`, and `OnnxRun()` implementation with correct data type handling and error recovery
- Feature engineering in MQL5: Price-derived features recalculated natively in MQL5 to match exactly what the model saw during Python training
- Strategy Tester validation: Full backtest run to confirm the model’s predictions in MQL5 match your Python notebook outputs on the same historical data
- Source code ownership: You receive the full `.mq5` source file. No DRM, no subscriptions, no lock-in.
How It Works
- Model audit: I review your Python notebook — training data, feature pipeline, normalization, model type. I identify any lookahead bias, data leakage, or normalization issues before touching MQL5.
- ONNX export: Your model is exported using `skl2onnx`, `torch.onnx.export`, or the appropriate converter for your framework. Input/output shapes are verified against MQL5’s requirements.
- Normalization extraction: Training-time scaler statistics are extracted and embedded in the MQL5 code. Features are normalized identically to how the model was trained — using training-fold statistics only, not live data statistics.
- MQL5 inference integration: `OnnxCreateFromBuffer()` embeds the model directly in the EA binary (no external file dependency). `OnnxRun()` is called on each signal bar with properly shaped input arrays.
- Prediction cross-check: I run the MQL5 EA and your Python notebook on the same historical period and compare prediction outputs bar by bar. They must match within floating-point tolerance before delivery.
- Delivery: Source code, compiled `.ex5`, Strategy Tester report, and documentation of the feature pipeline and normalization logic.
Who This Is For
Good fit:
- Traders who have a working ML model in Python (scikit-learn, PyTorch, XGBoost) and need it running inside MetaTrader 5
- Developers who tried the integration themselves and hit shape mismatches, type errors, or prediction divergence between Python and MQL5
- EA owners who want to add an ML signal layer to an existing rules-based EA
- Teams who want the model inference to run entirely inside MT5 — no external Python process, no ZMQ bridge, no infrastructure dependency in live trading
Not the best fit:
- Traders who want me to build the ML model from scratch, train it, and integrate it — that’s the [ML Expert Advisor Development Service](/machine-learning-ea-development/), which covers the full pipeline from feature engineering through live deployment
- MetaTrader 4 users — MT4 does not support ONNX natively; MT4 integration requires a bridge architecture (socket or file I/O), which adds latency and is best evaluated case by case
What Makes This Different
The most common failure mode I see in Python-to-MT integration projects is normalization contamination. A developer trains a model, exports it to ONNX, builds the MQL5 inference code — and live predictions diverge from notebook predictions by 20–40%. The root cause is almost always the scaler: in Python, the model was trained with `StandardScaler.fit_transform()` on the full historical dataset. In MQL5, features are normalized using live price data. The two normalization spaces are different, so the model receives inputs it has never seen during training.
The fix requires extracting the exact training-fold mean and standard deviation for each feature and embedding them as constants in MQL5. This is not a subtle optimization — it is the difference between a model that works and one that produces noise.
MQL5’s native ONNX support (via `OnnxCreate()` and `OnnxCreateFromBuffer()`) means the model runs entirely inside the MetaTrader process. No external Python runtime, no ZMQ socket, no subprocess. The EA can run on a VPS with zero Python dependencies. This is the architecture I implement by default — it is more reliable in production than bridge approaches because it eliminates the external process as a failure point.
I have built this integration for gradient boosting classifiers, LSTM sequence models, and random forest regressors. The data type handling in MQL5 requires explicit casting (MQL5 uses `float` arrays for ONNX I/O, while your Python model may expect `double`), and MQL5 provides automatic conversion — but only when the shape declaration is correct. Shape errors are silent in the Strategy Tester and only surface live.
Pricing
Integration complexity depends on model architecture and feature pipeline depth.
| Scope | Includes | Starting at |
|---|---|---|
| Standard | Scikit-learn or XGBoost model, ≤10 features, single output (signal or probability), prediction cross-check | $400 |
| Advanced | Deep learning model (LSTM, CNN), ≥10 features, sequence input, walk-forward validation of integration | $800 |
| Full pipeline audit | Model audit + normalization fix + integration + backtest discrepancy analysis | $1,200+ |
All tiers include source code, compiled `.ex5`, prediction cross-check report, and 30-day support.
Frequently Asked Questions
Can you integrate a Python ML model with MetaTrader 4?
MetaTrader 4 does not support ONNX natively — the `OnnxCreate()` API is MQL5 only. For MT4, integration requires a bridge: either a ZMQ socket connecting a Python process to the EA, or a file-based I/O approach where Python writes signals to a CSV and the EA reads them. Both introduce latency (typically 20–200ms per signal) and an external dependency. For strategies where execution timing is not critical, the file bridge is simpler and more reliable. For anything requiring sub-second execution, the recommended path is migrating the EA to MT5 to use native ONNX inference.
What Python ML frameworks are supported for the ONNX export?
The most common are: scikit-learn (via `skl2onnx`), PyTorch (via `torch.onnx.export`), XGBoost (via `onnxmltools`), LightGBM (via `onnxmltools`), and Keras/TensorFlow (via `tf2onnx`). The ONNX ecosystem covers most major frameworks — the limiting factor is usually operator support (some custom layers or activation functions have no ONNX equivalent). I review your model architecture before committing to a price, and flag any export limitations upfront.
How do I know the MQL5 model predictions match my Python notebook?
The cross-check is part of every integration. I run your Python notebook and the compiled MQL5 EA on identical input data (the same historical OHLCV bars) and compare predictions bar by bar. Acceptable tolerance is ±0.001% — effectively floating-point rounding. Any divergence beyond that indicates a normalization mismatch or feature calculation error, which I trace and fix before delivery. You receive the cross-check report showing the comparison.
What happens if the model needs to be retrained and the integration updated?
Model updates are handled as a separate project, typically at a reduced rate since the infrastructure is already built. The most common scenario is retraining with newer data and re-exporting the `.onnx` file — if the architecture and feature list are unchanged, this is a minor update (1–2 hours). If the feature pipeline changes, the MQL5 feature calculation code needs updating as well. I document the integration in enough detail that you can replace the `.onnx` file yourself if the architecture is identical.
Why use ONNX instead of keeping Python running alongside MT5?
The ONNX-native approach runs inference entirely inside the MetaTrader process. No Python runtime required, no process management, no socket reconnection logic, no risk of the Python process dying and the EA trading without signals. On a VPS with limited resources, eliminating the Python dependency reduces complexity and failure surface. The bridge approach makes sense when the model is too large or complex for ONNX export — for example, custom PyTorch layers with no ONNX operator equivalent. For standard classification and regression models (scikit-learn, XGBoost, standard LSTM architectures), ONNX native is the more reliable production architecture.
Related Services
- ML Expert Advisor Development Service — full ML EA from feature engineering through live deployment
- ML Feature Engineering for Forex Trading — feature construction and lookahead bias elimination
- Expert Advisor Programming — custom EA development without ML components
- EA Debugging & Code Review — diagnosis and repair of failing live EAs