A prop-firm daily reset is not a calendar detail. It is part of the risk rule, and a backtest that cannot replay it cannot tell you whether a strategy would have stayed inside that rule.
The usual error is to record the worst loss for each date on a chart and call that a daily-loss test. That only works if the firm defines its day by that same date, uses the same reset instant, and measures the same equity components. Those are assumptions, not harmless defaults.
A daily reset is a calculation boundary
A daily-loss rule needs three pieces of information: the reference captured at reset, the loss allowance, and the equity being checked after reset. Change any one of them and the same price path can produce a different pass-or-fail result.
FTMO's current Maximum Daily Loss explanation makes the distinction explicit for its 2-Step Challenge: the limit is recalculated at midnight CE(S)T, while equity includes closed positions, floating P/L, commissions, and swaps. That is an example of one firm's rule, not a universal prop-firm template. The firm and account type must be checked in the current rulebook.
For a backtest, write the rule as a contract before looking at the outcome:
| Field | Question the test must answer |
|---|---|
| Reset clock | At what exact server time does the new trading day begin? |
| Reset reference | Is it starting balance, starting equity, prior close, or another defined value? |
| Loss allowance | Is the allowance fixed from initial capital or recalculated from the reset reference? |
| Equity inputs | Do realised P/L, floating P/L, commissions, swap, and conversion effects count? |
| Breach timing | Is the rule checked continuously, at a snapshot, or at end of day? |
Why an overnight position changes the result
An open position can cross the reset boundary even when no new order is placed. If the provider re-establishes the daily reference while the trade is still open, the floating P/L must be evaluated against the new day's allowance.
That is the case a daily-bar backtest can hide. A daily bar has one date label; the rule has a timestamp. A system that holds through the reset needs intraday equity marks on both sides of that timestamp. If the data only gives an end-of-day balance, the test cannot establish whether a floating drawdown breached in the middle.
The same issue applies to costs. A trade list with entry and exit profit is not necessarily an equity ledger. Where the rule counts commissions, swap, or floating P/L, the simulation needs them at the point the rule checks them—not merely in a final net-profit total.
Build the reset into the backtest ledger
The clean implementation is a separate daily-rule ledger alongside the normal balance curve. It should never be inferred afterwards from monthly returns or from maximum drawdown.
Use the firm's clock, not your computer's clock
Store every event in a known timezone, then convert it to the provider's stated reset timezone. This is especially important where daylight-saving changes alter the relationship between your local time, broker server time, and the rule's clock. The practical test is simple: can you point to the exact timestamp at which the ledger took its new reference?
Snapshot the reference before evaluating the new day
At each reset, save the value the rule calls for. Do not substitute closing balance because it is convenient. If the rule says a prior balance, record that; if it says equity, record equity. The two are not interchangeable when trades remain open.
Mark equity whenever the rule could be breached
Revalue open positions at a frequency that can see the strategy's intraday adverse move. A test that only checks at bar close may miss a temporary breach that a continuously monitored account would not ignore. The right resolution depends on the strategy, the instruments, and the provider's enforcement method; it is a limitation to disclose, not a gap to wave away.
Preserve the breach even if the trade later recovers
The ledger needs a permanent breach flag and the timestamp that triggered it. A later recovery does not make a previous rule violation disappear. This is why a final equity curve is evidence of neither compliance nor non-compliance by itself.
Here is the logic in plain pseudocode:
at each reset:
reference = value required by the current rule
daily_floor = calculate_floor(reference, allowance)
for each equity mark until the next reset:
equity = balance + floating_pnl - counted_costs
if equity < daily_floor:
record_breach(timestamp, equity, daily_floor)The details inside calculate_floor belong to the particular firm's published rule. Do not import a familiar formula from another account type just because the phrase “daily loss” looks the same.
Test the awkward timestamps deliberately
A robust test set contains more than ordinary trading days. Force the conditions most likely to expose a reset bug:
- A position still open immediately before and after the reset.
- A floating loss that is acceptable before reset but not after it.
- A realised loss just before the reset and a different adverse move just after it.
- A commission or swap posting near the boundary, where the published rule counts it.
- A daylight-saving transition in the rule timezone.
- No trades on the new day, but an inherited open position that still moves equity.
This is not a hunt for a prettier equity curve. It is contract testing for the rule that determines whether the account remains eligible. The same discipline matters when testing daylight-saving time in cTrader backtests: a strategy can be logically unchanged while its operational clock is wrong.
Do not confuse total drawdown with a daily-rule test
Maximum drawdown is useful, but it answers a different question. It describes a peak-to-trough decline across the whole sample; a daily-loss rule compares equity with a specific reference inside a recurring time window.
A strategy can therefore show a tolerable overall drawdown and still fail the daily rule on one concentrated session. It can also have a rough multi-day decline without breaching any daily floor. You need both measurements, each calculated under the account's actual definitions. The distinction between daily loss and maximum loss is the starting point; the reset ledger is how you test the daily side rather than merely describe it.
realbacktesting's methodology and reproducibility standard is built around checking the conditions behind a result, including costs and the path rather than just the endpoint. For a system intended for prop-account constraints, the relevant context is the funding model. Neither page removes uncertainty: a buyer still needs to rerun a backtest with the current account rules and their own broker conditions.
Frequently asked
Can a backtest use calendar days for a prop-firm daily loss rule?
Only if the provider's reset time and timezone make those calendar days identical to the rule's trading days. Otherwise, a calendar grouping can put losses on the wrong side of the reset.
Does an open trade matter at the daily reset?
It can. FTMO's current Maximum Daily Loss page says its calculation includes floating P/L, so an open position can affect the result immediately after its midnight CE(S)T reset. Other providers may define the calculation differently; verify their current rule.
Is maximum drawdown enough for a prop-firm backtest?
No. Maximum drawdown measures the largest decline across the sample. A daily-loss rule needs a separate sequence of reset references and intraday equity checks.
What should a daily-reset test report?
It should report the rule version, reset timezone, reference definition, equity components, valuation frequency, and every breach timestamp. Without those inputs, a pass claim cannot be reproduced.
The stubborn takeaway is simple: if a backtest does not know when the prop-firm day begins, it does not know whether the account survived it.