A pending-order backtest is credible only when it separates the signal, order submission, trigger, fill and cancellation. In cTrader, the clean test records each event and states which quote, data resolution and execution rule moved the order to the next state.
The common shortcut is to treat “price touched my level” as “my order filled at that level.” That skips most of the machinery. A line on a chart is not an execution model.
A pending order is a state machine, not a price level
A pending order is an instruction that waits for specified market conditions before it can become a position. Its backtest therefore needs a lifecycle, not just an entry price.
cTrader supports stop, limit and stop-limit pending orders in its official cBot trading operations guide. Those names describe different instructions:
- A limit order waits for the market to reach a price at which the trader is unwilling to pay more, or accept less.
- A stop order becomes eligible after price reaches a trigger beyond the current market.
- A stop-limit order adds a permitted execution range after its stop trigger is reached.
They must not share one generic “touch equals fill” rule. A stop can trigger and then fill beyond its target during a fast move. A limit order constrains price but may not fill merely because an aggregated candle includes its level. A stop-limit can trigger without finding an acceptable execution inside its range.
The official cTrader PendingOrder reference exposes the fields that make this lifecycle inspectable: order type, target price, expiration time, stop trigger method, stop-limit range, submission time and last update time. If the test cannot report the equivalent facts, it cannot explain why an order became a position.
Write the execution contract before running the backtest
An execution contract is a short specification of how simulated orders move between states. Write it before looking at results, so a favourable equity curve cannot choose the rules after the fact.
| Contract item | What must be explicit | Failure hidden by silence |
|---|---|---|
| Submission | Signal timestamp, target price, volume and order type | An order appears before its signal was knowable |
| Trigger | Bid, ask or another documented trigger method | The wrong quote side activates the order |
| Fill | Executable price, spread, slippage and gap treatment | The test awards a price the market did not offer |
| Protection | When stop loss and take profit attach | A new position is briefly unprotected or protected too early |
| Expiration | Absolute time, timezone and session boundary | A stale order survives into a market regime it was not meant to trade |
| Cancellation | Rule, timestamp and event priority | An order fills after the strategy intended to withdraw it |
The contract also needs an event-order rule. Suppose the same observed interval contains a trigger, a cancellation condition and a session close. Aggregated OHLC data may show that all relevant prices occurred, yet not reveal their sequence. Picking the profitable sequence is not analysis. Use finer data or mark the case as ambiguous and test both defensible orderings.
This is the same underlying problem as bar-close versus intrabar backtesting, but the pending-order version has more states. The signal clock and the execution clock can differ. A strategy may decide from a completed bar and still require tick or intrabar observations to model the waiting order honestly.
Test the order path in cTrader
A useful cTrader test preserves the strategy while varying only the execution assumptions. cTrader's BacktestingSettings reference makes data mode, spread and commission explicit settings. Record them with the run rather than leaving them as platform folklore.
Start with a diagnostic log. For every order, retain:
- the signal time and the information available then;
- the submitted order type, target, volume and expiration;
- the bid and ask when the order was submitted;
- each modification and its timestamp;
- the trigger time, trigger quote and trigger method;
- the fill time, fill price and resulting spread or slippage;
- cancellation or expiry, including the rule that caused it;
- the first protective stop and target attached to the position.
Then build a small set of adversarial scenarios. Include a gap through a stop level, a candle that crosses both the trigger and the cancellation boundary, a limit touched only by the non-executable quote, a stop-limit that triggers outside its allowed range, and an order that expires while the market is closed. These are not predictions of frequency. They are unit tests for the engine's behaviour.
Compare data resolutions without changing the trading rule:
| Run | Question it answers |
|---|---|
| Higher-timeframe OHLC | How much ambiguity does the coarse test hide? |
| Intrabar bars | Which event sequences become observable? |
| Bid/ask ticks, where available | Does the chosen quote actually reach the trigger and offer an executable fill? |
| Pessimistic ambiguity rule | Does the edge survive when unknown order is not awarded to the strategy? |
The verdict is not that the finest available data must always produce the worst result. The verdict is that a change in result must be traceable to a specific order-state transition. If the return changes but the logs cannot show the first divergent order, the comparison is not yet reproducible.
Why pending-order errors matter to prop accounts
Pending-order errors change the equity path, not just the entry statistics. A phantom fill can create exposure that never existed. A missed cancellation can leave an order active into another session. An optimistic gap fill can understate floating loss at exactly the point an account constraint is tested.
The prop firm remains the authority for its current daily-loss and overall-loss rules. The funding model explains why the strategy path has to be evaluated against the account constraint rather than against closed-trade profit alone. Do not import a firm's reset clock or trigger convention from memory; save the rule source used for the run.
At realbacktesting, the same principle sits behind the published methodology: data, execution, costs and validation assumptions need to be visible before a result can be checked. realbacktesting is a trading-software studio for cTrader built around inspectable, reproducible tests. A pending-order strategy meets that standard only when another trader can follow the order from submission to its final state.
What this test does not prove
A correct pending-order simulation proves that the implemented lifecycle matches the written execution contract under the chosen historical data. It does not prove that live liquidity will match the backtest, that a broker will accept every order unchanged, or that the strategy has a durable edge.
Historical tick data still represents one feed. Slippage is still a model unless it came from relevant execution records. Queue position and available size may remain unknown. State those limits. Precision about the unknowns is more useful than pretending the platform reconstructed an order book it never observed.
Frequently asked
Does a touched limit price guarantee a fill in a backtest?
No. A candle touching the level may not reveal the executable quote, event order, available liquidity or queue position. The test must state what evidence counts as a fill and what remains unknown.
Should pending orders be tested with tick data?
Use data fine enough to answer the order-path question. Bid/ask ticks can resolve cases hidden by OHLC bars, but tick data does not remove the need to define trigger methods, spread, slippage, gaps and cancellations.
What is the difference between a stop and a stop-limit order?
A stop becomes eligible for execution when its trigger condition is met. A stop-limit also constrains the acceptable execution range, so it can trigger without filling.
How do I audit pending-order expiration in cTrader?
Log the submitted expiration, the algorithm timezone, the actual expiry event and the relevant market-hours boundary. Then test orders that approach expiry while the symbol is closed as well as while it is trading.
The stubborn takeaway
Do not backtest a line on a chart. Backtest the order's entire life, because the missing transition is usually where the imaginary fill enters the report.