SENIOR MQL5 / QUANTITATIVE DEVELOPER REQUIRED — PROFESSIONAL AI-ASSISTED MT5 TRADING SYSTEM

Project Overview

I am seeking a highly experienced MQL5 developer, quantitative trading-system engineer or small specialist team to design and build a professional, fully auditable MetaTrader 5 trading system.

This is not a request for a basic indicator conversion, copied Expert Advisor, martingale robot, grid-recovery system or a bot claiming guaranteed profits.

The objective is to develop a disciplined, risk-controlled trading platform that can:

• analyse multiple instruments and market conditions;

• identify and rank high-quality trade opportunities;

• select only the strongest qualifying setups;

• calculate entries, Stop Loss and Take Profit levels;

• manage positions automatically;

• minimise avoidable losses and excessive drawdowns;

• preserve capital during unfavourable market conditions;

• provide clear reasons for every trading decision;

• support backtesting, optimisation, demo trading and controlled live deployment.

Profitability cannot be guaranteed. The system must instead be designed around measurable statistical evidence, strict risk management, realistic execution assumptions and long-term capital preservation.

Preferred Platform and Architecture

The initial platform should preferably be:

• MetaTrader 5;

• MQL5 source code;

• Python or another external analytical component only where technically justified;

• modular architecture that can be expanded later.

A hybrid MQL5/Python architecture may be proposed where machine learning, advanced statistical analysis or external data processing genuinely improves the system.

The applicant must clearly explain:

1. Why the proposed architecture is appropriate.

2. Which functions will run directly inside MT5.

3. Which functions, if any, will run outside MT5.

4. How communication failures between components will be handled.

5. Whether the system can continue operating safely if an AI or external service becomes unavailable.

Tradable Markets

The long-term vision may include:

• major and minor Forex pairs;

• gold and selected commodities;

• stock-market indices;

• stocks or share CFDs where supported by the broker;

• interest-rate or bond-related instruments where supported;

• other suitable liquid instruments.

However, I do not expect every market to be included in the first release.

The developer should recommend a sensible pilot market and instrument set for Phase One. The architecture should then permit additional instruments to be added without rewriting the entire system.

Phase One — Strategy Research and Requirements Specification

Because the final trading strategy has not yet been fixed, the first paid phase must be a formal discovery and system-design stage.

The developer will be expected to help define:

• suitable trading style;

• suitable instruments;

• appropriate timeframes;

• trade frequency;

• signal-generation framework;

• market-regime classification;

• risk limits;

• exit methodology;

• testing methodology;

• live-deployment safeguards;

• realistic performance expectations.

Possible analytical components may include, where justified:

• trend analysis;

• momentum;

• volatility;

• support and resistance;

• market structure;

• multi-timeframe confirmation;

• volume or tick-volume analysis;

• liquidity conditions;

• spread and slippage;

• session behaviour;

• correlations;

• economic-news risk;

• statistical or machine-learning models.

The result of Phase One must be a written and testable Requirements Specification.

No full development should begin until both parties agree on the exact rules and acceptance criteria.

Trade Opportunity Ranking Engine

The system should be able to scan the permitted instruments and assign a transparent quality score to every valid setup.

The score may consider:

• strength of the trading signal;

• higher-timeframe agreement;

• volatility conditions;

• market regime;

• expected reward-to-risk ratio;

• spread and execution cost;

• liquidity;

• correlation with current open positions;

• proximity to high-impact economic events;

• recent performance of the strategy under comparable conditions.

The system should reject weak or conflicting setups and prioritise only the highest-quality opportunities.

Every accepted or rejected trade should record the reasons behind the decision.

I do not want an unexplained black-box output that merely says “BUY” or “SELL.”

Operating Modes

The finished system should preferably support three operating modes:

1. Analysis Mode

The system scans the market, ranks opportunities and generates reports but does not place orders.

2. Approval Mode

The system prepares the complete trade proposal, including entry, Stop Loss, Take Profit, position size and reasoning, but waits for manual approval.

3. Fully Automated Mode

The system executes and manages qualifying trades automatically within strict risk limits.

The user must be able to switch between these modes.

Mandatory Risk-Management Engine

Risk management is the most important part of this project.

The system must include configurable controls for:

• percentage of equity risked per trade;

• maximum monetary risk per trade;

• mandatory Stop Loss protection;

• maximum daily loss;

• maximum weekly loss;

• maximum total drawdown;

• maximum number of concurrent positions;

• maximum exposure per symbol;

• maximum exposure to correlated instruments;

