A kill switch that watches only closed P/L can miss the breach it was meant to prevent. A prop-firm rule can be evaluated on equity while positions are still open, so a green balance is not proof that the account is safe.
Test a prop-firm kill switch as a control system, not as a line of code. Replay the account path, force the boundary cases around the daily reset, and verify that the switch blocks new risk, handles open orders, survives a restart, and leaves an audit trail.
The thesis is stubbornly simple: a kill switch is not verified when it prints “limit reached”. It is verified when the same event produces the same protective action under every relevant path.
What a prop-firm kill switch is protecting
A prop-firm kill switch is an account-level control that stops a strategy from adding risk after a declared loss or operating condition is reached. A stop loss limits one position. A kill switch governs the whole strategy, including positions and pending entries that were created by earlier signals.
FTMO's current Trading Objectives describe Maximum Daily Loss using account equity, including open-position P/L, swaps and commissions, and state that the daily calculation is made at 00:00 CE(S)T. Those rules belong to FTMO and can change, so the firm's current page is the authority for an account you actually trade.
cTrader exposes both Account.Balance and Account.Equity. The cTrader IAccount reference defines equity in terms of balance and unrealised profit or loss. That distinction is the first test: a switch that reads only closed trades is measuring a different object from the one the rule may evaluate.
Write the rule contract before writing the test
The switch needs a written contract that another developer can implement without guessing. It should name:
- the account value being monitored: balance, equity, or the exact firm-defined combination;
- the loss boundary and the reference value from which it is calculated;
- the firm's timezone and reset event;
- whether a trigger blocks new entries, cancels pending orders, closes open positions, or applies another declared policy;
- whether the triggered state remains latched after the reset;
- what happens when account data, the clock, or order status is unavailable.
The daily-loss-limit versus max-loss explainer covers why the two account boundaries are not interchangeable. This test adds the implementation question: does the bot apply the right boundary to the right state at the right time?
How a prop-firm kill switch sees equity
The first failure case is an open loss with an unchanged balance. A position moves against the account, equity crosses the declared boundary, and the position later recovers before closing. A close-only backtest reports no breach. An equity-aware replay records one.
Use the finest account state the rule requires. If the rule can be breached while a position is open, checking only end-of-bar balance is not enough. With historical data, the available resolution sets the limit of what the test can prove. An M1 replay can still miss a sequence that happened inside the bar; a close-only replay cannot claim to have observed the intrabar path.
The account snapshot also needs the details that created it. Record:
- balance and equity at each control check;
- open positions and their unrealised P/L;
- pending orders that could add exposure;
- swaps, commissions, and other account adjustments included by the rule;
- the timestamp in the firm's timezone and the platform/server timezone.
cTrader's Positions collection and PendingOrders collection expose the objects a cBot must inspect. The test must include every route by which the account can still gain exposure after the trigger.
Test the reset as a separate state transition
The daily reset is not a midnight convenience. It is part of the rule. FTMO's current page specifies 00:00 CE(S)T for its daily recalculation; a local computer clock, broker server clock, and UTC timestamp can all tell a different story if the conversion is implicit.
Build boundary cases for an open position spanning the firm day, a trade or cost posting around the reset, a restart before the new baseline is written, and the daylight-saving relationship between the firm's clock and UTC.
For each case, the expected baseline, trigger state, and next permitted action must be written down before the replay runs. A safe implementation does not silently use yesterday's baseline, reset because the computer changed timezone, or re-arm itself because the process restarted.
Test the action, not just the alert
An alert in the log is not a protective control. Once the trigger is true, test the complete sequence:
- The entry gate rejects a new market order and pending entries are cancelled or disabled under the declared policy.
- Existing positions follow the documented action instead of being ignored by the switch.
- A signal arriving at the same instant as the trigger cannot slip through a race between the signal and the risk check.
- The switch records the event and its inputs, then remains in the declared state.
The close-versus-freeze decision is not universal. It depends on the firm's current rules, the strategy's design, and what the control is meant to enforce. Make the decision explicit and test the action itself. If a close request is rejected or an order cannot be cancelled, the test must show whether new risk remains blocked and how the failure is surfaced.
Use a failure matrix, not one happy-path backtest
The matrix below is small enough to run every time the kill switch changes and broad enough to expose the usual gaps.
| Case | State to replay | Expected evidence |
|---|---|---|
| Floating-equity breach | Balance stays above the boundary while open P/L pushes equity through it | No new entry; the event stores the equity snapshot |
| Pending-entry breach | A pending order can become a position after the trigger | The order is cancelled or disabled before it can add risk |
| Reset crossing | An open position spans the firm's daily reset | The new baseline and latch state match the written contract |
| Same-update race | A valid signal and the loss trigger arrive together | The ordering is deterministic and no unapproved entry slips through |
| Restart after trigger | The process stops and starts with the account still under pressure | State is restored or recomputed fail-safe; it does not re-arm silently |
| Stale account data | Equity, positions, or order status cannot be confirmed | New risk remains blocked and the data failure is visible |
| External intervention | A position or order changes outside the cBot | The next reconciliation catches the difference and records it |
The expected evidence matters as much as the final return: show trigger detection, action completion, rejected or missed orders, reset handling, and recovery after interruption.
How to backtest a prop-firm kill switch without curve-fitting it
Separate the strategy test from the control test. The strategy answers whether its signals and exits produced a result under the stated market model. The kill-switch test answers whether account rules were applied to the resulting event stream. Mixing the two makes it too easy to optimise the guard around one historical path.
Use a fixed protocol:
- Freeze the strategy, symbols, sizing, timezone, and execution assumptions.
- Define the rule contract and failure matrix before inspecting outcomes.
- Replay profitable and losing periods, including positions that span a reset.
- Report detection latency, entries after trigger, uncancelled orders, false resets, and restart recovery.
- Repeat on a hold-out period that was not used to tune the strategy or the control.
The control can pass its own tests while the strategy remains poor, or improve rule compliance while reducing return. Neither result proves a live account will behave the same way. It proves only that the declared control behaved as specified on the tested data and failure paths.
A reproducible cTrader baseline
realbacktesting is a trading-software studio for cTrader built around verifiable tests rather than screenshots. Its published methodology records intrabar M1 execution, 1 bps slippage, swap applied, a fixed 2-pip spread for the FTMO line, commission charged in the run, and a 30% out-of-sample hold-out.
Those are test conditions, not a live-performance promise. The methodology page documents the assumptions; the funding page places the equity path inside the account constraints that matter to prop traders. A kill-switch result belongs beside those conditions, not in place of them.
The companion balance-versus-equity drawdown guide explains why the observed path matters. The switch is the operational layer that turns that observation into a tested account response.
Frequently asked
Is Account.Balance enough for a daily-loss control?
Not when the applicable rule uses floating equity. cTrader exposes Account.Equity, and FTMO's current Trading Objectives describe its daily loss calculation using equity that includes open-position P/L, swaps and commissions. Verify the rule that applies to the account before implementing the contract.
Should the switch close every open position?
There is no universal answer. The required action depends on the firm's current rules and the control's declared purpose. Whatever policy is selected, test it as an action and test what happens when the close or cancellation request fails.
Can a backtest prove the kill switch will never breach a rule?
No. It can prove that the control handled the specified historical states and failure cases. Data gaps, execution differences, platform interruptions, and rule changes remain outside that proof.
What is the most important restart test?
Restart after the trigger while positions or pending orders still exist. The control must reconstruct the account state and remain blocked according to its contract. A process restart must not become an accidental reset button.
The stubborn takeaway
A kill switch earns trust only when a replayed breach leaves no new risk, no uncancelled entry, and no ambiguity about the clock.