Automatische Datenvalidierung mit Expectation-Frameworks im Trading-Stack.
Marktdaten kommen selten so sauber an, wie ein Backtest sie braucht. In rohen Lieferungen stecken negative Volumina, fehlende Handelstage, doppelte Zeilen, plötzliche Dezimal-Verschiebungen und Werte, die physikalisch unmöglich sind. Wer solche Daten ungeprüft ins Modell schiebt, findet den Fehler im besten Fall im Backtest-Ergebnis wieder – im schlimmsten Fall erst im Live-Handel. Die unspektakuläre, aber wirkungsvolle Antwort darauf sind Expectation-Frameworks: Werkzeuge, mit denen man Erwartungen an Daten deklarativ formuliert – „Volumen ist nie negativ“, „jeder Handelstag ist vertreten“, „der Schlusskurs liegt zwischen Tagestief und Tageshoch“ – und automatisch gegen jede eingehende Lieferung prüft. Dieser Beitrag zeigt, welche Prüfungen sich für Marktdaten wirklich lohnen, wie man ein solches Framework in eine Trading-Pipeline einbaut, was an Aufwand und Nutzen realistisch ist – und wo automatische Validierung an ihre Grenzen stößt und menschliche Einschätzung nicht ersetzt.
Welche Datenfehler in Marktdaten typisch sind.
Bevor man validiert, lohnt der Blick auf die Fehlerklassen, die in der Praxis tatsächlich auftauchen. Sie sind erstaunlich wiederkehrend, egal von welchem Vendor die Daten stammen.
- Strukturelle Fehler: fehlende Handelstage, doppelte Zeilen, vertauschte Spalten, falsche Zeitzonen.
- Wertebereichsfehler: negative Preise oder Volumina, ein Schlusskurs außerhalb der Tagesspanne, Hoch unter Tief.
- Skalierungsfehler: ein Kurs plötzlich um den Faktor 10 oder 100 verschoben, weil sich ein Dezimaltrenner oder eine Einheit geändert hat.
- Stille Lücken: ein Feld, das ab einem bestimmten Datum nur noch Nullen oder NaN liefert, ohne dass der Rest der Datei auffällt.
Das Tückische: Viele dieser Fehler sehen in einer Tabelle harmlos aus und fallen erst auf, wenn eine Volatilitätsberechnung explodiert oder eine Strategie auf einem Phantom-Sprung handelt. Genau deshalb braucht es automatische, jede Lieferung treffende Prüfungen statt gelegentlicher Stichproben.
Was ein Expectation-Framework leistet.
Der Kerngedanke ist einfach: Statt Prüfcode in jeder Pipeline-Stufe von Hand zu schreiben, formuliert man Erwartungen deklarativ. Eine Expectation ist eine benannte, parametrisierte Behauptung über die Daten – etwa „Spalte volume enthält keine Werte unter null“ oder „Spalte timestamp enthält keine Duplikate“.
Frameworks wie Great Expectations bündeln solche Erwartungen zu einer Suite, prüfen sie gegen einen Datensatz und erzeugen einen strukturierten Report: Welche Erwartung wurde erfüllt, welche verletzt, wie viele Zeilen waren betroffen. Dieser Report ist menschenlesbar und maschinenauswertbar zugleich – man kann ihn anzeigen, aber auch eine Pipeline daran abbrechen lassen.
Der praktische Mehrwert liegt in drei Punkten: Die Prüfungen sind an einer Stelle dokumentiert statt über den Code verstreut, sie sind wiederverwendbar über mehrere Datenquellen, und sie erzeugen ein nachvollziehbares Protokoll darüber, dass die Daten geprüft wurden – was bei Audits und Fehleranalysen Gold wert ist.
Die Prüfungen, die sich für Marktdaten wirklich lohnen.
Nicht jede denkbare Prüfung bringt Nutzen. Erfahrungsgemäß deckt eine überschaubare Kernmenge den Großteil der real auftretenden Fehler ab:
| Prüfung | Fängt ab |
|---|---|
| volume >= 0, kein NaN | kaputte Volumenfelder |
| low <= open, close, high | OHLC-Inkonsistenzen |
| Zeitstempel eindeutig & lückenlos | Duplikate, fehlende Bars |
| Preis innerhalb plausibler Tagesbewegung | Fat-Finger-Prints, Sprünge |
| Spaltenanzahl & Typen stabil | Schema-Drift |
| Werteverteilung im erwarteten Korridor | Skalierungswechsel |
Die ersten vier sind harte, deterministische Regeln – sie sollten eine Pipeline hart abbrechen lassen. Die letzten beiden sind weicher und statistisch; sie eignen sich eher als Warnung, weil ein ungewöhnlicher, aber echter Markttag sie auslösen kann. Diese Unterscheidung zwischen harten Regeln und Warnungen ist entscheidend, sonst erzeugt das System Fehlalarme und verliert das Vertrauen des Teams.
Einbau in die Trading-Pipeline.
Der wirkungsvollste Ort für Validierung ist der Pipeline-Eingang: direkt nachdem die Rohdaten geladen, aber bevor sie transformiert, gejoint oder ins Feature-Set überführt werden. Fehlerhafte Daten sollen so früh wie möglich gestoppt werden, bevor sie sich durch nachgelagerte Schritte ziehen und schwer rückverfolgbar werden.
Technisch fügt man die Validierung als eigenen Schritt in den Orchestrator ein – ob das nun Airflow, Prefect, Dagster oder ein schlankes eigenes Skript ist. Schlägt die Suite an, entscheidet die Konfiguration: harter Abbruch bei kritischen Erwartungen, Protokolleintrag plus Alarm bei weichen.
Sinnvoll ist außerdem, die Validierungs-Reports zu archivieren. Wenn Monate später eine Strategie sich seltsam verhält, lässt sich nachschlagen, ob an einem bestimmten Tag eine Datenanomalie gemeldet wurde. Diese Historie macht die Fehlersuche von Stunden auf Minuten kürzer.
Aufwand, Werkzeuge und Pflege.
Der Einstieg ist niedrigschwellig. Eine erste Suite mit den wichtigsten zehn bis fünfzehn Erwartungen für eine Datenquelle lässt sich in ein bis zwei Tagen aufsetzen. Great Expectations ist das bekannteste Framework, aber für kleine Quant-Teams genügt oft auch eine leichtgewichtigere Bibliothek wie pandera, die direkt auf Pandas- oder Polars-DataFrames arbeitet und weniger Infrastruktur mitbringt.
Der eigentliche Aufwand liegt nicht im ersten Aufsetzen, sondern in der Kalibrierung über die Zeit. Schwellenwerte für die weichen, statistischen Prüfungen müssen nachjustiert werden, sonst produzieren sie entweder Fehlalarme oder übersehen echte Probleme. Rechnen Sie mit einer Einlaufphase von einigen Wochen, in der Sie die Regeln an den realen Datenstrom anpassen.
Die laufende Pflege ist überschaubar – aber sie ist nicht null. Validierung, die nicht gewartet wird, veraltet still und vermittelt falsche Sicherheit.
Wo automatische Validierung an Grenzen stößt.
Ein Expectation-Framework prüft, was man als Erwartung formuliert hat – nicht mehr. Es findet keine Fehler, an die niemand gedacht hat. Wer keine Regel für vertauschte Spalten schreibt, dem hilft das beste Framework nicht, wenn der Vendor genau das tut.
Zweitens ist die Grenze zwischen Fehler und echtem Marktereignis manchmal unscharf. Ein Flash-Crash, eine Currency-Abwertung über Nacht, eine Aktie, die nach Übernahmegerücht 40 Prozent springt – das sind echte, handelbare Ereignisse, die eine zu enge Plausibilitätsprüfung fälschlich als Ausreißer markiert. Wer solche Tage automatisch herausfiltert, verfälscht seinen Datensatz in die andere Richtung.
Drittens ersetzt Validierung keine inhaltliche Kontrolle. Ein Wert, der typkonform, im Bereich und plausibel ist, aber schlicht falsch – ein Zahlendreher beim Vendor – passiert jede formale Prüfung. Solche Fehler braucht Cross-Checks gegen eine zweite Quelle. Validierung ist die erste, unverzichtbare Verteidigungslinie. Sie ist nicht die einzige, und sie ersetzt nicht das Auge eines erfahrenen Quants auf die Daten.
Sie wollen Ihre Marktdaten automatisch absichern, bevor sie ins Modell fließen, und sind unsicher, welche Prüfungen den Großteil Ihrer realen Fehler abdecken? Unverbindlich anfragen — wir analysieren gemeinsam Ihre Datenquellen, identifizieren die typischen Fehlerklassen und bauen eine Validierung, die echte Probleme stoppt, ohne Sie mit Fehlalarmen zu lähmen.