• maximum permitted spread;

• maximum permitted slippage;

• minimum reward-to-risk ratio;

• maximum number of losing trades within a defined period;

• trading-session restrictions;

• high-impact news restrictions;

• weekend and holiday handling;

• equity-protection shutdown;

• emergency global close;

• manual kill switch;

• automatic suspension following abnormal behaviour.

The system must fail safely.

If market data becomes stale, communication fails, spread becomes abnormal, an order is rejected or account conditions become inconsistent, the system should stop opening new positions and alert the operator.

Prohibited or Restricted Techniques

The initial production system must not use the following unless they are separately disclosed, scientifically justified and expressly approved:

• martingale;

• unlimited grid trading;

• uncontrolled averaging down;

• lot-size multiplication after losses;

• hidden recovery baskets;

• unlimited hedging;

• strategies that depend on unrealistic zero-slippage execution;

• strategies that hide Stop Losses while risking large portions of the account;

• backtests based on unsuitable or manipulated data;

• curve-fitted parameter sets designed only to make historical results look attractive.

Applicants offering guaranteed profits, guaranteed win rates or “zero-risk” trading should not apply.

Entry and Exit Management

The final entry logic will be agreed during Phase One.

The system should support, where appropriate:

• market and pending orders;

• fixed or volatility-adjusted Stop Loss;

• fixed or adaptive Take Profit;

• partial profit-taking;

• break-even protection;

• trailing Stop Loss;

• time-based exits;

• signal-invalidation exits;

• maximum trade-duration controls;

• Friday or weekend position management;

• emergency closure.

Stop Loss and Take Profit placement must be verified after execution. The system must not merely assume that the broker accepted the protective levels.

AI and Machine-Learning Requirements

I am open to genuine AI or machine-learning components, but I do not want “AI” added merely as a marketing phrase.

Any applicant proposing AI must explain:

• the exact purpose of the AI component;

• what input data it uses;

• how training data will be obtained;

• how data leakage will be prevented;

• how overfitting will be controlled;

• how often the model needs retraining;

• whether inference occurs locally or through an external service;

• what recurring service costs may exist;

• how model decisions will be recorded;

• what happens when the model is unavailable;

• how the AI component will be compared against a simpler non-AI baseline.

A conventional statistical system should be used where it performs more reliably than an unnecessarily complicated AI model.

AI may assist analysis, but deterministic risk rules must retain final authority over account exposure.

Backtesting and Validation

The developer must provide a professional testing framework, including:

• historical backtesting;

• realistic spreads;

• commissions;

• swaps where relevant;

• slippage assumptions;

• different market regimes;

• bull, bear, trending and ranging periods;

• out-of-sample testing;

• walk-forward analysis;

• parameter-sensitivity testing;

• Monte Carlo or comparable robustness analysis where appropriate;

• testing across more than one broker-data environment where practical.

The system should not be judged only by total net profit.

Reports should include:

• maximum drawdown;

• average drawdown;

• profit factor;

• expected payoff;

• recovery factor;

• win rate;

• average winning trade;

• average losing trade;

• reward-to-risk distribution;

• number of trades;

• consecutive losses;

• monthly consistency;

• exposure;

• performance by symbol;

• performance by market regime;

• performance after realistic trading costs.

The developer must identify which results are backtested, which are demo-forward-tested and which, if any, are live results.

Demo and Controlled Live Testing

Before serious live deployment, the system must pass:

1. Historical validation.

2. Out-of-sample validation.

3. Demo or paper-forward testing.

4. Tiny-capital live testing.

5. Controlled scaling only after stable behaviour has been demonstrated.

The applicant should propose a realistic demo-testing period and measurable pass/fail conditions.

Dashboard and Reporting

The system should include a clear control panel showing:

• system status;

• current operating mode;

• market regime;

• qualified trade opportunities;

• active trades;

• current risk exposure;

• daily profit or loss;

• weekly profit or loss;

• current drawdown;

• maximum permitted drawdown;

• spread and execution conditions;

• recent rejected signals;

• reason for the latest trading decision;

• whether any safety lock is active.

Reports and logs should make it possible to reconstruct every decision and order.

Audit and Logging

The system must record:

• input data used;

• signal values;

• ranking score;

• entry reason;

• rejection reason;

• risk calculation;

• requested order;

• broker response;

• actual fill price;

• Stop Loss and Take Profit confirmation;

• modifications;

• exit reason;

• final result;

• errors and warnings.

Duplicate orders must be prevented.

