Minimum trading days are a prop-firm account requirement that asks for activity across separate trading days before an evaluation can be completed. A backtest can clear a profit target without satisfying that requirement, so the rule belongs in the account ledger, not in the strategy's performance claim.
That distinction is easy to miss because an equity curve only records money and time. The evaluation also has a calendar. A system that earns its historical return in a short cluster of trades may be perfectly valid as a strategy and still be a poor match for a programme that requires qualifying activity on separate days.
Minimum trading days are not a trade-frequency target
A minimum-trading-days rule measures qualifying calendar days, not whether a strategy is busy. Its exact definition belongs to the prop firm: the firm decides what counts as a trading day, when its clock resets, and whether open or closed activity matters. Those terms can change, so preserve the rule page used for the test rather than reconstructing it later.
The backtest question is narrower: if the historical trades were run through that declared rule, would the account path have completed the day requirement without changing the strategy?
This is not a reason to make a system trade more often. Adding low-quality trades to create calendar marks changes the system and can add cost and risk. It may satisfy an administrative condition in a toy calculation while making the underlying evidence worse.
Add a calendar ledger to the account simulation
A conventional trade log has timestamps, entries, exits, realised profit and floating equity. For a prop-firm test, add an account-level calendar ledger beside it. The ledger should be calculated from the same timestamps and rule definitions as the rest of the test.
| Ledger field | What it records | Why it matters |
|---|---|---|
| Rule source | The firm's page and version used for the run | Lets another reader check the current terms and the historical assumption |
| Account time zone | The clock used to group activity into days | Prevents one session being assigned to different dates in different reports |
| Qualifying-day rule | The explicit condition that marks a day | Stops a vague label from hiding a rule mismatch |
| Qualifying dates | Every date that passed that condition | Shows whether activity was genuinely distributed |
| Target date | The date the profit condition was first met | Separates a strategy result from an account-completion result |
| Completion date | The first date all declared conditions were met | Makes the waiting period visible rather than implied |
The important word is explicit. “Active for several days” is not a reproducible result. A reader needs the time zone, the day boundary and the qualifying condition. This is the same discipline needed when testing daylight-saving-time changes: a clock definition is part of the trading rule once it can alter the recorded outcome.
Test the path after the target is reached
The awkward cases begin when the return condition is met before the calendar condition. The backtest must then continue using the original entry, exit and sizing rules until the account condition is complete. Stopping the report at the target silently assumes the remaining days do not matter.
They do. Further trades can add profit, give it back, create floating loss or trigger a different account constraint. If the strategy normally has no signal after reaching the target, that is also a result: the historical path may wait for later qualifying activity, or it may never meet the declared condition. Neither outcome justifies inventing a filler trade.
Record both views of the same run:
| Report | Question it answers |
|---|---|
| Strategy result | What did the unchanged rules produce over the chosen sample? |
| Account-path result | Did that path meet every declared programme condition, including the calendar rule? |
Keeping them separate prevents a familiar mistake. A profitable strategy result is evidence about the historical rules. It is not automatically evidence that a particular prop-firm evaluation would have been completed.
Do not optimise the calendar after seeing the curve
Minimum trading days can tempt a researcher into a quiet form of curve fitting. The pattern is simple: inspect the dates of the profitable run, then alter session filters, holding periods or entry thresholds until activity happens to land on more qualifying days.
Those changes may be legitimate strategy hypotheses. They are not legitimate merely because they repair an account report. Treat each as a new rule, state why it should exist, include its costs and test it on data not used to choose it. The acceptance criteria for a prop backtest should say in advance whether calendar completion is a requirement, a diagnostic or irrelevant to the intended programme.
Trade frequency is a useful companion metric, but it does not answer this question by itself. A burst of many trades can occur on one date. A sparse strategy can meet a day rule across a broad span. The trade-frequency check describes activity; the calendar ledger describes whether that activity maps to a particular account condition.
The rule belongs beside drawdown, not above it
An evaluation is constrained by more than a calendar. The current firm rulebook governs how daily loss, overall loss, open positions and qualifying activity are treated. A test that tracks only the calendar can be as misleading as one that tracks only final profit.
That is why the funding model keeps an account path beside its constraints. It is also why realbacktesting's published methodology makes the data, execution, costs and validation assumptions inspectable. realbacktesting is a trading-software studio for cTrader built around results a trader can reproduce and challenge, not a claim that a backtest predicts a funded outcome.
The limitation is plain. Historical timestamps cannot prove that a future programme will use the same definition, nor can they predict future signals. They can show whether a stated set of rules was tested against a stated calendar condition. For a live evaluation, the prop firm's current documentation remains the authority.
Frequently asked
Does a minimum-trading-days rule make a strategy better?
No. It is an account condition, not a measure of expectancy or robustness. A strategy should be judged on its declared rules and evidence; the calendar ledger then shows whether it fits a particular programme.
Can I add small trades to satisfy minimum trading days in a backtest?
You can model those trades, but they are a separate strategy rule with their own cost, execution and risk. Calling them administrative while excluding their consequences makes the test less honest.
Should the backtest stop when it reaches the profit target?
Not if a declared account condition remains unmet. Continue the unchanged rules until the path completes the condition or the sample ends, then report that result separately from the strategy's return.
The stubborn takeaway: a minimum-days rule is not a reason to manufacture trades; it is a reason to test the account calendar as honestly as the equity curve.