1. What the system observed. A review of all-time closed trades on one venue showed 44 trades, a 29.5% win rate, and −$2,634 total P&L — an apparently broken strategy. Root cause: one trade (the ARM outage) accounted for the entire loss. Excluding that single infrastructure-caused outlier, the real picture was 43 trades, 30.2% win rate, +$187.47 total, with winners averaging $97.36 against losers averaging −$35.94 — a legitimate low-win-rate, high-payoff carry trade with a thin per-trade edge.
2. The hypothesis. Splitting those 43 trades by exit type — "weak" exits (funding decay, grace-timer, sign-flip: n=7, avg −$459.90, still skewed by the ARM trade) versus "clean" exits (emergency reversal, max hold: n=20, avg +$39.43) — found that 5 of the 7 weak-exit trades had entered with funding already declining over the prior 24 hours, while the cleanest, largest winners had all entered with funding flat and close to its own trailing average. This suggested a testable rule: reject entries where funding is already rolling over, even if it still clears every absolute-level filter.
3. What the model expected. An existing, never-tested "momentum filter" toggle in the backtesting tool should show a clear improvement once switched on.
4. What changed — the first result didn't survive scrutiny. The first backtest run showed the momentum filter helping, by a modest $16–23 per configuration tested. But that run had two real flaws: it blended two venues' data into a single timeline instead of keeping them separate, and it didn't model the weekend-hold behavior the live system actually uses (the hedge broker can't close positions on Saturday or Sunday, so the live daemon pauses certain exit timers over the weekend — the backtest didn't). Cross-checking the backtest engine against a known-good historical result exposed the gap directly: it reproduced $1,320 where the verified result was $1,839 — enough of a discrepancy to distrust the momentum finding until the engine itself was fixed.
5. The corrected run. With weekend-hold logic added to match the live system exactly, and the venue-blending bug fixed, momentum consistently hurt or was neutral — never positive — across every configuration retested:
| Configuration | Momentum filter | Total P&L | Win rate |
|---|---|---|---|
| 2h decay grace | Off | $1,531 | 51.8% |
| 2h decay grace | On | $1,504 | 51.8% |
| 3h decay grace, 20% entry | Off | $1,510 | 51.1% |
| 3h decay grace, 20% entry | On | $1,493 | 50.6% |
6. Final result. The momentum filter was rejected — not added to the live entry logic. The reversal from "helping" to "neutral-to-harmful" was entirely attributable to the two backtest-engine bugs, not to anything about momentum itself. The live configuration was left unchanged. A secondary, unrelated observation from the same work — a tighter entry/exit threshold profile showing better results on a short, outage-affected data window — was explicitly not adopted either, flagged only as "watch, don't deploy," since it contradicted a more rigorous longer-window study and could easily be short-term noise.
7. What was learned. A backtest result that looks like a real edge is only as trustworthy as the engine that produced it — validating that engine against a known-good number before trusting a new finding from it is what caught this one before it became a live rule change. See Why a day with no qualifying opportunities is still useful for the related idea that a strict, well-tested filter set is the point, not an obstacle.