The system should recover safely following terminal restart, VPS restart or temporary connection loss.

Configurable Inputs

Important parameters should be configurable without editing source code, including:

• symbols;

• timeframes;

• risk percentage;

• maximum daily loss;

• maximum drawdown;

• trading sessions;

• news restrictions;

• spread limit;

• slippage limit;

• permitted number of trades;

• Stop Loss method;

• Take Profit method;

• trailing settings;

• break-even settings;

• minimum trade-quality score;

• operating mode.

Input settings should be clearly named and documented.

Deliverables

Required deliverables should include:

• complete MQL5 source code;

• compiled MT5 files;

• external source code if a hybrid system is used;

• installation instructions;

• configuration guide;

• technical architecture document;

• final Requirements Specification;

• testing and validation reports;

• recommended initial settings;

• explanation of every major module;

• sample logs;

• troubleshooting guide;

• version and change history;

• source-code comments;

• agreed period of post-delivery bug correction.

No locked-only or compiled-only delivery will be accepted unless specifically agreed beforehand.

The customer should retain ownership of the custom source code and project deliverables, subject to the final agreed MQL5 Requirements Specification.

Proposed Development Stages

Applicants should quote each stage separately.

Stage 1 — Discovery and Formal Specification

• Strategy research.

• Market and platform recommendation.

• Risk framework.

• Architecture.

• Test plan.

• Final Requirements Specification.

Stage 2 — Prototype

• Signal scanner.

• Trade-ranking model.

• Risk-engine prototype.

• Analysis-only mode.

• Preliminary dashboard.

• Initial backtest.

Stage 3 — Full Development

• Automated execution.

• Complete position management.

• Risk controls.

• Audit logging.

• Recovery handling.

• Dashboard.

• Configuration interface.

Stage 4 — Validation and Optimisation

• Historical tests.

• Out-of-sample tests.

• Walk-forward testing.

• Robustness testing.

• Realistic cost modelling.

• Bug correction.

Stage 5 — Demo Forward Test

• Installation on demo account or VPS.

• Behaviour monitoring.

• Execution verification.

• Risk-control verification.

• Corrections based on observed faults.

Stage 6 — Final Delivery and Support

• Source-code delivery.

• Documentation.

• Installation assistance.

• Agreed bug-support period.

• Final acceptance testing.

Minimum Acceptance Conditions

The finished system must:

• compile without errors;

• preferably compile without warnings;

• follow the approved Requirements Specification;

• never intentionally open a trade without the required risk protection;

• prevent duplicate orders;

• respect daily, weekly and overall risk limits;

• stop safely when critical conditions fail;

• generate readable decision and execution logs;

• reproduce agreed test cases;

• operate correctly after terminal restart;

• provide all agreed source files and documentation.

Profit cannot be an absolute acceptance guarantee because future market performance is uncertain. Acceptance will instead be based on correct implementation, robustness, risk-control compliance and the agreed validation tests.

Applicant Requirements

Please apply only if you have strong experience in several of the following areas:

• professional MQL5 Expert Advisor development;

• quantitative trading systems;

• strategy testing and optimisation;

• risk-management systems;

• multi-symbol systems;

• order-execution handling;

• financial statistics;

• Python integration;

• machine learning for time-series or financial markets;

• dashboard development;

• live-trading fault handling.

Your application should include:

1. Number of completed MQL5 projects.

2. Relevant examples of similar systems.

3. Your specific role in those projects.

4. Your proposed architecture.

5. Whether you recommend pure MQL5 or a hybrid solution.

6. How you would prevent overfitting.

7. How you would test live-execution risk.

8. How you would implement the emergency shutdown system.

9. Estimated cost for each project stage.

10. Estimated timeline for each stage.

11. Included post-delivery support.

12. Confirmation that full source code will be delivered.

13. Confirmation that you do not guarantee profits.

14. Confirmation that you will not use martingale, hidden grid recovery or other undisclosed high-risk methods.

15. Any recurring data, VPS, API or software costs.

Please do not submit a generic copy-and-paste application.

The strongest candidates will be invited to discuss the project in detail through the official MQL5 Freelance process.

Budget and Timeline

The budget is open to serious proposals from qualified developers.

I prefer a phased fixed-price quotation rather than one undivided payment for the entire project.

Applicants should provide:

• cost per stage;

• delivery time per stage;

• dependencies;

• assumptions;

• optional features;

• recurring costs;

• features that can be deferred to a later version.

Quality, risk discipline, transparency and maintainable source code are more important than selecting the cheapest proposal.