Backtesting and Journaling ICT Setups: A Practical Guide

Reading about ICT concepts is the easy part. Knowing whether your version of them has any edge is harder, and the only honest way to find out is to test it. Backtesting looks at past data under fixed rules; journaling records what you actually do in live or simulated trading. Together they turn opinions into evidence you can review.

What it is

• Backtesting means applying a written set of rules to historical charts and recording each trade the rules would have produced.
• Forward testing applies the same rules in real time, on a demo account or the Trading Simulator, before risking money.
• Journaling captures every trade, planned or taken, with enough detail to review it later in your Trading Journal.

Most ICT setups involve judgment, so manual backtesting with bar replay is far more common than automated testing. That makes clear rules even more important.

How to do it

1. Write objective rules. Define the timeframe, the higher-timeframe bias method, the time window in New York time (ET), what counts as a sweep, what counts as displacement, the entry level, stop placement and target.
2. Choose one instrument and one setup. Testing five ideas on five markets at once produces a muddle.
3. Use bar replay. Most charting platforms let you hide future candles and step forward one bar at a time. Start each session before the kill zone and do not peek ahead.
4. Log every valid setup, including the ones you would have liked to skip. Selective logging is the most common way backtests lie.
5. Record results in R. One R is the amount risked. A trade that hits a target three times the stop distance is +3R; a full stop is −1R.
6. Include costs. Subtract a realistic spread from each trade, especially when stops are small.
7. Review in batches, for example every 20 trades, rather than after each one.

Journal fields

A screenshot journal should let you rebuild the trade months later. Useful fields:

The "rule followed?" field is often the most revealing. Many traders discover that their rules are reasonable but their execution is not.

Worked example: reading a sample

The following log is hypothetical, used only to show the arithmetic. A trader backtests a 2022 model variant on GBP/USD and logs 40 setups:

• 14 trades reach target, averaging +2.5R each = 14 × 2.5 = +35R
• 26 trades are stopped out at −1R each = −26R
• Net result: 35 − 26 = +9R
• Expectancy: 9 ÷ 40 = +0.225R per trade
• Longest losing streak in the log: 7 trades

At 1% risk on a $10,000 account, +9R would equal about $900 before compounding and costs, and the 7-trade losing streak would be roughly a 6.8% drawdown (1 − 0.99^7 ≈ 6.8%).

Now the caution. Forty trades is a small sample. If just three of the winners had been losers instead, the net result would fall to 11 × 2.5 − 29 = −1.5R, which is negative. Small samples swing easily, so the honest conclusion is "promising, needs more data", not "this works". Testing across different market conditions, such as trending and ranging months, matters as much as raw trade count. A setup that only worked during one strong trend may struggle when the market turns choppy, so note the conditions alongside each batch of results.

How traders use it

• To build confidence in rules, so they can sit through normal losing streaks without abandoning the method.
• To refine filters. Splitting results by kill zone, day of week or PD array type can show where a setup struggles, but each split shrinks the sample further.
• To set realistic risk. The longest losing streak in testing helps choose a risk per trade you can tolerate; see ICT risk and trade management.
• To catch execution drift. Comparing live journal results with backtest results shows whether you are trading the same rules.

Common mistakes

• Vague rules such as "strong displacement" without a definition.
• Hindsight bias, marking setups after seeing how they ended.
• Skipping losers in the log or quietly changing rules mid-test.
• Over-optimizing, adding filters until past results look perfect; such rules often fail on new data.
• Ignoring spread and slippage on short-term trades.
• Drawing firm conclusions from 20 or 30 trades.

Summary

Write objective rules, test them with bar replay on one instrument, log every valid setup, and measure everything in R. Keep a screenshot journal with bias, kill zone, PD array, entry, stop, target, outcome and whether you followed the rules. Treat small samples as provisional and include costs. Past results, real or simulated, never guarantee future ones. The final lesson covers the most common ICT mistakes that a good journal tends to expose.