A scale-in entry must be backtested as one changing position, not as a row of independent wins and losses. The test needs to preserve the order of fills, the combined quantity, the stop logic, and the worst floating loss while the position is being built.
That sounds fussy until a backtest reports a clean final exit while hiding the period when its exposure was largest. For a prop trader, that hidden path can matter more than the average entry price.
What a scale-in entry actually tests
A scale-in entry adds exposure to one trade idea over time. The additions may be planned at different prices, triggered after confirmation, or added as the market moves against the initial position. The label is less important than the rule that determines each new fill.
Three designs that look similar on a chart are not the same test:
| Design | What causes the next fill | What the test must preserve |
|---|---|---|
| Layered entry | A pre-defined price level is reached | Order priority, unfilled orders, and the shared exit rule |
| Confirmation add | New information meets a stated condition | The information available at that moment and the new stop logic |
| Adverse-move add | Price moves against the open position | The growing loss, the exposure cap, and the point at which no further add is allowed |
Calling all three “averaging” erases the mechanism that creates their risk. A credible backtest states the mechanism before it shows a result.
Why separate trade rows can flatter the result
Separate rows can make a campaign look tidier than it was. They can show several small entries and one profitable close without showing that all entries were open together when price was weakest.
The unit of analysis should be the campaign: the initial entry, every add, every reduction, and the final exit linked as one position. At every point in that campaign, the test should know the aggregate quantity, average entry, effective stop, realised loss, and floating loss.
One useful check is to calculate open risk from the full position rather than from the latest ticket:
aggregate open risk = sum of each open quantity × distance to its effective stop × value per pointThe formula is only as honest as the rules beneath it. If an add changes the stop for every open unit, the earlier units must be revalued at that new stop. If there is no hard stop, the report should say so rather than manufacture a risk figure after the fact.
Write the scale-in rule before looking at the curve
A scale-in backtest needs a small contract. The purpose is not to make the strategy rigid; it is to stop the test from deciding, after the outcome is known, which additions were convenient.
| Rule to record | The question it prevents |
|---|---|
| Entry trigger for each add | Was the fill available at the time, or chosen with hindsight? |
| Maximum aggregate quantity | Could exposure keep increasing during a losing move? |
| Order handling | What happens when several levels can fill in the same bar or when an order remains unfilled? |
| Stop and exit rule | Does an add move the exit for the whole position or only part of it? |
| Costs on every fill | Did the test charge the spread, commission, and swap created by the extra trades? |
| Campaign identifier | Can the report reconstruct the complete position rather than just its tickets? |
This is also where intrabar assumptions matter. A bar that touches more than one entry level does not tell a backtest which order occurred without a stated execution convention. The convention need not be flattering. It needs to be repeatable.
Measure the risk path, not only the final campaign P&L
The final profit or loss cannot show how much account risk was open along the way. A scale-in report is more useful when it adds path measures beside campaign P&L:
- maximum aggregate quantity;
- maximum floating loss while the campaign was open;
- maximum open risk under the stated stop rule;
- time spent at peak exposure; and
- the outcome of campaigns that never received every planned fill.
Those measures do not predict the next campaign. They make the historical one inspectable. They also complement, rather than replace, the portfolio-heat view: a single campaign can grow dangerous before its correlation with other positions is even considered.
The prop-firm question is account-level aggregation
A prop-firm rule set is applied to an account, not to the story a trade blotter tells. If the relevant rule observes account equity, the backtest must apply it to the combined position, its costs, and any other open exposure at the relevant observation points.
The exact definitions are not universal and can change. Verify the current firm terms before treating a generic daily-loss or drawdown label as a test rule. The funding model explains why a compliant backtest is not a promise of a funded outcome.
This is where reproducibility earns its keep. realbacktesting publishes cBot results as cTrader-native backtests that a trader can rerun and challenge in cTrader; the methodology and proof page set out that approach. A scale-in design deserves the same standard: someone else should be able to trace each fill and arrive at the same campaign.
Frequently asked
Can scale-in entries improve a backtest?
They can change the average entry and the distribution of outcomes, but that does not establish an improvement on its own. The test must show the added exposure, costs, and worst path as well as the final curve.
Should scale-in campaigns be reported separately from ordinary trades?
Yes, because a campaign has changing exposure that a single-entry trade does not. Keeping campaign statistics separate makes it possible to see whether the result depends on a small set of complex positions.
Does a profitable final exit prove that the scale-in was safe?
No. A final profit says nothing by itself about the maximum floating loss or aggregate open risk that occurred before the exit. Those are distinct observations and should be reported separately.
The position is the test
A scale-in is not several harmless tickets with a shared ending. It is one position whose risk changes over time; if the backtest cannot replay that change, the equity curve has skipped the part that matters.