Datenqualität ist Teil jeder Auswertung — nicht die Nachkontrolle.
Schematische, anonymisierte Ansicht. Instrumente, Positionen und Werte sind illustrativ; Qualitäts-, Abgleichs- und Risikologik bilden den realen Systemansatz ab.
Ausgangslage, Aufgabe, Umsetzung.
- Viele Kennzahlen, selten die gebrauchten
- Herkunft einer Zahl nicht nachvollziehbar
- Kein Abgleich gegen echte Kontobestände
- Widersprüche zwischen Anbietern ungelöst
- 6 Quellen mit fester Prioritätsregel
- Jede Zahl bis zur Rohdatenzeile rückverfolgbar
- Abgleich gegen Broker-Bestände automatisch
- Qualitätsprüfung 2× täglich, meldet vor Nutzung
| Rolle | Architektur, Umsetzung und Betrieb in einer Person |
| Laufzeit | Mai 2026 bis heute, täglich im Einsatz |
| Umfang | 128 Python-Module, 65 Auswertungsseiten · Stand Juli 2026: rund 620 Commits |
| Kernproblem | Nicht die Anbindung der Quellen — die Absicherung gegen falsche Daten |
Warum dieses System für ein IT-Mandat relevant ist.
- Der Anwendungsfall ist der Kapitalmarkt — die Ingenieursleistung nicht. Widersprüchliche Quellen, verzögerte Daten, Ausreißer und Schnittstellenabbrüche treten in jedem datengetriebenen Unternehmen auf.
- Dieselben Fragen entscheiden über Management-Reporting. Welcher Zahl glaubt man im Zweifel? Woher kommt sie? Wie alt ist sie?
- Der Unterschied zur Konzeptarbeit: Hier kostet eine falsche Zahl unmittelbar Geld — das verändert, wie man Datenqualität baut.
„Eine Kennzahl ohne belegbaren Datenstand ist keine Kennzahl, sondern eine Vermutung mit Nachkommastellen."
Technischer Deep-Dive.
Datenarchitektur, Qualitätssicherung und die fachliche Logik im Detail — inklusive der Fehler, die dabei aufgetreten sind.
Datenarchitektur & Quellen aufklappen
Quellen und ihre Rolle
| Ebene | Umsetzung |
|---|---|
| Broker-API | Direkte Anbindung an die Handelsplattform für Kontostände, Positionen, Ausführungen und Live-Kurse |
| Kursdaten | Kommerzieller Marktdatenanbieter für Historie, Fundamentaldaten und Sektorzuordnung |
| Abrechnungsdaten | Automatisierter Abruf standardisierter Broker-Auswertungen für Transaktionshistorie und Gebühren |
| Terminmarktdaten | Wöchentliche Positionsdaten der US-Aufsichtsbehörde für Marktstimmungsanalysen |
| Nachrichten | Strukturierter Nachrichten-Feed für ereignisbezogene Auswertungen |
| Speicherung | DuckDB als analytische Datenbank für Zeitreihen; getrennte Datenbanken je Domäne mit Einzelschreiber-Prinzip |
Quellenpriorität als feste Regel
Bei Widersprüchen gilt eine dokumentierte Rangfolge: Broker-Livedaten vor kommerziellem Anbieter vor freiem Fallback. Die Reihenfolge steht im Code, nicht im Kopf — sonst entscheidet jede Auswertung anders.
Datenqualität — die eigentliche Schwierigkeit aufklappen
Aufwendig war nicht die Anbindung, sondern die Absicherung gegen falsche Daten. Vier Mechanismen laufen dauerhaft:
- Plausibilitätsgrenzen — Kennzahlen mit bekannten Wertebereichen werden bei Überschreitung verworfen statt gespeichert. Eine historische Volatilität von über 250 Prozent ist ein Datenfehler, kein Marktereignis.
- Frischeprüfung — jede Auswertung zeigt den tatsächlichen Datenstand aus der Quelle, nicht das Änderungsdatum der Datei. Veraltete Daten werden als solche markiert statt stillschweigend angezeigt.
- Zweimal tägliche Kontrolle — ein automatisierter Prüflauf vergleicht Bestände, Summen und Zeitstempel gegen erwartete Bandbreiten und meldet Abweichungen.
- Abgleich gegen die Kontowahrheit — errechnete Positionswerte werden gegen die tatsächlichen Broker-Bestände geprüft. Eine Abweichung ist immer ein Fehler im eigenen System, nie im Kontoauszug.
Ein konkreter Fehlerfall
Eine Auswertung zeigte eine Kennzahl grün, obwohl der Sachverhalt kritisch war. Ursache: Die angezeigte Prozentzahl wurde auf einer anderen Bezugsgröße berechnet als die Regel, die die Warnfarbe bestimmte. Beide Berechnungen waren für sich korrekt — sie maßen nur nicht dasselbe. Seitdem gilt: Anzeigekennzahl und Entscheidungskennzahl müssen dieselbe Quelle und denselben Nenner verwenden. Diese Regel ist als verbindliche Prüfung hinterlegt.
Fachliche Logik: Optionsstrategien & Risikobewertung aufklappen
Der fachliche Kern ist die Bewertung von Optionsstrategien. Was in einer Standardsoftware als Liste einzelner Positionen erscheint, muss zu tatsächlichen Strategien zusammengesetzt werden — sonst entsteht ein falsches Risikobild.
Was das System auswertet
- Strategieerkennung — einzelne Positionen werden zu zusammengehörigen Strategien gruppiert (Spreads, Kombinationen, gedeckte Positionen), inklusive Erkennung von Einzelpositionen ohne Gegenstück
- Deckungsprüfung — automatische Prüfung, ob eine verkaufte Option gedeckt ist oder ein unbegrenztes Risiko trägt; ungedeckte Positionen werden gesondert markiert
- Volatilitätsanalyse — Vergleich der impliziten mit der historischen Volatilität als Auswahlkriterium; Scanner für mehrere Indexuniversen
- Prämien- und Ergebnisverfolgung — Journal über vereinnahmte Prämien, realisierte Ergebnisse und Gebühren, abgeglichen gegen die Broker-Abrechnung
- Marktstimmungsindikatoren — Terminmarkt-Positionsdaten, Optionsvolumen-Auswertungen und Volatilitätsstrukturkurven
- Rückrechnung — Auswertung abgeschlossener Positionen nach Strategie und Zeitraum als Grundlage für Regelanpassungen
Regeln statt Bauchgefühl
Auswahlkriterien sind als überprüfbare Regeln hinterlegt — etwa eine Mindestprämie im Verhältnis zur Risikobreite oder die Bedingung, dass die implizite Volatilität über der historischen liegen muss. Der Wert liegt nicht in der einzelnen Regel, sondern darin, dass sie maschinell prüfbar und damit im Nachhinein bewertbar ist.
Was das System bewusst nicht tut
Es handelt nicht selbstständig. Aufträge werden nicht automatisiert an den Markt gegeben; das System bereitet Entscheidungen auf und dokumentiert sie. Diese Grenze ist absichtlich gesetzt — ein Datenfehler soll eine falsche Anzeige verursachen können, aber keine falsche Transaktion.
Betrieb: Zeitsteuerung, Ausfälle, Wiederanlauf aufklappen
Zeitgesteuerte Abläufe
Datenabrufe laufen gestaffelt: Live-Kurse während der Handelszeiten im Minutentakt, Abrechnungsdaten nach Handelsschluss, wöchentliche Positionsdaten nach Veröffentlichung durch die Aufsichtsbehörde. Jeder Lauf schreibt einen Statuseintrag — ein ausgefallener Job ist sichtbar, nicht stillschweigend übergangen.
Umgang mit erwartbaren Ausfällen
- Feiertage — an Börsenfeiertagen liefert der Broker keine Abrechnung. Das ist kein Fehler und löst keinen Alarm aus; der Lauf wird als planmäßig leer vermerkt.
- Verbindungsverlust — bricht die Broker-Verbindung ab, greift ein definierter Rückfallpfad auf zuletzt bekannte Werte, deutlich als veraltet gekennzeichnet.
- Wiederanlauf — Abrufe sind wiederholbar gebaut: Ein zweiter Lauf für denselben Zeitraum erzeugt keine Dubletten.
Sicherheit
Zugangsdaten und Schnittstellenschlüssel liegen ausschließlich in Umgebungsdateien außerhalb der Versionsverwaltung. Ein Prüfhook blockiert Commits, die Zugangsdaten im Klartext enthalten würden — technisch erzwungen, nicht als Vorsatz.