Open-Interest-Daten vor der Interpretation prüfen · 3 / 5
Open-Interest-Backtests: verspätete Daten und Korrekturen
Ein Zeitstempel, der den Bezugszeitpunkt eines Datensatzes nennt, beweist nicht, wann du ihn verwenden konntest. Bewahre Verfügbarkeit und Änderungshistorie auf, bevor du eine Schwellenentscheidung nachspielst.
Athenum8 Min.Aktualisiert:
Um 10:00:05 ist der spätere Datensatz noch nicht verfügbar
Der neue Wert von A liegt vor, der neue Wert von B dagegen nicht. A=110 zusammen mit dem letzten B=200 ergibt 310 aus unterschiedlichen Messzeitpunkten. Das ist eine Schätzung mit unterschiedlich alten Werten, nicht das erforderliche synchronisierte Paar. Der Regel fehlt eine verfügbare Eingabe; es liegt kein gültiges negatives Signal vor. Ein Backtest, der B=230 verwendet, weil dessen Messzeit mit 10:00 angegeben ist, greift gegenüber dieser Entscheidung um 15 Sekunden vor. Eine Sortierung ausschließlich nach Messzeit verbirgt diesen Fehler.
Um 10:00:25 erfüllt das zunächst empfangene Paar die Bedingung
Beide ursprünglichen 10:00-Messwerte sind eingetroffen. Ihre Summe beträgt 340, ein Anstieg von 40/300 = 13,333…%; damit ist die beispielhafte Schwelle erreicht. Das beweist nicht, dass ein Trade zum früheren Preis des Messzeitpunkts ausführbar gewesen wäre. Ein Ausführungsmodell benötigt später verfügbare Quotes, Mengen, Kosten und eigene Annahmen zur zeitlichen Abfolge.
Um 10:00:45 verändert eine Revision die rekonstruierte Beobachtung
Der korrigierte Wert von B liegt jetzt vor. Das korrigierte Paar ergibt 325, einen Anstieg von 25/300 = 8,333…%, also weniger als die Schwelle. Eine Datenbank, die nur den endgültig korrigierten Datensatz behält, würde die frühere Markierung rückwirkend löschen. Dadurch könnte eine Echtzeitentscheidung unmöglich erscheinen, obwohl sie mit den um 10:00:25 empfangenen Informationen vereinbar war.
Bewahre für ein Nachspielen des damals beobachteten Zustands beide Versionen mit ihren Verfügbarkeitszeiten auf. Eine Auswertung endgültiger Daten beantwortet eine andere legitime Frage, muss aber entsprechend gekennzeichnet sein. Vergleiche nicht stillschweigend eine Strategie mit damaligem Informationsstand mit einem Benchmark aus revidierten Daten und deute den Unterschied als Trading-Können.
Aufgabe und Beobachtungsregister
Unterscheide den Zeitpunkt, den eine Messung beschreibt, von dem Zeitpunkt, zu dem das Forschungssystem sie verwenden konnte. Dieses künstliche Beispiel mit zwei Börsen verwendet vergleichbare einseitig gezählte Mengeneinheiten und UTC-Uhren. Ankunft bedeutet hier, dass der vollständige Datensatz empfangen wurde und dem Entscheidungsprozess zur Verfügung steht. Zusätzliche Verarbeitungsverzögerungen müssten bei einem realen Replay berücksichtigt werden.
Die hypothetische Prüfregel verlangt ein synchronisiertes 10:00-Paar und markiert einen Anstieg von mindestens 10% gegenüber dem synchronisierten 09:55-Paar. Das ist ein Prüfauslöser, keine Handelsanweisung oder Behauptung über Prognoseleistung. Das Ausgangs-OI beträgt 300. Die numerische Schwelle liegt bei 330.
| Börse | Messzeit | Nutzbare Ankunftszeit | OI | Version |
|---|---|---|---|---|
| A | 09:55:00 | 09:55:02 | 100 | Erstfassung |
| B | 09:55:00 | 09:55:03 | 200 | Erstfassung |
| A | 10:00:00 | 10:00:02 | 110 | Erstfassung |
| B | 10:00:00 | 10:00:20 | 230 | Erstfassung |
| B | 10:00:00 | 10:00:40 | 215 | Korrektur |
Diagramm vergrößern- 10:00:05: synchronisiertes Paar nicht verfügbar
- 10:00:25: ursprüngliche Summe 340; Schwelle erreicht
- 10:00:45: korrigierte Summe 325; Schwelle nicht erreicht
Künstliches UTC-Register für Messung, nutzbare Ankunft und Korrektur. Mit eintreffenden Datensätzen ändert sich der Informationsstand für Entscheidungen. Die beispielhafte Schwelle beträgt 330. Gezeigt werden Prüfergebnisse, keine ausgeführten Trades oder gemessenen Anbieterlatenzen.
Die waagerechte Achse zeigt die nutzbare Ankunftszeit in Sekunden nach 10:00:00 UTC. Jeder neue Datensatz beschreibt dieselbe 10:00-Messung. Linien zeigen verfügbare Versionen, keinen durchgehenden Marktverlauf. Das Fragezeichen bedeutet: synchronisierter Eingangswert nicht verfügbar, nicht null oder Schwelle verfehlt.
B = 230: Erstfassung. B = 215: Korrektur.
- 10:00:05: synchronisiertes Paar nicht verfügbar
- 10:00:25: ursprüngliche Summe 340; Schwelle erreicht
- 10:00:45: korrigierte Summe 325; Schwelle nicht erreicht
Zeitprobleme nicht mit zukünftigen Datensätzen reparieren
Das Fortschreiben von B=200 vor dem Eintreffen des neuen Werts verbirgt dessen Alter; das rückwirkende Einsetzen von B=230 vor seiner Ankunft schleust zukünftige Informationen ein. Wird die Korrektur vor 10:00:40 angewendet, wird eine spätere Version vorweggenommen. Das sind drei unterschiedliche Fehler, auch wenn alle als Verknüpfung anhand von Zeitstempeln implementiert werden.
Vor der Entscheidung
- Bewahre Messzeit und nutzbare Ankunftszeit getrennt auf.
- Wähle nur Datensätze aus, die bis zum Entscheidungszeitpunkt verfügbar waren.
- Erhalte Korrekturen und eine verlässliche Versionsreihenfolge.
- Kennzeichne Schätzungen mit unterschiedlich alten Werten statt sie synchronisierte Daten zu nennen.
- Trenne Signalverfügbarkeit von Annahmen über ausführbare Fills.
Prüfe dein Verständnis
Verschiebe ausschließlich die Ankunft von Bs ursprünglichem 10:00-Wert auf 10:00:50; seine Korrektur trifft weiterhin um 10:00:40 ein. Was ist um 10:00:25 und 10:00:45 bekannt? Soll die ältere Erstfassung, die um 10:00:50 eintrifft, die Korrektur überschreiben?
Lösung mit Erklärung anzeigen
Um 10:00:25 ist der erforderliche B-Messwert weiterhin nicht verfügbar. Um 10:00:45 liefert die Korrektur B=215; die synchronisierte Summe beträgt somit 325 und die Markierungsbedingung ist nicht erfüllt. Eine zuverlässig versionierte Korrektur darf nicht durch eine später eintreffende ältere Version überschrieben werden. Fehlt eine vertrauenswürdige Regel für die Reihenfolge von Versionen und Korrekturen, isoliere den Konflikt, statt aus der Ankunftsreihenfolge auf den maßgeblichen Wert zu schließen. Echte Anbieterfelder und Revisionsregeln müssen gesondert geprüft werden; dieses Modellregister behauptet nicht, dass Bybit genau diese Versionsfelder oder Zeitabläufe bereitstellt.