Methodik › Backtest-Engine

Methodik · Teil 2 von 3

Die Backtest-Engine

Wie aus rohen Marktdaten ein nachvollziehbares Ergebnis wird — von der Datenpipeline über die Handelslogik bis zur Oberfläche. Und der Verweis aufs Repository, damit sich alles nachrechnen lässt.

Lesezeit ca. 14 Minuten

Überblick

Architektur in einem Bild

Die Engine ist als Pipeline aufgebaut: Daten fließen von links nach rechts durch klar getrennte Stufen. Jede Stufe hat eine Aufgabe und lässt sich einzeln prüfen — das ist die Voraussetzung dafür, dass ein Ergebnis am Ende nachvollziehbar bleibt.

Pipeline der Engine Daten-LoaderKurse + Ketten BereinigungFilter + Checks Strategie-RegelSignal + Auswahl AusführungFill + Kosten BuchhaltungP&L, Margin Kennzahlen+ Report/GUI Jede Stufe ist einzeln testbar — Fehler bleiben lokal und nachvollziehbar.
Schematischer Aufbau. Die Trennung in Stufen sorgt dafür, dass sich jeder Schritt isoliert prüfen lässt — etwa die Bereinigung unabhängig von der Handelslogik.
An deinen echten Stack anpassen: Nenne Sprache und Kernbibliotheken (z. B. Python, pandas, NumPy) und ob die Engine ereignis- oder vektorbasiert rechnet. Diese eine Angabe signalisiert Fachleuten sofort, wie ernst das Projekt gemeint ist.

Stufe 1 — Daten

Datenbasis und Bereinigung

Jedes Ergebnis ist nur so gut wie seine Daten. Benötigt werden die Kursdaten des Basiswerts und die Optionsdaten — historische Preise, implizite Volatilitäten und Griechen je Kontrakt.

Quellen und Zeitraum eintragen: z. B. [Optionsdaten-Anbieter] für End-of-Day-Ketten, [Kursquelle] für den Basiswert, Zeitraum [JJJJ–JJJJ]. Transparenz über die Datenquelle ist der wichtigste einzelne Glaubwürdigkeitsfaktor.

Vor jedem Lauf durchlaufen die Rohdaten feste Prüfungen — gegen Arbitrageverletzungen, verdrehte Quotes, Ausreißer und Lücken. Fehlt ein Preis, wird der Trade übersprungen statt geschätzt: Ein ausgelassener Trade verzerrt weniger als ein erfundener Füllpreis.

GUI · Datenimport & Qualitätsreport
[Screenshot: Import-Ansicht der Engine]
Zeigt geladenen Zeitraum, Anzahl Kontrakte, erkannte Lücken und die Zahl der aussortierten fehlerhaften Quotes. Auf entfernte Kontostände/IDs achten.

Stufe 2 — Regeln

Die vier Prinzipien der Ausführung

Die größte Fehlerquelle ist nicht die Technik, sondern der Mensch, der während der Simulation eingreift. Deshalb läuft jeder Backtest mechanisch nach vier Prinzipien:

  • Regeln vorab definiert — die komplette Logik steht fest, bevor der Test läuft, und wird nicht nachträglich getunt.
  • Keine subjektiven Eingriffe — die Simulation verarbeitet jeden Tag identisch, egal wie der Markt steht.
  • Jeder Trade gleich — der erste und der zehntausendste folgen derselben Logik.
  • Realistische Bedingungen — nie zum theoretischen Mittelkurs, sondern inklusive Spread, Slippage und Kosten.

Nur so ist das Ergebnis eine Aussage über die Regel — nicht über das Geschick dessen, der sie anwendet.

GUI · Strategie-Konfiguration
[Screenshot: Regel-Editor der Engine]
Zeigt die einstellbaren Parameter einer Strategie — DTE-Fenster, Delta-Ziel, Roll-Schwelle, Positionsgröße — die vor dem Lauf fixiert werden.

Stufe 3 — Kosten

Realistische Handelsbedingungen

Der Unterschied zwischen einem seriösen und einem schöngerechneten Backtest liegt fast immer in den Kostenannahmen. Die folgenden sind bewusst konservativ — im Zweifel zulasten des Ergebnisses.

FaktorAnnahme
Bid-Ask-SpreadFill Richtung ungünstigeres Ende, nicht Mittelkurs
SlippageZusätzlicher Abschlag von [X]
Kommission[X] € je Kontrakt plus Gebühren
LiquiditätNur Kontrakte über Mindest-Open-Interest/Volumen
AusführungZum nächsten realen Preis, nie zu einem Zukunftskurs

Warum der Spread so viel ausmacht

Put quotiert 1,95 / 2,15, Mittelkurs 2,05. Wer zum Mittelkurs bucht, rechnet mit 2,05 — realistisch füllt die Verkaufsorder bei 2,00 oder darunter. Fünf Cent mal 100 Stück sind 5 € je Trade, bei tausend Trades 5.000 €, die zwischen Schein und Wirklichkeit liegen.

Optionen

Optionsspezifische Regeln

Optionen bringen Komplikationen, die die Engine explizit behandeln muss:

  • Laufzeiten (DTE): feste Auswahl, z. B. „am nächsten an 45 Tagen“.
  • Delta oder Strike: Auswahl über festen Strike-Abstand oder Delta-Ziel; Delta passt sich automatisch der Volatilität an.
  • Assignment: vorzeitige Ausübung wird erkannt — besonders tief im Geld und rund um Dividenden — und korrekt gebucht.
  • Rollen: feste Schwellen (z. B. „schließen bei 50 % Gewinn“ oder „rollen unter 21 DTE“), beide Transaktionen mit vollen Kosten.
  • Margin: Belastung nach Kontomodell, sonst wird scheinbar mit unbegrenztem Hebel gehandelt.
Konkretisieren: Welches Margin-Modell (Reg-T, Portfolio Margin, SPAN) und welche Positionsgröße unterstellst du? Beides bestimmt den Hebel und damit fast das gesamte Risikoprofil.

Stufe 4 — Ergebnis

Kennzahlen und Oberfläche

Am Ende steht ein Report: Equity-Kurve, Drawdown-Verlauf und die zentralen Kennzahlen — CAGR, Max Drawdown, Sharpe, Trefferquote, Profit Factor, Anzahl Trades. Keine davon erzählt allein die ganze Geschichte; erst zusammen ergeben sie ein Bild. Eine ausführliche Erläuterung jeder Kennzahl steht in der Übersicht.

GUI · Ergebnis-Dashboard
[Screenshot: Report-Ansicht nach einem Lauf]
Equity-Kurve gegen Benchmark, Drawdown-Kurve darunter, Kennzahlen-Panel rechts. Der aussagekräftigste Screenshot für Besucher — hier wird die Engine „greifbar“.

Nachvollziehbarkeit

Zum Nachrechnen: das Repository

„Nachvollziehbar“ ist ein Versprechen — ein öffentliches Repository ist der Beweis. Der Code der Engine liegt offen, damit jede Annahme dieser Seite im Quelltext überprüfbar ist und Ergebnisse reproduziert werden können.

Repository
$ git clone [dein-repo-link]
// Enthält: Engine, Beispiel-Konfigurationen, Auswertungs-Notebooks
// Ausführung siehe README — Datenlizenzen liegen nicht bei
Vor Veröffentlichung klären: Öffentliches oder privates Repo? Falls öffentlich — keine API-Keys, keine Broker-Zugänge, keine lizenzpflichtigen Rohdaten mit einchecken. Ein sauberes README mit Reproduktionsanleitung wirkt stärker als viel Code ohne Anleitung.