Page 1 of 1
A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Sat Oct 24, 2026 6:51 pm
by Fairman
A filter that doubles expectancy per trade but lowers the week's total: check costs first
Say a pullback setup fires 50 times a week. It wins 45% of the time at 1.5R with a 1R stop, so the expectancy is 0.45 times 1.5 minus 0.55, which is +0.125R per trade, or +6.25R a week before costs.
Now you add a filter, maybe a higher timeframe trend check. It leaves 20 signals a week and the win rate on those is 52%. Expectancy per trade becomes 0.52 times 1.5 minus 0.48, so +0.30R. That's 2.4 times better per trade. The weekly total is 20 times 0.30, which is +6.0R, slightly lower than the +6.25R you had without it.
So before costs the filter looks great per trade and gives up a bit overall. Add a cost of 0.1R per trade for spread and commission and the picture flips. Unfiltered: 50 trades at 0.025R net, so +1.25R a week. Filtered: 20 trades at 0.20R net, so +4.0R a week.
The same filter is a mild loss or a big win depending on whether you count costs. It's why looking at expectancy per trade alone is a trap in either direction. The number to compare is expectancy per week (or per day), net of costs, and the fewer trades have to be enough to hold up on their own.
All figures here are illustrative, built from round numbers, not from my journal.
Re: A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Thu Oct 29, 2026 7:46 am
by FXS Prop Desk
Fairman, this is a good example of why expectancy per trade alone can mislead. The weekly total is what pays, and a filter that halves the number of trades needs to more than double the expectancy to come out ahead. Costs make the comparison even tighter, since they are paid per trade regardless of the filter. A worked case shows it: 50 trades at +0.125R is +6.25R, while a filter leaving 20 trades needs above +0.31R each just to match that week.
Re: A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Sat Oct 31, 2026 4:33 am
by Fairman
Measuring the filtered system takes longer. At 20 trades a week you collect 100 trades in 5 weeks, where the unfiltered one gets there in 2. At a 52% win rate and 1.5R the standard deviation of a single trade is around 1.25R, so after 100 trades the standard error of the average is 0.125R. The measured +0.30R edge sits about 2.4 standard errors from zero, which is decent, but the confidence interval runs from roughly +0.05R to +0.55R. A filter that was picked by looking at old data also tends to look better on that data than it will going forward, so the first weeks of live results usually come in below the backtest.
Re: A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Sat Oct 31, 2026 5:04 am
by Fairman
There's a simple bar the filter has to clear. In the example it must produce at least as much net R per week as before. The unfiltered net is 50 times 0.025R, or 1.25R. Spread over 20 trades, the filtered net per trade must be at least 0.0625R, so gross expectancy of 0.1625R. At 1.5R reward to risk that needs a win rate w where 2.5w minus 1 equals 0.1625, so w is 46.5%. That's all. The filter only has to lift the win rate from 45% to 46.5% on the remaining signals to break even net, which is a much lower hurdle than 52% suggests. Run the same sum on your own numbers.
Re: A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Sat Oct 31, 2026 5:33 am
by Fairman
Look at what the filter threw away. 50 signals at 45% is 22.5 winners. The filtered set has 20 signals at 52%, 10.4 winners. So the 30 removed signals contain 12.1 winners, a 40.3% win rate. Their gross expectancy is 0.403 times 1.5 minus 0.597, about +0.01R, and after the 0.1R cost it's roughly minus 0.09R each. So the filter removed 30 trades that on balance lost money. That explains why the net result improved so much: cost is charged on every trade, and the removed ones were barely better than free. Keeping the discarded signals in a column labelled filtered out lets you check this on live data.
Re: A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Sat Oct 31, 2026 6:12 am
by Fairman
A filter that removes trades at random does the opposite. Cut 30 signals chosen by coin flip and the remaining 20 keep a 45% win rate. Gross is 20 times 0.125, which is 2.5R, net is 20 times 0.025, which is 0.5R, down from 1.25R. When net expectancy is positive, thinning trades randomly always lowers the weekly total; when it's negative it cuts the losses. So a filter's value comes entirely from how much better the kept set is than the discarded set, and that comparison needs the discarded trades recorded. If the two groups win at nearly the same rate, the filter is a time saver and nothing else.
Re: A filter that doubles expectancy per trade but lowers the week's total: check costs first
Posted: Sat Oct 31, 2026 9:56 pm
by Shadow Trader
Most traders track wins, losses, and spread. Fewer track slippage as a separate cost. It deserves its own line.
Total slippage over a month, in pips and in money, is easy to calculate from a trade log with requested and executed prices. Dividing by the number of trades gives the average per trade. Comparing it to the average profit per trade shows how much of the edge is consumed.
An example: a strategy earns 1.4 pips per trade on average, and slippage costs 0.5. That's a third of the edge. If slippage doubles in a volatile month, the strategy can flip from profitable to losing without any change in signal quality.
Tracking slippage by session adds more insight. London open slippage may be 0.2, while the New York close is 0.6. Moving trades away from the costlier windows can improve results without altering the strategy.
It's dull bookkeeping, but it explains many mysteries: why the live result trails the backtest, why a good month turned flat, why one broker seems better than another.
What share of the average profit goes to slippage in the logs kept here?