Methodik › Backtest-Engine

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

Dieser Teil beschreibt, wie ein Lauf technisch zustande kommt. Zunächst die Architektur im Überblick, dann die Datenbasis und wie sie bereinigt wird. Danach folgen die vier Prinzipien, nach denen Positionen eröffnet und geschlossen werden, und die Annahmen, die den Handel realistisch halten sollen — Kosten, Geld-Brief-Spanne, Deckung. Anschließend geht es um die Kennzahlen, die jeder Lauf ausgibt, und um die Oberfläche. Zuletzt der Verweis auf das Repository, mit dem sich jeder Lauf nachrechnen lässt. Konkrete Ergebnisse stehen hier nicht — nur das Verfahren, das sie erzeugt.

Kapitel 1

Kapitel 1: 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.

Die Engine ist in Python geschrieben (ab Version 3.10) und kommt mit einem schlanken Satz an Bibliotheken aus: pandas und NumPy für die Datenhaltung, matplotlib für die Auswertungsgrafiken, openpyxl für den Excel-Export. Optional beschleunigt pyarrow den Parquet-Cache, der Folgeläufe deutlich verkürzt. Bedient wird alles über eine Oberfläche im Browser (Streamlit); wer offline arbeiten will, nutzt die gleichwertige Tkinter-Variante. Beide Oberflächen greifen auf denselben Ausführungskern zu — die Rechenlogik existiert genau einmal.

Gerechnet wird ereignisbasiert: Die Engine geht die Handelstage der Reihe nach durch, eröffnet Positionen nach dem eingestellten Takt und prüft für jede offene Position in fester Reihenfolge, ob ein Ausstiegsgrund vorliegt. Das ist langsamer als ein vektorisierter Ansatz, hält aber die Ausstiegslogik nachvollziehbar und schließt aus, dass eine Regel zufällig vor einer anderen greift.

Der vollständige Quelltext liegt öffentlich unter github.com/Paul090787/OptionBacktester (MIT-Lizenz). Die Optionsketten selbst liegen aus Lizenzgründen nicht im Repository — das README beschreibt, wie sie sich bei OptionsDX kostenfrei beschaffen lassen.

Wer nicht mit Python arbeitet, muss nicht außen vor bleiben. Geplant ist eine ausführbare Anwendung, die ohne Python-Installation startet: herunterladen, entpacken, Optionsketten daneben legen, starten. Die Engine ist darauf vorbereitet — in einem gepackten Build zeigen die Standardpfade auf den Ordner der Anwendung statt in ein temporäres Verzeichnis, sodass Daten und Ergebnisse dauerhaft daneben liegen bleiben. Der Download ist noch nicht verfügbar: [Link einzutragen, sobald der Build steht]

Die Optionsketten müssen in jedem Fall selbst beschafft werden, weil sie nicht mitgeliefert werden dürfen.

Kapitel 2

Kapitel 2: 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.

Die Optionsdaten stammen von OptionsDX. Verwendet werden End-of-Day-Ketten, also ein Datensatz je Handelstag und Kontrakt mit Geld- und Briefkurs, impliziter Volatilität und Griechen. Die Daten sind frei verfügbar — jeder kann denselben Rohbestand herunterladen und die Läufe nachrechnen. Das ist der Grund für diese Wahl: Eine kostenpflichtige Quelle würde die Reproduzierbarkeit an eine Lizenz binden.

End-of-Day bedeutet zugleich eine Einschränkung, die offen gehört: Innerhalb eines Handelstages ist nichts sichtbar. Ein Einstieg zum Schlusskurs unterstellt, dass man zu diesem Preis auch tatsächlich handeln konnte. Für Regeln, die auf Intraday-Bewegungen reagieren, ist diese Datenbasis nicht geeignet.

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.

Kapitel 3

Kapitel 3: 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.

Kapitel 4

Kapitel 4: 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.

Tabelle 4.1 · Definitionstabelle der Kostenannahmen, keine Ergebnisdaten. Die Werte für Slippage und Kommission sind Einstellungen der Engine und stehen in jedem Report in den Feldern slippage_pct_of_spread und commission_per_contract. Sie gelten unverändert für alle Läufe dieses Blogs.

Kapitel 5

Kapitel 5: 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.

Kapitel 6

Kapitel 6: 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.

Das Repository ist öffentlich. Zugangsdaten, Broker-Verbindungen und lizenzpflichtige Rohdaten liegen nicht darin; das README beschreibt, wie sich die Datenbasis selbst beschaffen und ein Lauf reproduzieren lässt.