8. Framework Monoculture and Methodological Homogeneity

Every off-the-shelf backtesting framework takes sides. Each one embodies a set of assumptions about how strategies should be structured, what data they consume, how signals are generated, and how execution is modelled. Users absorb these assumptions through documentation and example code, and the result is a characteristic sameness in the way problems are framed and solutions developed.

Most popular frameworks, for example, encourage a pattern in which a strategy is expressed as a series of indicator calculations followed by threshold-based entry and exit rules, evaluated bar-by-bar on a fixed-frequency time series. This pattern is natural for a certain class of strategies but is poorly suited to others: event-driven strategies, strategies that operate across multiple timeframes simultaneously, strategies that incorporate non-price data, or strategies whose execution logic is itself a source of edge. Real multi-timeframe research computes features on one-minute, five-minute, hourly and daily bars and aligns them without look-ahead, whereas on a daily-only platform the bar size is a setting on a daily file. When the framework’s implicit recipe does not accommodate these approaches, developers tend to bend their ideas to fit the framework instead of the other way round, and the part of the strategy space that gets explored narrows.

The more experienced users of a given framework develop conventions and “best practices” that are passed on to newcomers through tutorials and forum discussions. These conventions often reflect the limitations of the framework as much as any principled methodological choice. The community that forms around a framework ends up approaching strategy development in remarkably similar ways, with the same indicators, entry patterns, default parameters, and evaluation metrics, so the strategies that emerge from it are correlated with one another. That is a problem for individual traders, whose strategies may be crowded, and for the field as a whole, whose collective output explores a narrower part of the strategy space than its volume would suggest. And since crowded strategies tend to unwind at the same time, the correlation creates systemic risk that no individual backtest can detect.

TradeStation, for decades one of the most widely used retail algorithmic trading environments, is a concrete illustration. Its EasyLanguage scripting system and built-in strategy development workflow were designed for a specific class of strategies: indicator-driven, single-instrument, bar-by-bar systems evaluated on fixed-frequency data. The platform makes this class of strategy extraordinarily accessible, to the point where a user with modest programming experience can have a moving-average crossover system running within hours of first contact with the software. But the platform’s strengths are also its constraints, because the ease of building indicator-based systems implicitly discourages approaches that do not fit its model, such as multi-instrument portfolio strategies, complex position-sizing logic, non-price data, or an execution model that departs from the platform’s built-in assumptions. The tool directs the work, and when thousands of users adopt the same tool, their collective output converges on the same narrow set of approaches, evaluated under the same assumptions. The resulting strategies are correlated because the platform’s architecture channels every user towards the same destination, whatever the underlying market relationships might demand. The criticism applies, in varying degrees, to every framework that makes some approaches easy and others difficult, but TradeStation’s longevity and large user base make it a particularly visible example of how platform constraints become community conventions.

The ecosystem around RealTest is a second, sharper example. The convenient stack is Windows, Norgate Platinum or Diamond data, RealTest itself, and an Interactive Brokers order basket, and it persists as a culture, whatever its capabilities. Strategies circulate as .rts files, and education, paid code and the advice to just use Norgate form a closed loop, good at producing more users of the product and poor at producing researchers who can leave it. The people recommending the product are, in my experience, mostly its own users, running daily equity mean-reversion and breakout systems. Nor is the pattern confined to these two products: AmiBroker, NinjaTrader, MultiCharts and MetaTrader are each a Windows desktop application with its own scripting dialect, and each keeps its users long after they have outgrown it.

