[Development Log] The "phantom trade" of backtesting. The decisive gap between test environment and real account

In the development of system trading, a system that drew an asset curve with no flaws in the backtest report fails to function at all and causes drawdown as soon as it moves to forward testing or live trading. When faced with this phenomenon, many developers tend to look for internal causes in the logic, saying “insufficient optimization” or “market volatility has changed.”

However, from the perspective of a process design engineer, the fundamental cause of this fatal divergence does not lie in the logic parameters. It stems from a structural defect: the system is built as an architecture that only holds in a test environment, a virtual space, and is physically impossible to execute in reality.

In this paper, I logically dissect the mechanism of “illusory orders” produced by the specific specifications of backtest tools and the perspective needed to detect the “desk-top theory” that ignores the physical constraints of the execution environment.

1. The Illusory Order History Generated by Tick Interpolation

One of the main reasons for divergence between backtest and live account results is the price data generation mechanism in the test environment, namely “tick interpolation.”

Typical backtest tools, aiming to minimize processing, base their reference on only the four price information of historical data—open, high, low, and close. The fine price movements (ticks) between these four points are interpolated and generated by the tool’s internal algorithms as a “virtual price trajectory,” either randomly or according to a fixed rule.

This specification induces a extremely serious bug in system design. In systems with extremely narrow profit-taking and stop-loss ranges, within the test environment there are many cases where the take-profit line is reached first within the artificially generated price movements. In real markets, even if the situation would have reversed after hitting the stop-loss, the test tool records it as a “clear win.”

This is the “illusory order.” The win rate and profit factor inflated unnaturally by this virtual order history do not capture the real market structure (edge); they merely reflect a test tool’s “computational bug.”

2. Forgetting the Physical Latency in the Execution Environment

Another fatal deception in the test environment is the absence of “physical latency (latency) and order rejection.”

In the backtest space, the moment the logic fires, there is zero latency and zero slippage, and the order is processed at the desired price flawlessly. However, in real trading infrastructure, this is physically impossible. Order packets travel from a local PC or VPS to the broker’s server and are matched in the market through a liquidity provider (LP), which involves unavoidable communication and processing time.

Especially in scenarios with reduced liquidity and widened spreads, or during sudden price movements, this physical latency becomes a clear “loss” in the form of slippage. Architectures that presume zero latency and compete on millisecond-level advantage lose that edge the moment they are implemented in real infrastructure, due to the friction of spreads and slippage. This is not a matter of the elegance of programming code; it is a design failure against the physical constraints of infrastructure.

3. Principles of Process Design Based on Divergence

I am not a programmer. I do not value language syntax or score-making that only works in a virtual space. As a process design engineer, I pursue only the robustness of whether the system can physically survive in real harsh infrastructure and uncertain markets.

To design truly executable systems, we must build in the assumption that the illusionary orders generated by tick interpolation and slippage caused by communication delays will inevitably occur. To this end, we must first completely eliminate architectural concepts that assume “averaging down” or “martingale,” designs that presume enduring drawdown. Attempts to offset unexpected losses caused by real divergence with further risk (adding positions) are the silliest defect that postpones collapse into the future.

The principle to ensure absolute survivability is to limit to a single position and to mandate a clear system-wide exit line (SL). Moreover, in environments with unfavorable execution conditions, such as during spreads widening, strictly implement a filter that conservatively avoids entries. A process is required that absorbs the noise of real physical constraints and still harvests only the remaining, robust edge.

Conclusion: Eliminate Desk-Top Theory and Guarantee Physical Survivability

In a greenhouse-like backtest, a system optimized under illusory ticks and zero latency has no defense in actual markets and remains a “desk-top theory.”

The true purpose of system trading is not to create perfect reports in virtual space. It is to survive the harsh real environment where physical communication delays and slippage intertwine, to protect one’s capital and extract a reliable edge. We at Semura Lab. will not promote the operation of a black box built on desk-top theory. We always audit the integrity of the trading logic and relentlessly pursue process design that prioritizes survival in real environments.

We must discard vulnerable logic that relies on illusory orders, eliminate emotions, and fundamentally redesign the system on the premise of a single position and strict withdrawal management.