Data Contracts für Trading-Pipelines bevor stille Schema-Drift Ihr Modell killt.

Eine Trading-Strategie ist nur so verlässlich wie die Daten, die sie füttern. Und genau hier liegt eine der unterschätztesten Ausfallquellen produktiver Systeme: Der Datenanbieter benennt still ein Feld um, ändert eine Einheit von Basispunkten auf Prozent, liefert Zeitstempel plötzlich in UTC statt lokaler Börsenzeit – und Ihr Live-Modell rechnet ab dem nächsten Handelstag mit Müll, ohne dass irgendwo ein Fehler aufpoppt. Der Backtest sah gestern noch perfekt aus, die Pipeline läuft grün, und trotzdem verbrennt die Strategie Geld. Data Contracts sind die Antwort auf dieses Problem: ein explizit definierter, maschinell prüfbarer Vertrag zwischen Datenlieferant und konsumierender Strategie über Schema, Typen, Wertebereiche und Verfügbarkeit. Dieser Beitrag zeigt, was ein Data Contract konkret enthält, wie man ihn im Trading-Stack technisch umsetzt, wo der Aufwand sich lohnt – und wo er zur Bürokratie ausartet, die niemand mehr pflegt.

Warum stille Schema-Drift gefährlicher ist als ein lauter Absturz.

Ein hartes Versagen – die Datei fehlt, die API antwortet mit 500, das Format ist kaputt – ist ärgerlich, aber harmlos. Es fällt sofort auf, jemand wird alarmiert, die Strategie stoppt. Die wirklich teuren Fehler sind die leisen: Daten kommen weiterhin an, sehen plausibel aus und sind trotzdem falsch.

Typische Beispiele aus der Praxis: Ein Vendor liefert Renditen bisher als Dezimalzahl (0,015) und stellt ohne Ankündigung auf Prozent um (1,5) – Ihr Modell sieht plötzlich hundertfach größere Bewegungen. Ein Volumenfeld wechselt von Stück auf Tausend Stück. Eine Spalte close wird zu close_price umbenannt, Ihr Join läuft ins Leere und füllt mit NaN, das stillschweigend auf den letzten gültigen Wert geforwardfillt wird.

In all diesen Fällen läuft die Pipeline grün durch. Der Schaden zeigt sich erst im Handelsergebnis – oft Tage später, wenn die Ursache schwer zu rekonstruieren ist. Genau diese Klasse von Fehlern soll ein Data Contract abfangen: nicht den lauten Crash, sondern die plausibel aussehende Lüge.

Was ein Data Contract konkret enthält.

Ein Data Contract ist keine vage Vereinbarung, sondern eine versionierte, maschinenlesbare Spezifikation – meist als YAML oder JSON-Schema im Repository abgelegt. Sinnvolle Bestandteile:

Der entscheidende Punkt: Der Contract gehört zum Code, wird versioniert und durchläuft Code-Review. Eine Änderung am Schema ist damit eine bewusste, dokumentierte Entscheidung – kein stiller Seiteneffekt eines Vendor-Updates.

Wie der Contract eine Pipeline kontrolliert abbricht.

Die Definition allein nützt nichts – sie muss zur Laufzeit durchgesetzt werden. Der übliche Aufbau: Am Eingang jeder Pipeline-Stufe sitzt ein Validierungs-Gate, das die eingehenden Daten gegen den Contract prüft, bevor sie weiterverarbeitet werden.

Verstößt eine Lieferung gegen den Vertrag, gibt es zwei Reaktionsmodi. Im harten Modus bricht die Pipeline kontrolliert ab und alarmiert – nichts fließt weiter, kein Trade wird auf Basis fragwürdiger Daten ausgelöst. Im weichen Modus läuft die Verarbeitung weiter, der Verstoß wird aber protokolliert und gemeldet; das eignet sich für unkritische Felder oder für eine Einführungsphase, in der man die Trefferquote der Regeln erst beobachten will.

Für sicherheitskritische Felder – Preis, Volumen, Zeitstempel – sollte der harte Modus die Regel sein. Ein kontrollierter Abbruch kostet vielleicht ein paar Stunden Datenverzögerung. Ein Tag Handel auf Basis falsch skalierter Renditen kostet potenziell ein Vielfaches.

Abgrenzung zu reiner Datenvalidierung.

Data Contracts und Datenvalidierungs-Tools werden oft verwechselt, lösen aber unterschiedliche Probleme. Validierung – etwa mit Expectation-Frameworks – prüft, ob konkrete Daten bestimmte Eigenschaften erfüllen. Das ist ein technischer Check zur Laufzeit.

