A cBot can calculate a sensible-looking risk amount while relying on a pip value that was fixed when the robot started. In a long cTrader backtest, that makes the intended cash risk a hypothesis to test, not a setting to take on faith.
The issue is narrow but consequential. A stop loss defines a price distance; a prop account fails on money and equity. Anything between those two quantities deserves an audit.
What pip value drift means
Pip value drift is the gap between the cash risk a sizing rule intends and the cash loss that its final volume and stop can represent as market and conversion conditions move. It is not a claim that every cTrader backtest is wrong, nor a prediction about a future fill.
The important implementation detail is documented by cTrader. Its Symbol.PipValue reference says the monetary value of one pip is set when a cBot starts and is not updated in real time. The same reference shows a sizing pattern that divides a balance-based risk amount by stop distance and PipValue.
That is a perfectly usable input when its limitation is understood. It becomes a quiet assumption when a report describes every trade as a fixed cash risk without checking the path between the initial value and each later order.
Why a fixed pip value can alter sizing
A fixed pip value matters only when the strategy uses it, directly or through a risk-sizing helper. If the account currency, the symbol's quote currency, or the conversion between them changes in relevance over the run, the sizing estimate can cease to be the same thing as current cash exposure.
The cTrader API is unusually clear about the broader limit. Its VolumeForProportionalRisk method says the calculated volume may be imprecise because the exact degree of risk depends on market movement and cannot be predicted. That caveat is not a defect to hide. It is the reason to record what the sizing code requested and what the trade actually risked.
This is not a reason to discard a strategy. It is a reason not to give the words "risk per trade" more precision than the test earned.
| Layer | What it tells you | What it does not prove |
|---|---|---|
| Intended risk | The amount the sizing rule asked to risk | The final cash loss of a later trade |
PipValue at cBot start | The static monetary pip input available to the code | A continuously refreshed conversion value |
| Final volume and stop | The order exposure the cBot submitted | That a live fill will occur at the stop price |
| Realised result | What happened in that tested path | Future performance or future execution |
Test the order path, not the label
A useful pip-value audit compares decisions through time. Do it in the same account currency, on the same symbol settings, and preserve the result with the backtest.
Log the inputs when the cBot starts
Record the account currency, symbol, PipValue, the sizing method, the intended risk input, and the volume step used by the cBot. Save the cTrader build and broker or server context too. Without that snapshot, a later reader cannot tell which static value informed the orders.
Inspect trades from different parts of the run
Choose stopped trades from early, middle, and late parts of the historical period. For each, retain the requested volume, accepted volume, stop distance, intended cash risk, and realised gross result if the stop was reached. A trade that exits before its stop is still useful for the order-path record, but it does not measure full stop risk.
Recalculate independently
Use the dated symbol contract and the relevant historical conversion information to rebuild the cash exposure of the final volume at each selected stop. Keep that calculation outside the sizing function you are testing. If the independent result differs materially from the stated risk, report the range or qualify the claim; do not massage the volume until the curve looks tidier.
Keep this separate from other backtest errors
Pip-value drift is not the same as slippage, spread, commission, or an invalid order. Those are separate execution questions, and each can change a result.
It also does not mean that every stop loss will realise its planned amount. A gap, a fast market, or liquidity can change an actual exit. The audit asks a smaller, answerable question: did the backtest's sizing logic describe the risk it was meant to describe under the recorded historical conditions?
That distinction matters in a prop context. The funding model puts the equity path beside account constraints, while the published methodology makes test assumptions available for inspection. A risk input belongs in that evidence trail, not in the marketing copy around a curve.
What realbacktesting makes checkable
realbacktesting is a trading-software studio for cTrader built around inspectable, reproducible tests. Its published cBot results are designed to be challenged in the buyer's own cTrader, with the relevant account and cost assumptions visible rather than implied.
That does not turn a backtest into a live record. It gives the reader a better question: can the risk-sizing path be reproduced, including the inputs that produced each volume? The same discipline applies when testing a cBot after symbol changes, because a changed contract can alter the relationship between a price-distance rule and its cash consequence.
Frequently asked
Does cTrader update PipValue while a cBot is running?
The current cTrader Symbol reference says PipValue is the monetary value of one pip when the cBot started and is not updated in real time. Check the current platform documentation and the installed build before relying on a different behaviour.
Does a static PipValue make a backtest useless?
No. It identifies a sizing assumption that may need measurement. A backtest can still be useful if it records the assumption, checks selected trades independently, and does not overstate fixed cash risk.
Can a proportional-risk method guarantee the final loss?
No. cTrader's documentation says its proportional-risk volume calculation can be imprecise because exact risk depends on market movement. A stop loss and a calculated volume are controls, not a guarantee of the exit amount.
What should a prop trader save with this test?
Save the account currency, symbol contract, cTrader build, start-time PipValue, requested and accepted volume, stop distance, and the independent calculation for the sampled trades. That record makes a risk claim reviewable after the curve has been generated.
The stubborn takeaway
If the cash-risk number matters to the account, test the number that each order could actually lose—not the one the cBot calculated at the start.