A max-open-positions rule is not a safety label. It is an entry rule: once the book is full, every later signal must be rejected, deferred, or handled by a policy you can name.
That changes the backtest. The curve is no longer the result of every signal the strategy found. It is the result of the signals that survived a capacity constraint and the order in which the engine encountered them.
What a max-open-positions rule actually controls
A maximum-open-positions rule caps the number of live positions the system may carry at the same time. It is often used to limit concurrent exposure, prevent a cBot from opening an unlimited stack of trades, or keep an account's operational load understandable.
The cap does not say whether the positions are diversified. Several open trades can still express the same market risk. Nor does it set the cash loss of a position; sizing, exits, costs and the account path still do that work. The portfolio heat guide explains why a small-looking list of trades can still create a large committed loss.
What the cap does decide is simple: when a valid new signal arrives and capacity is unavailable, the model cannot pretend that trade happened. The chosen response belongs in the test specification.
The missing rule is usually the collision policy
A capacity cap becomes ambiguous at the exact moment a backtest needs to be precise. Signals can arrive while a position is open, while another order is pending, or at the same timestamp as an exit. A report that only says "maximum positions" leaves the decisive part unstated.
Write the collision policy before looking at the result:
| Situation | Rule the test must define |
|---|---|
| A new signal arrives at capacity | Reject it, queue it, replace an existing position, or apply another declared action |
| Several signals arrive together | The deterministic priority or tie-break used to choose among them |
| An exit and an entry share a timestamp | Whether the exit frees capacity before the entry is evaluated |
| A pending order activates at capacity | Whether activation consumes capacity and what happens to the existing book |
| A partial exit occurs | Whether the position remains one open position under the rule |
| A restart occurs | How the cBot rebuilds its count from live positions rather than memory alone |
None of these choices is cosmetic. A priority rule can repeatedly favour one symbol or strategy. A queue can make an entry stale. Treating a same-timestamp exit as already complete can create fills that the engine never could have had. The simultaneous-signals guide covers the broader problem of deterministic ordering; a position cap is one place where that ordering becomes an account constraint.
Count the same thing in the test and in cTrader
The unit being counted must be explicit. A position is not the same thing as a signal, an order, a strategy sleeve, or a symbol. A cBot can have a valid signal without an open position; a pending order can be waiting to become one; a single position can be partially reduced without disappearing.
A useful test log records the count before and after every event, together with the reason for the decision. It should make these questions answerable without reconstructing the engine from an equity curve:
- Which positions were open when the incoming signal was assessed?
- Did the count include pending orders, and if so, at what stage?
- Which signal lost capacity, and why?
- Did an exit, stop modification, partial close, or restart alter the count?
- Could the same event sequence be replayed in cTrader?
That last question matters. A backtest has little value if its capacity rule is a research-only convention that the live cBot does not implement. The cBot restart checklist is relevant here because state recovery is part of the rule, not a separate reliability feature.
Compare the cap against an unchanged control
The honest way to assess a max-open-positions rule is to test a declared control beside the capped version. Keep the data, signal logic, costs, sizing, exit logic and evaluation window unchanged. Change only the capacity rule and its collision policy.
Then inspect more than the final return. Compare the accepted and rejected signal ledger, the time spent at capacity, the clustering of open positions, the equity path, drawdown, trading costs and the conditions around the largest differences. The cap may reduce overlap. It may also discard the trades that carried a particular historical period. Both are results, not conclusions to choose in advance.
For a prop-firm context, put the resulting account path beside the applicable rules, including how floating equity and time boundaries are defined. Do not infer compatibility from a calmer chart. The daily reset backtesting guide shows why account constraints depend on the exact clock and measurement rule.
A test plan that can be challenged
A compact scenario set catches much of the hidden behaviour before a live account does:
| Scenario | What to verify |
|---|---|
| Capacity is already full | The new signal receives the declared treatment and the log explains it |
| Competing signals share a timestamp | The same priority is applied on every replay |
| A position closes as a new signal arrives | Event order matches the documented engine rule |
| A pending order activates | The count and the account ledger remain internally consistent |
| The cBot restarts with positions open | The recovered count matches the positions actually held |
| Several positions move adversely together | The cap is reviewed alongside aggregate open risk, not used as a substitute for it |
A scenario that passes does not prove a strategy will be safe in live trading. It proves something narrower and more useful: the rule did what the specification said under a known sequence of events. That is the standard a reviewer can reproduce.
Frequently asked
Does a max-open-positions rule reduce risk?
It can limit concurrent positions, but it does not by itself measure or cap the loss of those positions. Assess sizing, stops, costs, correlation and aggregate open risk separately.
Should a backtest queue signals that arrive at capacity?
Only if the strategy specification says so and defines when a queued signal expires or becomes executable. A delayed entry is a different trade, not the original signal preserved.
Can a position cap improve a backtest?
It can change the path by excluding or deferring trades. Compare it against an unchanged control and inspect the accepted and rejected signal ledger before drawing a conclusion.
Is a position cap enough for a prop-firm account?
No. A prop account can be affected by floating equity, costs, correlated moves and firm-specific rules that a simple count does not describe. Verify the current rule set and test the full account path.
The stubborn takeaway
A maximum number of open positions is not a risk model. It is a choice about which trades the model is allowed to have—and every excluded trade belongs in the evidence.