Ein Data Contract ist das eine Stufe darüber: eine organisatorische Vereinbarung über Verantwortlichkeiten. Er beantwortet die Frage, wer für welche Garantien geradesteht und was passiert, wenn sie gebrochen werden. Die Validierungsregeln sind dann das technische Mittel, mit dem der Contract durchgesetzt wird.

In der Praxis verschwimmt die Grenze, und das ist in einem kleinen Quant-Team auch in Ordnung: Der Contract ist die Schema- und SLA-Spezifikation, die Validierung der Mechanismus, der sie prüft. Wichtig ist nur, beide Ebenen zu haben – die Spezifikation, gegen die man prüft, und die Prüfung selbst.

Versionierung und der Umgang mit gewollten Änderungen.

Schemas ändern sich legitim – ein Vendor fügt eine nützliche neue Kennzahl hinzu, eine Datenquelle wird gewechselt, ein Feld wird tatsächlich umbenannt. Ein guter Data-Contract-Prozess verhindert nicht Änderungen, sondern erzwingt, dass sie bewusst geschehen.

Bewährt hat sich semantische Versionierung des Contracts. Eine rückwärtskompatible Erweiterung (neues optionales Feld) ist eine Minor-Version und stört bestehende Konsumenten nicht. Eine breaking change (Feld entfernt, Typ geändert, Einheit gewechselt) ist eine Major-Version und erzwingt eine bewusste Migration: Beide Seiten – Datenproduzent und Strategie – müssen die neue Version explizit übernehmen.

Der Effekt: Eine Änderung, die früher still durchrutschte und das Modell kippte, wird zu einem sichtbaren Vorgang mit Review und Test. Das ist der eigentliche Gewinn – nicht die Verhinderung von Drift, sondern ihre Sichtbarmachung.

Aufwand, Werkzeuge und realistischer Nutzen.

Der Einstieg muss nicht groß sein. Ein erster, brauchbarer Data Contract für die kritischsten zwei oder drei Datenquellen lässt sich in wenigen Tagen aufsetzen – mit Standardwerkzeugen wie Pydantic oder pandera für die Typ- und Wertebereichsprüfung in Python, ergänzt um ein paar Vollständigkeits- und SLA-Checks.

Realistisch ist eine Bandbreite von ein bis drei Personentagen pro Datenquelle für einen soliden ersten Contract, plus laufende Pflege bei jeder bewussten Schema-Änderung. Der größere Aufwand liegt nicht in der Technik, sondern in der Disziplin: Die Verträge müssen gepflegt werden, sonst veralten sie und werden ignoriert.

Wo lohnt sich das? Bei produktiv handelnden Systemen, bei externen Datenquellen, die man nicht kontrolliert, und überall dort, wo ein Datenfehler direkt in Orders mündet. Wo es sich nicht lohnt: bei einmaligen Forschungs-Backtests auf einem statischen, lokalen Datensatz – dort ist der Vertrag Overhead ohne Gegenwert.

Grenzen und ehrliche Einordnung.

Ein Data Contract ist kein Allheilmittel. Er fängt das ab, was man vorher als Regel formuliert hat – und nur das. Ein Datenfehler, an den niemand gedacht hat und für den keine Regel existiert, rutscht weiterhin durch. Wer den falschen Wertebereich definiert, validiert falsch und wiegt sich in trügerischer Sicherheit.

Zweitens schützt der Contract vor Schema- und Format-Drift, nicht vor inhaltlich falschen, aber formal korrekten Daten. Ein Kurs von 99,80 statt 98,90 – ein Zahlendreher beim Vendor – ist typkonform, im Wertebereich und verletzt keinen Contract. Solche Fehler braucht zusätzliche statistische Plausibilitätsprüfung.

Drittens gibt es einen kulturellen Preis: Verträge, die ständig falsch abbrechen, weil die Regeln zu eng sind, werden vom Team entnervt deaktiviert. Die Kunst liegt darin, die Regeln eng genug für echten Schutz und weit genug für den Normalbetrieb zu kalibrieren. Das ist iterative Arbeit, kein einmaliges Aufsetzen – und genau hier scheitern viele Implementierungen, nicht an der Technik.

Sie wollen wissen, ob Ihre Daten-Pipeline still driftet und wo ein Data Contract Ihr Live-System absichern würde? Unverbindlich anfragen — wir schauen gemeinsam auf Ihre Datenquellen, Ihre kritischen Felder und Ihren Stack und definieren die Verträge dort, wo sie echten Schaden verhindern, statt nur Bürokratie zu erzeugen.