ORSTAC
Backtests are only as trustworthy as the ticks they consume. Before you trust a single equity curve on Deriv synthetic indices, you need to know whether your historical tick file is complete, aligned, clean, and consistent with the spreads the platform actually quoted. This article gives a practical checklist for that audit: gaps, timestamp alignment, outlier ticks, and spread consistency, with worked arithmetic you can reproduce. It is written for people who build or run automated strategies on DBot and the Deriv API, and it assumes you are skeptical of your own data.
Trading involves significant risk and you can lose your entire stake. Test every strategy on a demo account first.
Why a tick audit comes before any backtest
A backtest is a filter, not proof. It can reject a bad idea cheaply; it cannot certify a good one. That asymmetry only holds if the input data is sound. Synthetic indices are generated continuously, so a missing hour is not a market closure, it is a hole in your sample. A hole silently changes trade counts, drawdowns, and expectancy.
The audit is also cheap relative to the cost of a wrong conclusion. You are checking four properties: completeness (no unexplained gaps), alignment (timestamps in one consistent frame), sanity (no impossible or duplicated ticks), and consistency (quotes and spreads match the contract you intend to trade). Do this once per dataset, record the results, and version the file. No data, no claim.
Gaps and completeness
Start by counting. For a given symbol and period, compute the expected number of ticks from the observed median inter-tick interval, then compare with the actual count.
Worked example. Suppose you download one hour of ticks for a synthetic index and the median interval between ticks is 2 seconds. Expected ticks = 3600 / 2 = 1800. If your file contains 1710 ticks, the shortfall is 1800 − 1710 = 90 ticks, or 90 / 1800 = 5.0% of the expected count. That is a flag, not a verdict: the median interval itself is an estimate, so treat the result as a prompt to inspect where the missing ticks fall.
Then locate the gaps. Sort by timestamp, compute successive differences, and list every interval above a threshold you set in advance (for example, ten times the median). Classify each: platform maintenance, your own connection drop, or an unexplained hole. Only the third category should worry you, and it should be documented. If you aggregate ticks into candles for a DBot strategy, a gap can merge two candles into one and change every signal after it.
A minimal check, expressed as pseudo-code:
sort ticks by timestamp
median_dt = median(diff(timestamps))
expected = (end - start) / median_dt
report(expected, count(ticks), expected - count(ticks))
for each consecutive pair:
if dt > 10 * median_dt: log gap(start, end, dt)
flag duplicate timestampsRecord the output alongside the dataset. When you later compare in-sample and out-of-sample results, you want to know whether the two periods had comparable coverage. A backtest over a period with 5% missing ticks and one over a complete period are not the same experiment.
Timestamp alignment
Timestamp errors are quieter than gaps and often more damaging. Three questions decide alignment.
First, what does the timestamp represent: the tick’s generation time at the source, or the time your client received it? These differ by network latency, and latency is not constant. If you mix sources, you mix frames.
Second, what unit and epoch? Deriv API timestamps are Unix-style seconds; some exports carry milliseconds, and a file that mixes the two will sort into nonsense. Check the magnitude: a ten-digit value is seconds, a thirteen-digit value is milliseconds. Convert once, at ingest, and store the result in a single documented frame.
Third, how do you handle ties? Two ticks with the same second are normal at high tick rates. Your backtester must define an order (for example, stable sort by arrival sequence) and apply it identically in every run. If entry and exit logic both read the same timestamp, decide explicitly whether a tick can fill both sides of a trade.
For Multipliers, this matters differently: stop loss and take profit by price exist only for Multipliers, so tick ordering determines which level is hit first within a bar. For fixed-stake contracts such as Rise/Fall and Digits, risk is controlled by stake, duration and session limits, not by a price stop, so alignment errors tend to change entry timing and contract counts rather than stop behaviour. Either way, document the frame and the tie rule in your test notes.
Outlier ticks and duplicates
Outliers in synthetic index data are usually one of three things: a genuine fast move, a bad print, or a duplicated record. You cannot tell which by looking at one tick, so use rules you fixed before inspecting the data.
Practical checks:
- Duplicates: identical symbol, timestamp and price appearing more than once. Count them; if the count is material, deduplicate and note it.
- Impossible jumps: a price change larger than any move you consider plausible for the symbol within one tick interval. List them with context rather than deleting them silently.
- Zero or negative prices, and prices with more decimal places than the symbol quotes. These are almost always parsing errors.
- Stale runs: long sequences of identical prices where the symbol normally moves every tick.
The discipline is to write the rules first, apply them mechanically, and keep a log of every removed or modified record. Deleting outliers after seeing that they hurt your backtest is how a filter becomes a fiction. If you remove 0.1% of ticks, say so; if that 0.1% sits inside your largest drawdown, the result is fragile and should be reported as such.
Spread consistency
Spread consistency is where many Deriv backtests quietly diverge from live behaviour. Your dataset must match the contract you intend to trade. A synthetic index tick feed is not automatically the same quote basis as the payout your bot receives.
For Rise/Fall and Digits, the relevant economics are the stake, the payout percentage and the contract duration. A backtest that assumes a payout of, say, 95% when the platform quoted 92% at that duration will overstate expectancy. Worked example: a stake of 1.00 at a 95% payout returns 1.95 on a win, so net profit is 0.95; at 92% it returns 1.92, net profit 0.92. On a strategy with 100 wins, that difference is 100 × (0.95 − 0.92) = 3.00 in overstated profit, before any losses. Small per-contract differences compound across a sample.
For Multipliers, spread and commission enter the P&L directly, so your tick file should reflect the quoted spread at the times you trade, not a constant you assumed. If the platform’s spread varies with settings or volatility, and it may, say so in your notes and test a range rather than a single value.
Also check that your dataset’s symbol and granularity match what the bot will subscribe to via the Deriv API documentation and the official Deriv API libraries. A mismatch between the historical file and the live subscription is a silent source of error that no amount of sample size will fix.
Limitations
This checklist does not tell you whether a strategy is profitable, and it cannot. It does not reconstruct quotes you never recorded, and it cannot verify that historical payouts match future ones; payout percentages are platform settings and can change. It does not model execution latency, requotes, or the behavioural gap between demo and real trading. A clean dataset removes one class of error; it leaves sample size, out-of-sample testing, and the number of configurations tried as separate obligations. Report all three, and treat any backtest as a hypothesis generator rather than evidence of edge.
Frequently Asked Questions
How many ticks do I need before a backtest means anything? More than you think, and the honest answer is that sample size depends on the strategy’s trade frequency and the size of the effect you are trying to detect. A practical rule is to require enough trades that a handful of outliers cannot flip the sign of your expectancy, and to confirm the result on a separate out-of-sample period.
Should I delete outlier ticks from my dataset? Only using rules written before you inspect the data, and only with a log of what was removed and why. Silent deletion is data manipulation; documented cleaning is part of the audit.
Does a clean tick file guarantee my live results will match the backtest? No. It removes data errors, not execution differences, payout changes, or the behavioural differences between demo and real trading. Demo first, minimum stake after a recorded demo sample, and limits set in the bot itself.
Key Takeaways
- Audit four properties before backtesting: gaps, timestamp alignment, outlier ticks, and spread consistency.
- Compute expected tick counts from the median interval and log every gap above a pre-set threshold.
- Convert timestamps to one documented frame and define a tie rule for same-second ticks.
- Match payout and spread assumptions to the contract you will actually trade; small per-contract differences compound.
- A backtest is a filter, not proof: large samples, out-of-sample tests, and a count of configurations tried.
If you want a starting point, the ORSTAC repository hosts open-source bots for Deriv, the platform used here, and a free demo account is available to test them. Bring your audit logs and your questions to the ORSTAC Telegram group and discuss them with the community.
Trading involves significant risk and you can lose your entire stake. Test every strategy on a demo account first.