Engineering notes

Engineering note · Position sizing checks

MT5 Position Sizing: Check the Cash Risk Before the Backtest

A backtest can compare the wrong position sizes very consistently. Before changing the strategy or interpreting a return chart, check whether one proposed trade actually matches the cash-risk rule in the brief. Keep sizing, margin and execution as separate questions.

  1. 01Freeze one example
  2. 02Record the raw size
  3. 03Check the allowed volume
  4. 04Compare cash exposure
A proposed diagnostic sequence for a sizing review. No customer account or strategy was tested for this article.

Choose one trade before running another matrix

Start with a single declared direction, symbol, entry price and stop price. Record the account currency and the exact definition of the cash budget. Does the rule use balance, equity or a fixed amount? At what moment is that value read? An input called risk percent does not answer those questions.

Keep the strategy signal unchanged during this check. Otherwise a different entry, stop or set of accepted trades can hide the sizing defect. The first useful result is a trace that explains one requested volume, not another table of aggregate returns.

A recent public MT5 discussion raised a possible units mismatch in lot sizing. That is a reason to inspect the calculation path, not proof of the cause. Without the relevant source and a reproducible example, the diagnosis remains open.

Make every unit visible

A useful debug record names the unit beside each value. Keep price distance, point count, tick size, lot volume and account-currency exposure in separate fields. Do not label all of them distance or risk. The developer should be able to trace where a price difference becomes a volume request.

Record the exact symbol, including any broker suffix. Retain the relevant symbol specification with the example. In MQL5, point size, trade tick size and volume step are different properties. Treating one as another can produce a plausible-looking number that does not represent the requested trade.

Keep the raw calculated volume and the normalized volume side by side. A format conversion that only changes displayed decimals is different from enforcing the allowed volume increment. Explain the rounding policy in the brief rather than hiding it in a utility function.

  • Intent: cash budget, its currency and its reference timestamp.
  • Prices: direction, entry, stop and source of each price.
  • Volume: raw request, normalized request and any cap applied.
  • Outcome: estimated price loss, margin check and explicit failure reason.

Estimate the price loss from the proposed volume

OrderCalcProfit estimates the result of a specified buy or sell operation in the current account currency. Supply the proposed volume, entry and stop as the close price. Check that the call succeeds and that the result has the expected sign before using it. A failed estimate must not be treated as zero exposure.

Compare the magnitude of that estimate with the declared price-risk budget after normalization. Keep transaction costs and adverse execution assumptions explicit; this estimate is not a promise that a stop will fill at its requested price or that total loss will equal the estimate.

For a historical sizing audit, retain the original symbol and conversion context. A fresh estimate under current market conditions is not automatically a reconstruction of the historical account environment. Label it as a current diagnostic unless the historical inputs have been established.

Do not silently raise a small request to the minimum

The allowed volume range and increment constrain what the EA can request. If the smallest permitted volume would exceed the agreed cash budget, choose an explicit outcome. One reviewable policy is to skip the entry and log why. Silently raising volume to the minimum changes the commercial specification of the bot.

The same trace should explain maximum-volume clipping and any aggregate exposure limit. A capped request is not the original request. Keep the reason visible so a backtest comparison does not attribute every change to strategy quality.

Test the exact boundaries rather than only a convenient middle case. Include a request below the minimum and one that needs normalization. The expected result comes from the agreed rule, not from whichever number the implementation currently returns.

Margin acceptance is a separate gate

OrderCalcMargin estimates the margin for a proposed operation; its reference states that the calculation does not account for current pending orders and open positions. That makes it useful context, not a substitute for the complete account and order checks.

Keep a rejected request distinct from a resized request. If a test changes account settings and one run admits a different set of trades, the return comparison now contains a selection difference as well as any sizing difference. Log those outcomes before interpreting the chart.

A useful repair handoff includes the original failing example, the changed source and the same examples rerun under named conditions. The checks below are a proposed specification, not evidence that an EA has passed. Correct sizing alone does not establish a profitable strategy.

Three acceptance checks

Proposed tests, not executed customer results. Record actual outcomes separately.

One fixed entry and stop

Input: Use a frozen symbol specification, direction, account-currency budget and price pair.

Expected: The trace explains raw and normalized volume. The successful price-loss estimate meets the agreed budget and rounding policy.

Below the allowed minimum

Input: Use an intended size below the symbol minimum under the same risk policy.

Expected: The EA follows the agreed skip or rejection outcome. It never silently increases exposure beyond that policy.

Unavailable estimate or rejected request

Input: Make a required calculation fail, then separately test a valid estimate with an inadmissible order.

Expected: Each case records its own reason. Unknown exposure is not zero, and a rejected order is not reported as an executed trade.

Sources and related guides

For your own brief, write the starting state, expected behavior and evidence for each case. The free Bot Blueprint gives you a place to collect those requirements.

Trading risk disclosure

Futures and forex trading contains substantial risk and is not for every investor. An investor could potentially lose all or more than the initial investment. Risk capital is money that can be lost without jeopardizing one's financial security or lifestyle. Only risk capital should be used for trading, and only those with sufficient risk capital should consider trading. Past performance is not necessarily indicative of future results.

Hypothetical performance disclosure

Hypothetical performance results have many inherent limitations. No representation is being made that any account will or is likely to achieve profits or losses similar to those shown. There are frequently sharp differences between hypothetical performance results and the actual results subsequently achieved by any particular trading program. Hypothetical results are generally prepared with the benefit of hindsight, do not involve financial risk, and cannot completely account for the impact of financial risk in actual trading. Market conditions, the ability to withstand losses, and adherence to a trading program can all materially affect actual results.

NinjaTrader trademark disclosure

NinjaTrader® is a registered trademark of NinjaTrader Group, LLC. No NinjaTrader company has any affiliation with the owner, developer, or provider of the products or services described herein, or any interest, ownership or otherwise, in any such product or service, or endorses, recommends or approves any such product or service.

Testimonials, when shown, may not represent the experience of other clients and are not a guarantee of future performance or success. Virtual-currency trading carries additional risks. See the CFTC customer advisories. Read the full financial risk disclaimer.