Simultaneous signals need a deterministic portfolio-level decision before any order is sized or accepted. If the backtest simply processes whichever symbol appears first, the equity curve partly measures a software loop rather than the trading rule.
This matters most when several strategies share one account constraint. They may all be valid alone, yet not all fit through the same risk, margin or exposure gate at the same instant. The collision policy decides which opportunities survive. It belongs in the strategy specification.
What counts as a simultaneous signal
Signals are simultaneous when the backtest cannot establish a meaningful market-time order between them before applying a shared account decision. They do not need identical code paths. They only need to compete against the same portfolio state.
A collision can happen when several symbols close a bar at the same timestamp, when separate sleeves react to one account event, or when multiple pending orders become eligible inside a time interval whose internal path is unknown. Bar-close and intrabar backtesting explains the underlying problem: coarse data can show that events occurred, but not necessarily which event came first.
The safe question is not, “Which order did the engine happen to visit first?” It is, “What information was available to every candidate at the decision boundary?”
Take one portfolio snapshot before choosing
A robust test evaluates every same-time candidate against one frozen pre-decision account snapshot. That snapshot includes open exposure, floating equity, reserved margin and any active account-level restriction.
Without a frozen snapshot, the first processed signal changes the state seen by the next one. Available risk shrinks, margin changes and a concentration cap may engage. Reversing the symbol list can then reverse the winners without any market input changing.
Keep the stages separate:
| Stage | What the backtest records |
|---|---|
| Candidate creation | Every valid signal at the decision boundary |
| Eligibility | Whether each candidate passes its own strategy rules |
| Portfolio selection | The declared rule used when candidates compete |
| Sizing | Size calculated after selection against the shared account state |
| Submission result | Accepted, rejected or reduced, with a reason |
This ledger prevents a rejected opportunity from disappearing. That is essential when auditing margin in a cTrader backtest, because an impossible order should not silently become a filled trade, and a refused order should not vanish from the explanation.
Choose a collision policy you can defend
A collision policy is the explicit rule that ranks, groups or refuses signals competing at the same decision point. There is no universally correct policy. There are only policies that match the intended live system and policies selected after seeing which historical result looked best.
Several designs are defensible when declared in advance:
- Fixed priority: a stable strategy or symbol rank resolves every tie. It is reproducible, but the priority itself becomes part of the strategy.
- Shared allocation: eligible candidates divide the available risk budget under a stated rule. This preserves breadth but can make each position smaller.
- Score-based selection: a signal score decides the order. The score must exist at decision time and needs its own out-of-sample validation.
- Reject the whole collision: the system stands aside when it cannot resolve the competition safely. This is conservative, though it changes trade frequency.
- Independent orders under a hard portfolio gate: all candidates remain eligible until the common cap is reached. A deterministic tie-break is still required at the boundary.
The tempting mistake is to sort by the profit each trade later produced. That is look-ahead bias with tidy formatting. Priority may use only information available before the orders are chosen.
Test whether iteration order owns the result
A useful sensitivity check reruns the same candidates under alternative deterministic traversal orders. Reverse the symbol order, reverse the strategy order and apply a neutral stable key. If the portfolio result changes materially, the collision policy is not an implementation detail; it is carrying part of the outcome.
Do not average those runs and call the problem solved. The spread between them is evidence that the specification is incomplete or that the system is sensitive to tie handling. Choose the live-intended rule, document it and validate that exact version out-of-sample.
This is closely related to portfolio heat in prop backtesting. Portfolio heat says how much combined exposure the account permits. Collision handling says which candidate receives the remaining capacity when several arrive together.
Keep correlation and sequence separate
Two signals can collide without being strongly correlated, and correlated positions can enter at different times. Why correlated trades fail prop accounts covers concentration across positions; same-time sequencing is a separate execution question.
The test should therefore log both. Record the portfolio exposure created by the accepted set, and retain every candidate excluded by the sequencing rule. A low final drawdown does not explain whether diversification worked or whether a hidden ordering preference repeatedly favoured one sleeve.
What the backtest still cannot prove
A deterministic collision policy makes the historical test reproducible. It does not prove that live messages will arrive in the same order, that a broker will accept every selected order, or that latency will be harmless.
For a cTrader system, the honest artefact includes the timestamp convention, the shared-state snapshot, the tie-break rule and the rejection ledger alongside the backtest output. realbacktesting is a trading-software studio for cTrader built around results that can be inspected and reproduced; its methodology makes execution and validation assumptions visible rather than asking the curve to speak for them.
Frequently asked
Should simultaneous signals be processed alphabetically?
Alphabetical order is reproducible, but it is still a portfolio rule. Use it only if that stable priority is acceptable in the intended system, and test how much the result depends on it.
Can every valid signal be sized before selection?
Not safely when signals share a risk or margin budget. Pre-sizing each candidate as if it were alone can allocate the same capacity more than once. Select against a common snapshot, then size the accepted set under the declared policy.
Is random tie-breaking more realistic?
Randomisation can expose sensitivity, but it does not define a reproducible live rule unless the random process itself is fixed and intentional. Use it as a stress test, not as a substitute for a specification.
The stubborn takeaway
If changing the order of a list changes the backtest, the list order is part of the strategy whether you documented it or not.