Model to Market

QuantHack’s Model to Market competition required entrants to build and operate a systematic trading process on a shared simulated MT5 account. I built the system solo: market-data ingestion, strategy research, portfolio sizing, risk controls, order handling, reconciliation and monitoring.

The difficult part was not producing another backtest. It was keeping the meaning of a strategy intact as it moved from historical data into a broker-observed position, while preserving enough evidence to explain what changed during the live window.

View chart summary

Live-only equity summary records

Record	Equity
First live observation	1,000,000
Lowest live observation	996,627.61
Peak live observation	1,070,700.36
Last live observation	1,059,853.82
Recorded settlement (separate)	1,059,439

Competition result

Competition result

19 / 440

Final rank

Project-recorded QuantHack result, 2026

+5.94%

Recorded simulated return

Starting equity $1,000,000

$1,000

Prize

Top-25 bracket

These figures come from the project repository and recorded run outputs. I do not have a separate organiser certificate confirming them, so I treat them as project records rather than externally audited results.

Scope and constraints

The competition environment fixed the operating conditions:

• one shared simulated MT5 account starting at $1,000,000;
• a fixed 15-instrument universe across FX, metals and crypto;
• 15-minute research and live inputs;
• a fixed competition window with no account reset;
• one operator responsible for research, deployment and monitoring.

The result is not evidence of a deployable investment product or performance with live funded capital. It is evidence that the system could move from research output to a monitored simulated account under a deadline.

What I built

The system had five connected responsibilities.

Data and alignment. A common processed market panel supplied both research and live operation. Symbol naming, timestamp alignment and missing observations had to be visible rather than silently hidden by a notebook-only cleaning step.

Strategy contracts. Registered strategy implementations returned target weights. They did not submit orders. Momentum and Kalman gold/silver mean reversion formed the documented launch blend; OU mean reversion was promoted later.

Portfolio and risk. The portfolio layer combined strategy outputs before execution and applied volatility, leverage, concentration, drawdown, margin and symbol controls. A simple external STOP file provided an operator kill switch outside the strategy loop.

Execution and reconciliation. The order-management system compared permitted targets with positions reported by MT5, converted the remaining difference into an order intent, ran broker preflight and checked the resulting broker state. MT5 remained authoritative after submission.

Telemetry and operating evidence. Heartbeats exposed mode, cycle, equity, configuration identity, targets, positions and errors. That made it possible to distinguish live observations from paper-live and dry-run records and to connect behaviour to a specific loaded configuration.

System architecture

The research and live paths shared data definitions and configuration, but they did not share authority. Research could propose a configuration. Risk and execution controlled what could reach MT5. Telemetry returned to the operator rather than feeding a self-modifying strategy.

Research / development

Market-data ingestionFX · metals · crypto

Clean aligned panel15-minute bars

Feature & signal researchMomentum · Kalman · mean-reversion

Vectorised backtest

Validation & comparison

Configuration selection

Promotion boundary✓▶

Live / competition

Shared strategy configurationSame YAML as research

Live market feed

Target generation

Portfolio sizingVolatility-aware · caps

Risk gatesDrawdown · margin · concentration

MT5 order manager

Broker preflight & submission

Reconciliation

Telemetry & stateEquity · positions · orders · config

Recorded result19 / 440 · +5.94% · simulated $1,000,000

Telemetry feeds operator review — the live strategy is not self-modifying↺

Cross-cutting

YAML configuration

Config hash / parity

Testing

STOP file kill switch

Drawdown & margin limits

Structured logs

Operator review

▶Trading path▷Market & telemetry data✓Promotion to live↺Operator feedback

