Trading Bot with MT5
The client was a small prop trading desk running roughly four discretionary strategies in parallel across forex and CFDs. The team had been operating through the standard MT5 client with manual execution, which capped strategy count at what the human operators could monitor simultaneously and produced inconsistent execution quality on volatile sessions. The principal trader had a list of seven additional strategies that backtested well but could not be operationalized without execution infrastructure.
Trading, FinTech & Analytics
Trading/Finance
11 weeks from kickoff to ten strategies live
4 specialists
The full story
The practical problem was twofold. Execution quality varied with operator attention, especially across overlapping sessions in London and New York, which meant entry slippage on the backtest-to-live transition often erased the edge that justified running a strategy. And the desk had no consolidated view of risk across strategies — each was monitored in its own window, so position sizing and correlation across strategies was eyeballed rather than measured.
We built a multi-strategy execution engine on top of the MT5 API that ran each strategy as an independent module with its own parameters, position sizing, and risk limits, all consolidated under a cross-strategy risk manager that enforced desk-wide exposure limits in real time. Strategy parameters were exposed as live controls that the principal could tune without code changes, and an analytics dashboard rendered fills, slippage, and per-strategy P&L on a one-second refresh.
What shipped was a desk-class trading workstation where the operator selects which strategies are live, monitors all ten on a single screen with consolidated risk metrics, and intervenes on individual strategies with parameter changes or pauses without affecting the others. Backtest-to-live slippage dropped substantially, the desk operationalized six of the seven shelved strategies within the first quarter, and the principal stopped manually executing entirely except during off-system anomalies.
Manual execution capped strategy count and produced session-dependent slippage that erased backtest edge.
Operator attention across overlapping London and New York sessions caused entry slippage that consumed the backtest edge on volatile days.
Seven backtested strategies sat on the shelf because the desk could not operationalize them under the manual execution model.
Cross-strategy risk was eyeballed across separate MT5 windows, so position sizing and correlation went unmeasured during volatile periods.
Strategy parameter changes required code changes from the principal, who was already running execution, creating a single point of failure.
Slippage attribution per fill did not exist, so the desk could not diagnose which strategies were execution-bound versus signal-bound.
How we structured the engagement
Decoupled signal from execution, then built a desk-wide risk layer over the top so ten strategies could run together safely.
- 01Phase 01Weeks 1-2
Discovery
Sat with the principal for three trading sessions, instrumented the existing manual workflow for slippage per fill, and reviewed the seven shelved strategies for execution requirements. Output: a strategy module contract, a cross-strategy risk model, and a real-time analytics requirement at one-second refresh.
- 02Phase 02Weeks 3-4
Architecture
Designed a Python-based execution engine on top of MT5 with each strategy as an independent module sharing a common signal-to-order contract. Built a cross-strategy risk manager that enforced desk-wide exposure limits in real time. Used WebSockets to push fills and metrics into the React dashboard.
- 03Phase 03Weeks 5-9
Build
Shipped the execution engine and the strategy module contract first, ported two existing strategies to validate the contract, then built the risk manager and analytics dashboard in parallel. Implemented parameter hot-reload so the principal could tune strategy parameters mid-session without redeploying.
- 04Phase 04Weeks 10-11
Launch
Ran the engine in paper-trading mode for two weeks alongside the manual desk, compared fills and slippage attribution, then promoted to live with the two original strategies. Onboarded one additional strategy per week thereafter as the principal validated each against live performance. Reached ten strategies by week thirteen.
What we built, component by component
- 01
MT5 connector
Wraps the MT5 API with retries, latency monitoring, and reconnect logic, normalizing the broker interface for upstream modules.
- 02
Strategy modules
Independent Python modules per strategy with parameters, position sizing, and signal logic, conforming to a shared contract.
- 03
Cross-strategy risk manager
Real-time enforcement of desk-wide exposure, correlation, and drawdown limits across all running strategies.
- 04
Parameter service
Live parameter store with hot-reload, allowing mid-session tuning without redeploying any strategy module.
- 05
Slippage attribution
Per-fill slippage analysis with attribution to signal latency, broker latency, and market impact components.
- 06
Real-time dashboard
React workstation with one-second refresh on fills, slippage, and per-strategy P&L, plus consolidated desk risk view.
Each strategy module produces signals against the MT5 connector, the risk manager gates every order against desk-wide limits in real time, and the connector executes against the broker with latency monitoring. Fills flow back through slippage attribution into the dashboard at one-second refresh, and parameter changes from the dashboard propagate to strategy modules via the hot-reload parameter service.
The trade-offs we made and why
Decoupled signal generation from execution
Strategy logic and execution logic had different change rates and different failure modes. Decoupling them let the principal iterate signals without risking execution stability, and let us harden execution once for all strategies instead of per-strategy.
Built a cross-strategy risk manager from day one
A per-strategy risk model would have produced safe individual strategies and a dangerous desk. The cross-strategy view caught correlation spikes that would have blown through any single-strategy limit, and made it safe to onboard new strategies without rebuilding risk for each.
Implemented parameter hot-reload from the dashboard
Mid-session parameter changes were a real workflow need. Forcing a redeploy for every tweak would have killed the principal’s ability to react to regime shifts. Hot-reload kept the workflow fluid without compromising the deployment story for code changes.
Ran paper trading in parallel for two weeks before live
Trading systems fail in ways that backtesting never catches. Paper trading alongside the live manual desk surfaced two race conditions in order acknowledgment that we would not have caught in development, both of which would have caused real losses on day one of live trading.
What changed for the client
execution efficiency
Reduction in average slippage per fill across the strategy portfolio versus the prior manual-execution baseline.
strategies live
Concurrent live strategies running on the engine at peak, with the seven shelved strategies operationalized within a quarter.
dashboard refresh
End-to-end refresh from fill to displayed metric on the workstation, enabling real-time intervention without polling delay.
manual executions
Manual executions on the desk after week eight, except during off-system anomalies that required principal override.
The tools behind the system
Built with a deliberate stack chosen for production reliability and operational velocity.
Lessons learned from the build
The cross-strategy risk layer was the unlock for everything else. Without it, each new strategy onboarded would have required a new round of manual risk validation. With it, onboarding a strategy became a one-week task instead of a one-month task, which is what let the desk operationalize the shelved strategies in a quarter.
Paper trading in parallel was non-negotiable in hindsight. The two race conditions paper trading caught would have produced losses that exceeded the entire project cost on day one. Any future trading-system delivery would include a parallel-paper period of at least two weeks as a hard gate.
Slippage attribution turned out to be the most-watched metric on the dashboard. The principal used it to triage which strategies needed signal work versus execution work, which was a different question than they were asking before the system existed. We would design the attribution surface earlier next time.
Similar delivery work usually starts in these service areas
If you are exploring a similar product, workflow, or implementation challenge, these are the service tracks that usually fit best.
Where this project sits in the bigger market picture
How we approach AI delivery for payments, banking, underwriting, and financial workflows.
Build a result-driven AI product with a team that has shipped before
If you are exploring a similar product, workflow, or AI use case, we can help scope the right architecture, delivery model, and first milestone.
Related case studies worth reviewing next
Have an AI idea, messy workflow, or product vision? Let's make it buildable.
Bring the problem. We'll help shape the product, define the architecture, and show the fastest path to a serious first version.
A practical first roadmap in the discovery call
Architecture, timeline, and delivery options in plain English
Security, scalability, and reliability discussed upfront
Model registry
softus-rag-v4.2
187ms
Latency
128k
Context
$0.004
Cost / req
Evaluation suite
Deploy pipeline
prod / canary 25% — healthy