Kimera RTO_SMC is my Expert Advisor on XAUUSD (gold), M1 timeframe, implementing return-to-origin logic: whoever chases the impulse late pays whoever originated and defends it. I use it as a case study because I own its entire history: the spec, the code, the backtests, the mistakes, the fixes.
1 · The spec before the code
The decisive transformation happens before any line of code: converting discretionary concepts into measurable thresholds. The Smart Money concepts everyone knows — displacement, order block, mitigation — become numbers comparable with data:
| Discretionary concept | Formalization |
|---|---|
| "Impulsive move" (displacement) | Excursion ≥ X points within a defined window of bars |
| "Order block" | Zone of the last counter candle before the impulse, extended by a buffer |
| "Mitigation" (RTO) | First return of price into the zone after the impulse |
| "Trading context" | Defined hour window, max spread, minimum cooldown |
| "Management" | SL beyond the zone + buffer; TP at RR × risk |
Is it an impoverishment? Yes — the formal version is dumber than an expert eye's reading. But it's verifiable, and a dumb verifiable rule is worth more than a brilliant rule that can't be tested. The backtest will then tell us what the dumbness costs — with embarrassing precision.
2 · The architecture: five modules, each testable on its own
- The signal detector reads the market and produces candidates. It knows nothing about money: only geometry and conditions.
- The filters are a chain of independent vetoes: enabled direction, hour window, day, spread, cooldown. Each filter answers yes/no and can be enabled, disabled and tested individually — this property becomes crucial in a moment.
- Money management turns the surviving signal into a size.
- The executor talks to the broker: order sending, retries on transient errors, fill verification. The only layer that touches OrderSend.
- The risk guardian — daily loss limit and max drawdown with latch — sits above everything and can shut the system down regardless of what the other modules think. The code is here.
3 · Parameter discipline
- Every parameter is a degree of freedom the backtest will use to lie to you. Before adding one: "can I derive it from the data instead of optimizing it?" — the stop can be k×ATR with fixed k instead of a grid-searched number.
- Every parameter needs a causal story, not just an optimal value. My hour window covers London and New York: real liquidity for an impulse mean-reversion strategy. A parameter you only know as "value X makes the backtest better" is a debt the market eventually collects.
- Parameters have fragility hierarchies. RR and risk % are structural; absolute-point thresholds are the most fragile of all — and that's exactly where the system broke when gold tripled.
4 · 590 trades under interrogation
The 2020–2026 backtest gave a summary anyone would sign: +116%, profit factor 1.18. An amateur smiles and goes live. A professional sees a razor-thin margin and a drawdown incompatible with any prop constraint — and stops looking at the summary, because a backtest's value is not in the synthesis: it's in the distribution. The 590-trade file, exported and dissected:
The direction cut: half the system didn't exist
Splitting long and short revealed that the long side — half the system, half the risk, half the costs — contributed 10% of the profit, containing the five worst trades of the entire six years, all concentrated in the five weeks of the max drawdown. The real edge was short. Six years of backtest to discover I was running two systems: a good one, and one that at best paid commissions for the privilege of occasionally exploding. Markets aren't symmetric: gold falls with different dynamics than it rises. Always split every backtest by direction: it's one minute of work.
The time cut: holes in the calendar
Two hours of the day were negative or flat. But finding a calendar hole doesn't automatically authorize plugging it — with 590 trades across 5 days × 10 hours, every calendar cell holds a few dozen observations: territory where noise manufactures patterns for free. The three-condition criterion: (1) is there a plausible causal story? (2) is it robust across subperiods? (3) does the system stay profitable even without the filter? If a system lives only thanks to calendar filters, you don't have an edge: you have embroidery on noise.
The recomposition: −47% drawdown without touching the entries
Short-only plus the two-hour blackout: profit unchanged at 98%, max drawdown cut by 47%. Same engine, same signals, same market: I only removed things. Hence the principle that reorganized how I develop:
The subtractive filter principle. The safest way to improve an existing system is not adding intelligence (new signals, new indicators): it's removing exposure in the contexts where the data shows the edge isn't there. A subtractive filter cannot invent profits that don't exist — at worst it removes good trades — and its model-risk profile is incomparably better than any addition. Those who add, optimize; those who remove, prune on evidence.
5 · What the backtest still doesn't say
An honest analysis always ends with the list of what it didn't solve:
- Cutting the longs is an empirical fix, not a causal one: it throws away the weak side instead of understanding it. The serious alternative — a regime filter re-enabling longs only in the right contexts — is in the development queue.
- The swap drag remains structural as long as positions cross the night.
- And above all: absolute-point thresholds on an underlying that tripled — the most instructive mistake of all, with ATR-relative thresholds as the first item on the roadmap.
The full development cycle I use to manage all this — with AI as a colleague, not an oracle — is documented here, with the real prompts.