The competition system has two tracks. In research and development, market data is ingested into a clean aligned 15-minute panel, features and signals are researched, backtested, validated and compared, and a configuration is selected. That configuration is promoted across a boundary into the live competition loop, which uses the same YAML configuration to generate targets from the live feed, size the portfolio, pass risk gates for drawdown, margin and concentration, and submit orders to MetaTrader 5 with preflight checks and reconciliation. Telemetry records equity, positions, orders and configuration. The recorded result was 19th of 440 with a +5.94% return on a simulated one-million-dollar account. Telemetry feeds a human operator review that adjusts configuration between runs; the live strategy does not modify itself. YAML configuration, config-hash parity, testing, a STOP-file kill switch, drawdown and margin limits, structured logging and operator review are cross-cutting.

The key state transitions were:

Collapsing those states would have made the system easier to describe and harder to trust.

Research decisions

The repository eventually contained more strategy code than the account used. I treated implementation, configuration and runtime activation as separate claims.

The documented launch configuration used:

• momentum at weight 0.60;
• Kalman gold/silver mean reversion at weight 0.40;
• target volatility 0.03;
• maximum instrument weight 0.10;
• maximum leverage 2.0.

On 23 June, a committed configuration enabled OU mean reversion at 0.20 and reweighted momentum and Kalman to 0.55 and 0.25. Git establishes the configuration decision; the public-safe archive does not contain the exact first live heartbeat that loaded it.

The longer validation panel produced a clearer rejection. The locked baseline recorded a positive return while the archived network-family configurations recorded the same negative return and failed the gate. Those implementations remained out of the live blend. BTC scalping, forecasting and graph-oriented candidates also remained research-only or gated rather than being rewritten as live strategies after the event.

Alternative-crypto controls were an operational decision rather than a universal research verdict. Repository history shows symbols being quarantined or disabled during the live window, but the public record does not support a detailed incident narrative with exact positions and broker responses.

Live run and telemetry

The sanitised telemetry source contains 1,045 observations:

• 893 live;
• 143 paper-live;
• 9 dry-run.

The public equity chart filters to mode == "live" before ordering timestamps and calculating drawdown. It does not join the settlement value onto the telemetry line.

Recorded live telemetry

$1,000,000

First live observation

20 Jun 2026

$996,628

Lowest live observation

22 Jun 2026

$1,070,700

Peak live observation

25 Jun 2026

$1,059,439

Recorded settlement

Separate from the final telemetry row

The public chart contains sampled live observations, not every intrabar movement. The final CSV observation, a separate README snapshot and recorded settlement are retained as distinct records.

Risk also changed during the competition. The archived final-day configuration records materially higher target volatility, instrument weight and leverage limits than the launch baseline. That does not prove the later schedule was optimal. It shows why the competition cannot be described as one fixed strategy and one fixed risk profile.

What the evidence supports

The project supports several concrete conclusions:

• a shared configuration can connect research and execution without giving strategy code broker authority;
• panel identity and configuration identity must travel with every result;
• code existing in a repository is not evidence that it traded;
• broker submission is not evidence of a reconciled position;
• paper-live and dry-run telemetry must not be joined into a live equity curve;
• Git history can date a configuration change without proving its exact first runtime activation;
• operational controls can be the right response even when the underlying research hypothesis remains unresolved.

The project does not establish that the strategy would have performed similarly with funded capital, different costs, a longer horizon or another broker.

What I would redesign

That bundle would remove much of the reconstruction now spread across Git history, telemetry, configuration files and later summaries.

I would also add:

• explicit configuration_loaded events;
• deterministic public-safe incident exports;
• risk changes on the same timeline as equity;
• predeclared post-event counterfactual replays;
• validators that fail when a named data panel is missing rather than substituting another dataset;
• one candidate record tying together dataset, parameters, costs, result, decision and effective runtime state.

Those requirements became part of the reasoning behind QuantSilico. The competition engine is not the final product architecture; it is the public predecessor that exposed why dataset identity, validation lineage, promotion and runtime evidence need to be first-class system concerns.

Related writing and artefacts

The three-part series separates system design, research promotion and the live run:

1. Part 1 — Building a Trading System That Could Actually Run
2. Part 2 — What Made It Live and What I Rejected
3. Part 3 — Live Risk, Telemetry and What I Would Change

View the repository