Over the years many people, myself included, have spent a considerable amount of time adding band-aid solutions to TradeStation: DLL callouts, a client-server architecture to reach the platform from outside its walled garden, misuse of the TradeStation Optimizer API to improve the user experience, cut-and-paste code fragments to export data for processing elsewhere, and much more. The ingenuity its users have put into working around its many shortfalls says a lot about their tenacity, but it also points to a dangerous blind spot, because traders who become proficient on a particular platform cannot overcome the inertia of moving to a new one, even when it is obviously better. Beneath the inertia sits the sunk cost fallacy, yet the hours that went into a library of EasyLanguage or .rts files are spent whichever way the trader decides, and they are no reason to spend the next five years inside the same walls. The case for moving also grows with time, because requirements drift. On the first day a trader’s needs are a subset of what the tool was designed to do; a year later they are a superset, taking in a futures roll the trader controls, intraday stops that can be verified, regime models, a second data vendor to compare against, and a strategy that runs on Linux. In the brave new world of AI, it is even more important for traders to assess critically whether their platform is still relevant and competent, so that they are not left behind. My working assumption is that whoever takes the opposite side of any trade I place is probably smarter than I am, so I don’t want to make it any harder than it already is by bringing the trading equivalent of the knife to a gunfight. To be fair to TradeStation, every platform has its limitations, and the software development experience on most (all?) of the widely available platforms is extremely poor. Some (including me in this paper!) will argue that it’s not all about the platform. That’s true, but I see no reason to operate on inferior tools, and in my case I have built my own backtesting platform. (For almost all traders, I would strongly recommend against going down that path!)

Other platforms have recognised specific instances of these problems and introduced partial mitigations. TradingView’s “Bar Magnifier” mode exists because the OHLC sequence ambiguity described in Section 4.2 is a real and widely encountered failure: the feature uses finer-resolution data to resolve intra-bar order fills during backtesting, an implicit acknowledgement that standard bar-by-bar evaluation is insufficient. TradeStation and MultiCharts offer an “Intra-Bar Order Generation” (IOG) mode that evaluates orders within each bar as well as at bar close, which tackles the same class of problems by a different mechanism. QuantConnect’s LEAN engine takes a more explicit architectural stance, pushing users towards finer-resolution data for realistic fills and exposing custom slippage and margin models as first-class configuration options. That these features exist at all confirms how severe the underlying problems are; that they are options to be configured, when they could have been default behaviour, confirms that the retail backtesting ecosystem still puts ease of use ahead of simulation fidelity.

A daily-only platform cannot offer even an optional bar magnifier, because intraday data is not a legal input. RealTest accepts only daily bars, which it can compress to weekly or monthly but never refine, and it resolves stops and limits inside the bar by inferring the path from the open, high, low and close. As of October 2026, intraday bar support was reportedly its most requested feature and in progress, but until it ships the platform has no way to check whether that inferred path matches what the market actually did.

In TradeStation’s case many of the constraints are hard limitations enforced by the platform’s parser and runtime environment, over and above the conceptual preferences encoded in its documentation and examples. EasyLanguage does not permit orders to be placed inside loops, which rules out pyramiding or scaling into positions algorithmically. Named orders must be string literals, so they cannot be built from expressions at run time, and that prevents programmatic management of multiple concurrent entries. The platform cannot query how many data series have been provided to the strategy, making it impossible to write strategies that adapt to an arbitrary number of instruments. Variable back-references are subject to hard-coded limits that constrain lookback calculations. Complex data structures (maps, trees, graphs, and the arbitrary nesting of collections that modern languages provide as primitives) are effectively non-existent. Portfolio-level support is extremely limited, meaning that strategies are evaluated in isolation from one another with no mechanism for cross-strategy risk management or capital allocation, a limitation that directly reinforces the signal isolation problem discussed in Section 9. And there is no facility for custom optimisation metrics, so the researcher is constrained to the platform’s built-in fitness measures when searching the parameter space. Weak portfolio support is not universal, though: RealTest gets portfolio-level, multi-strategy capital allocation right, better than it is done in far more expensive products, while sharing the absence of rich data structures and lacking typed variables and composable functions besides.

Each of these limitations forces a design compromise, and together they make entire classes of strategy impossible to build on the platform. A trader who has spent years developing within these constraints may not recognise what they have never been able to try, and the strategies they build reflect what the tool permits as much as their ideas about markets, to a degree that is hard to appreciate from inside the ecosystem. Platform constraints turn into methodological homogeneity through this gradual, invisible narrowing of the design space to the subset the tool can express, without anyone ever being instructed to conform.