The development and implementation of a trading strategy undergo several phases. Often the backtesting phase is presented as a crucial phase in determining whether a trading model or strategy is relatively viable and profitable. This phase is so widely known that many of us have become backtesting specialists, and sometimes forget the reality as well as the complex environment that a production launch presents us with.

Indeed, once the strategy starts its life in the real market, it is very difficult to revert back. For instance, take the example of a rally, despite having a beautiful car, the reality of the terrain is sometimes cruel; no one is guaranteed from having a breakdown or from having an exceptional violent event, which is often followed by consequences that are difficult to explain. We then start trying to adapt to the terrain in the middle of a race; we change one first parameter, then a second, and we deactivate some assets hoping that this will save the day... long story short, we build a new strategy on the fly, which is often a losing proposition! We try to limit the losses, but remember, our first goal was always to win!

What if we took a little more time to better validate our trading process?

In addition to "paper trading" and going into production with a small size to run the model, it is important to test the constraints imposed by the operation of our strategy in real conditions. This phase is called "Stress-Testing". The principal objective is to validate our strategy before it is put into production based on two levels: technical and functional.

Technical

The objective of the technical stress test is to test the behavior of the strategy following breakdowns or technical events such as a feed disconnection, a feed delay, a fast market, or even a delay when starting up our strategy.

Functional

The functional stress test aims to validate our strategy from a model point of view. For example, our strategy is a trend following strategy; what happens if for some time, according to the trading horizon of the model, it becomes "rangy"? Or if we have a strategy based on volatility and see a change in market conditions...

How is this done?

Our strategy must be built in a "code invariant" way, i.e. we must be able to use the same workflow and the same binary or source code for each and every phase (backtest, paper trading, and live trading). The test phase (backtest and stress test) consists of three steps. These three steps are listed as follows;

• Generation of market data (storyboard) from historical tick data by applying the appropriate filters and transforms (to introduce shocks, and/or rare events, technical or functional)
• Simulation: using the event-driven approach, replay the storyboard
• Analysis: analyze the performance and evaluate the scenario results

By applying these particular filters, or transformations to the historical data, as well as using this storyboard as in the standard backtest phase, we will be able to test the robustness of our strategy. Obviously, the stress test is not intended to improve the performance of the strategy (more P&L). It revolves around measuring and then limiting the impact of real market conditions on our model so that we can continue the race.