AlgoWay Blog

Guides, manuals and platform references.

Core
JSON & Alerts
MT5 / Expert Advisors
Errors
Integrations
Other Publications
AlgoWay Strategy Lab

Trading Expectancy: Why a High Win Rate Can Lose Money

AlgoWay trading automation

Eight winning trades out of ten sounds comfortable. It says nothing about whether the two losers ate the furniture.

Trading expectancy combines how often you win with how much you win and lose. A high win rate can lose money when losses are large enough, and a positive result before costs can become negative after them. Start with the cash ledger, then admire the percentage.

Count money as well as wins

For a sample with winning and losing trades, gross average payoff is:

E = p × W − (1 − p) × L

Here p is the fraction of winners, W is the average gross winning amount, and L is the average gross losing amount expressed as a positive number. All amounts must use the same unit. This is the weighted-payoff approach described in CME Group's lesson on mathematical expectation.

Consider two invented sets of 100 completed trades. These are arithmetic examples, not tested strategies, forecasts or recommendations.

ExampleWinnersAverage winLosersAverage lossTotal before costsAverage per trade
A80$2520$120−$400−$4
B45$9055$50$1,300$13

A wins 80% of the time, but $2,000 in wins fails to cover $2,400 in losses. B wins only 45% of the time, yet $4,050 covers $2,750 with $1,300 left. The lesson is not to prefer a low win rate. It is to stop evaluating either percentage without the size of the outcomes attached.

Subtract costs once

If C is the average round-trip cost not yet included in those gross outcomes, the calculation becomes:

E_net = p × W − (1 − p) × L − C

With an illustrative $6 cost per completed trade, A falls to −$10 per trade and B falls to $7. At $14, B would instead average −$1. A small gross advantage can disappear without a single change in the entry signal.

Define the ledger carefully. If each outcome already uses actual entry and exit fills, the effects of spread and execution slippage relative to a reference price are already reflected in that fill-based result. Do not deduct those same effects again. Subtract commissions, financing or other charges only to the extent they are missing from the recorded result. Conversely, a hypothetical midpoint-price calculation must not be mistaken for an executable-price ledger.

For net results, a simpler audit is to sum the net P&L of all completed trades and divide by their count. TradingView documents Expected payoff as net P&L divided by completed trades; it excludes floating P&L from positions still open. A profitable closed-trade average therefore does not describe the whole account if a large losing position remains open.

Calculate the win rate needed to break even

Under the simplified assumptions of fixed average gross win, average gross loss, and average cost, set net expectancy to zero and solve for the required winning fraction:

p_break_even = (L + C) / (W + L)

For example B before costs, the threshold is 50 / 140, or about 35.71%. With $6 costs it becomes 56 / 140 = 40%. With $14 costs it becomes 64 / 140, or about 45.71%, above B's assumed 45% win rate.

This calculation is a sensitivity check, not an invitation to edit only the win-rate cell. Moving a target closer may increase winning frequency while reducing average wins. Changing a stop may change both average loss and the number of losses. Recalculate from the outcomes produced by the revised rule.

Keep the denominator honest

A trade must mean the same thing throughout the calculation. Three partial exits from one entry should not become three independent winning ideas in one column while the matching losing position counts as one idea in another. Choose either the report's trade convention or a consistently reconstructed position-level ledger, and document it.

If zero-result trades exist, include them in the total count. The general form is E = p_win × W − p_loss × L, with both frequencies measured against all completed trades. Now p_loss is not necessarily 1 − p_win. For a fully net ledger, zero-result trades contribute zero cash but still affect the average.

Varying position sizes require another distinction. Average dollars per trade measures the size-weighted cash outcomes you actually recorded. An average in risk units answers a different question: divide each trade's net result by its own recorded initial cash risk, then average those ratios. Do not divide the whole ledger by a convenient risk amount that only some trades used.

What the average cannot tell you

TradingView's profit factor compares the total winning amount with the absolute losing amount. On the before-cost ledger above, A has a factor of about 0.83 and B about 1.47. This ratio and average payoff summarize different features; use a consistent cost basis before comparing them.

Neither number preserves trade order. Rearranging the same wins and losses leaves their average unchanged but can put all the losses into one unpleasant stretch. Review drawdown and the sequence of outcomes alongside expectancy. Also inspect whether a few unusually large winners account for most of the total.

A sample average describes that sample. Calling it “expected” does not establish that future prices, costs or fills will repeat it. Save the rules and test period used to produce the ledger, then compare with a separate period or forward observations. The TradingView backtest and forward-results workflow covers keeping those comparisons organized.

For your next strategy review, bring four items: the complete closed-trade ledger, its cost definition, the treatment of partial exits, and the remaining open exposure. A win-rate screenshot leaves too much of the bill off the table.

Last updated: October 8, 2026