Audit open-interest data before interpreting it · 3 / 5
Open interest backtests: handle delayed data and revisions
A timestamp saying what a record describes is not proof of when you could use it. Preserve availability and revision history before replaying a threshold decision.
Athenum8 minUpdated:
At 10:00:05, the future record is unavailable
A's new value is available, but B's new value is not. Pairing A=110 with the last B=200 produces 310 across different measurement times. That is a mixed-age estimate, not the required synchronized pair. The rule has an unavailable input, rather than a valid negative signal. A backtest that uses B=230 because its measurement label says 10:00 has looked ahead by 15 seconds relative to this decision. Sorting solely by measurement time conceals that mistake.
At 10:00:25, the initially received pair qualifies
Both initial 10:00 measurements have arrived. Their total is 340, a rise of 40/300 = 13.333…%, so the illustrative threshold is met. This does not prove a trade could execute at the earlier measurement-time price. An execution model needs later available quotes, size, costs and its own timing assumptions.
At 10:00:45, a revision changes the reconstructed observation
The corrected B value is now available. The corrected pair totals 325, an increase of 25/300 = 8.333…%, below the threshold. A database that retains only the final corrected record would retrospectively erase the earlier flag. It could then make a real-time decision look impossible even though it was consistent with the information received at 10:00:25.
Keep both versions with their availability times for an as-observed replay. A final-data analysis is a different valid question, but it must be labelled as such. Do not silently compare an as-observed strategy with a revised-data benchmark and interpret the difference as trading skill.
Task and observation ledger
Distinguish the time a measurement describes from the time the research system could use it. This synthetic two-venue example uses comparable one-sided quantity units and UTC clocks. Arrival time means the complete record has been received and is usable by the decision process. Any additional processing delay would have to be added in a real replay.
The hypothetical review rule requires a synchronized 10:00 pair and flags an increase of at least 10% from the synchronized 09:55 pair. This is an audit trigger, not an instruction to trade or a claim of predictive performance. Baseline OI is 300. The numeric threshold is 330.
| Venue | Measurement time | Usable arrival time | OI | Version |
|---|---|---|---|---|
| A | 09:55:00 | 09:55:02 | 100 | initial |
| B | 09:55:00 | 09:55:03 | 200 | initial |
| A | 10:00:00 | 10:00:02 | 110 | initial |
| B | 10:00:00 | 10:00:20 | 230 | initial |
| B | 10:00:00 | 10:00:40 | 215 | correction |
Open full-size diagram- 10:00:05: synchronized pair unavailable
- 10:00:25: initial total 340; threshold met
- 10:00:45: corrected total 325; threshold not met
Synthetic UTC measurement, arrival and correction ledger. Decision-time information changes as records arrive. The illustrative threshold is 330. These are audit outcomes, not executed trades or measured vendor latencies.
The horizontal axis shows usable arrival time, in seconds after 10:00:00 UTC. Every new record describes the same 10:00 measurement. Lines show available versions, not a continuous market path. A question mark means the synchronized input is unavailable, not zero or a failed threshold test.
B = 230: initial. B = 215: correction.
- 10:00:05: synchronized pair unavailable
- 10:00:25: initial total 340; threshold met
- 10:00:45: corrected total 325; threshold not met
Do not repair timing with future records
Forward-filling B=200 before its new arrival hides staleness; backfilling B=230 before its arrival leaks future information. Applying the correction before 10:00:40 leaks a later version. These are three separate errors even when they are all implemented as a timestamp join.
Before acting
- Retain measurement time and usable arrival time separately.
- Select only records available by the decision time.
- Preserve corrections and reliable version ordering.
- Label mixed-age estimates instead of calling them synchronized data.
- Keep signal availability separate from executable fill assumptions.
Check your understanding
Change only B's initial 10:00 arrival to 10:00:50, leaving its correction arrival at 10:00:40. What is known at 10:00:25 and 10:00:45? Should the older initial version arriving at 10:00:50 overwrite the correction?
Show the explained answer
At 10:00:25 the required B measurement is still unavailable. At 10:00:45 the correction supplies B=215, so the synchronized total is 325 and the flag is false. A reliably versioned correction must not be overwritten by a later-arriving older version. Without a trustworthy version/correction ordering contract, quarantine the conflict rather than assume that arrival order proves which value is authoritative. Real provider fields and revision semantics need their own verification; this toy ledger does not assert Bybit exposes these exact version fields or timings.