Build a backtest you can question: samples, exits, costs and stability

Start a backtest with a question that can receive an unwelcome answer. Our proposed question is: “Under these recorded assumptions, does this alert deserve another stage of investigation?” Write that question before opening the results screen. This article offers our proposed educational workflow, rather than a forecast, an asset selection method or a recommendation to place trades.

The English MaxData backtest guide describes historical trigger counts and average and median price changes before and after an alert. Those are the documented outputs we use as the starting point. Backtests guide.

Write a research brief before configuring exits

Our proposed research brief has six entries: the hypothesis, the instrument, the observation unit, the data window, the evaluation rule and the rejection condition. Keep each entry specific enough that another reader could identify which experiment you intended to run.

For an illustrative exercise, write: “When conditions A and B occur, examine the following four hours of price observations using a fixed entry convention.” This is deliberately incomplete until you define A, B and the entry convention. It is a research template, not a trading signal. Add a competing interpretation: “Comparable windows without the alert may show a similar pattern.” Treat that as a question to investigate.

The Pro Alerts guide distinguishes a single-condition Alert from a Pro Alert combining several conditions. It describes a window for satisfying the conditions, a sleep period after triggering and selectable data sources including open, close, minimum, maximum and average. Pro Alerts guide.

In our workflow, copy these settings into the brief. Also record whether a condition starts being satisfied, remains satisfied or stops being satisfied at the chosen trigger. Give the configuration a version number. Any subsequent change belongs in a new version, with a reason and a record of which results you had already seen.

Make the sample auditable

Our proposed data checklist asks you to record the provider, venue, trading pair, market type, quote currency, timezone and date range. For every input metric, attach its definition and source. Specify the price interval, the observation horizon and the typical publication delay, with the evidence used to establish that delay.

If delay is unknown, write “not established”. Our proposed acceptance rule is to leave timing validity unresolved until the availability assumption has been checked. For the exercise in this article, use five-minute observations and a four-hour horizon as explicit fictional design choices. Neither setting is presented as an optimal interval.

Choose what counts as one observation. You might register every trigger, or allow only one observation during an already open analysis window. State your convention before collecting the sample. Record excluded events, missing data and the counts before and after exclusions. Do not silently replace a missing observation with a favourable one.

Divide the historical range into chronological development, checking and final-evaluation segments. Set their boundaries in advance. We propose no universal minimum number of trades: instead, disclose the count in each segment and define your required sample before running the experiment. If that requirement is unmet, use the status “inconclusive”.

The English guide includes selecting a backtest period and reviewing historical trigger frequency among its steps. Backtest procedure. Our proposed extension is to preserve the period and count alongside every exported result, rather than relying on a screenshot of the headline number.

Separate the event chart from the exit model

The English guide describes two result lines: average price change and median price change before and after triggering. It also states that backtesting can use a single condition or several conditions simultaneously. Documented event analysis.

Our proposed reading convention: first describe the event chart without assigning a position. Record the historical window, trigger count, elapsed time on the horizontal axis and the two displayed summaries. In a separate section, describe how your hypothetical position enters and exits. Keep “price behaviour around events” and “simulated portfolio result” as distinct report fields.

The Polish MaxData backtest documentation describes a time-based portfolio that exits after a specified duration. It also describes a TP/SL portfolio with take-profit and stop-loss thresholds and a time exit when neither threshold is reached. Documented exit models.

Our proposed exit specification includes the reference price, threshold percentages, start of the holding clock and the handling of an observation interval containing both exit levels. If the order of threshold touches is unestablished, mark the event as ambiguous. Document alternative resolutions separately rather than concealing the choice inside a default setting.

For a comparison exercise, retain the same event list, entry convention and cost assumptions across the two exit models. Decide beforehand which report fields you will compare. Do not rename the winning historical configuration “the expected result”. Our publication convention reserves historical labels for historical outputs.

Inspect the path, not just the endpoint

The Polish documentation describes an equity curve compared with the asset or BTC, maximum drawdown and a heatmap of outcomes for different TP/SL settings. Backtest report components.

Our proposed drawdown convention is to report the decline from a preceding equity peak to a subsequent trough in the simulated path. State whether equity includes open-position valuations or only closed trades. Attach the peak and trough dates, and record a return to the preceding peak only if it occurs within the observed sample.

For stability, prepare a worksheet of questions. Does each chronological segment tell a similar story? What do adjacent TP/SL settings show? What does the report look like without its best event? Are the benchmark and strategy evaluated over matching dates with declared valuation conventions?

Treat these as checks to complete, not proof that a strategy will behave similarly elsewhere. Our proposed heatmap annotation marks the selected cell and its neighbours, then records their values without a “safe” label. If an additional score is used, request its definition, units and calculation method before making it an acceptance criterion.

Write down alternative interpretations. For example, ask whether the chosen benchmark comparison explains the result, whether a small group of events dominates it or whether the selected period is doing most of the work. Keep these as unresolved questions until the planned comparisons have been completed.

Write an execution and cost ledger

The Polish backtest guide lists fees, slippage, execution differences and use of a different market, such as spot versus perpetual, as possible explanations for discrepancies between historical tests and live results. Execution limitations.

Our proposed ledger separates entry fees, exit fees, spread assumptions, slippage assumptions and any applicable holding costs. Next to each value, identify its evidence or mark it “scenario assumption”. Specify which costs are already included in the execution-price model so that the report does not count them again.

Create a baseline scenario and a scenario with larger assumed costs. These names describe your experimental choices; do not call either scenario realistic without support. Include hypothetical order size, the data used to examine liquidity and your convention for partial or absent fills. Where execution cannot be checked, our proposed status is “execution unverified”.

Also specify the interval between trigger and hypothetical entry. Preselect any delay variants before evaluating them. Preserve the same event list when comparing those variants, and record exclusions separately. End the ledger with a concrete evidence request: what information is missing, who supplies it and which conclusion remains unresolved without it?

Keep an experiment log and a stopping rule

Our proposed convention for overfitting uses the term as a working label for choosing parameters to fit results you have already inspected. Maintain a log of every tested combination, including rejected variants. Record when the hypothesis, thresholds or acceptance rule changed. Do not make the experiment history disappear when a preferred configuration emerges.

For cognitive-bias checks, use three editorial questions: “Have I retained unfavourable results?”, “Did I change the success criterion after seeing the outcome?” and “Am I judging the final segment using the rule I wrote beforehand?”. This is our proposed review checklist, with no claim that it eliminates bias.

Assign one of three research statuses: rejected, inconclusive or selected for further observation. Link rejection to a recorded condition. Link an inconclusive status to missing evidence or an unmet sample requirement. For further observation, freeze the configuration and set a review date, an event log and explicit criteria for reopening the research question.

Our proposed invalidation conditions include a changed data definition, an unverified publication timestamp, unsupported execution assumptions or a breach of the original test protocol. A status change should trigger documentation and review under this workflow; it is not an automatic instruction to trade.

MaxData Help Hub presents MaxData Info Bot as an assistant for questions about MaxData. Help Hub. For a product question, supply the field name, configuration version and behaviour you are trying to understand. Keep that request separate from your own research conclusion. Product CTA: creating an account or asking the agent is an invitation to explore the tool, not an endorsement of a historical result.