A Strategy That Compiled Perfectly and Still Lost Money

The script built with zero errors. Every order call was correctly formed. Risk was sized off account equity and the stop distance. The table rendered, the levels drew where they should, the markers landed on the right bars.

It finished with a profit factor of 0.939.

That is a useful result to look at closely, because nothing about it was a coding failure. This is what a correctly implemented bad idea looks like.

The strategy

A session range break with risk-based sizing:

• track the high and low of a defined session
• arm a long above the range high and a short below the range low
• enter on the break, place a stop the other side of the range, set a target at a fixed multiple
• close anything still open at the session close

That last rule is the whole story, though it does not look like much when you write it.

What the backtest returned

Over the sample:

A 36.84% win rate is not the problem on its own. Plenty of profitable strategies win a third of the time, because the wins are large enough to carry the losses. Profit factor is where it breaks: 0.939 means the strategy earned 93.9 for every 100 it gave back.

Where the money went

The trade list explains it, and this is the part worth learning to read. The exit reasons were not evenly distributed. Several winners closed with the comment Session end at values like +119.2 and +135.4 — a fraction of what the target would have paid.

The losers had no equivalent brake. A stop is a price, and price reaches it whenever it reaches it. So the rule set was asymmetric in the worst direction:

• losers ran the full planned risk distance
• winners were interrupted by the clock

Position sizing made this sharper rather than softer. Risk was sized on the assumption of a reward multiple that the exit rule frequently did not permit. Every trade was sized for a payoff it was not allowed to collect.

How to tell this apart from a code bug

Read the exit reasons before you touch the source.

If trades are closing for reasons you deliberately wrote — session end, time stop, opposite signal — the code is doing its job and the rules need work. If trades close for reasons you never wrote, or at prices that do not correspond to any level you defined, then look at the code.

That distinction saves a lot of wasted effort. It is very common to rewrite working logic because a backtest disappointed, when the honest problem was the rule set all along.

What would actually help this strategy

Not a refactor. Options that change the distribution rather than the syntax:

• Let the session-end rule apply only to losing positions, so the clock stops losses but does not cap wins.
• Move the stop to break-even once price travels a defined distance, so the interrupted trades exit flat instead of small.
• Size from the realistic payoff rather than the target, if the exit rule genuinely has to stay. If most winners close at 0.6R, size for 0.6R.
• Test whether the session boundary matters at all. Sometimes the constraint is inherited from a habit rather than from the market.

Each of those is a change to the idea. That is the point.

The part the compiler cannot check

There are three separate questions, and passing one says nothing about the next:

1. Does it build?
2. Does it do what I described?
3. Is what I described worth doing?

A validator can answer the first. Careful reading of the source and the plotted output answers the second. Only exposure to bars you have not already studied answers the third — and that is judgement, built by making calls before you know the outcome and finding out where your reasoning was wrong.

Review checklist

Reading a backtest honestly

• Check profit factor before win rate: a high win rate can still lose money
• Group the exits by reason and see which rule is closing your winners
• Compare the average win to the risk you sized for, not to the target
• Ask whether every constraint in the rules is there for a reason you can state
• Judge the idea on charts you have not already optimised against