Die Automatisierung des Optionshandels über die TWS API bringt spürbare Effizienzgewinne – aber nur, wenn das Risikomanagement mit der gleichen Sorgfalt entwickelt wird wie die Strategie selbst. Dieser Artikel geht durch, was technisch möglich ist, wo die typischen Fallstricke liegen und wie sie sich programmatisch abfangen lassen.
1. Funktionaler Umfang der TWS API
Die API steuert viele Funktionen der Trader Workstation programmatisch.
Möglich:
- Kauf- und Verkaufsorder für Aktien, Anleihen und Optionen, inklusive Stop-Loss und Take-Profit
- Ausübung (Exercise) von Optionen
- Abruf von Kontodaten: Cash-Balance, offene Positionen, Margin-Auslastung
- Historische und Echtzeit-Marktdaten für alle verfügbaren Assets
Nicht möglich:
- Kapitaltransfers (Ein- und Auszahlungen) lassen sich nicht über die API initiieren.
Im Optionshandel gilt: Jedes Underlying und jedes Verfallsdatum, das in der TWS handelbar ist, ist grundsätzlich auch automatisierbar. Der limitierende Faktor ist ausschließlich die Implementierung der verwendeten Software – nicht die API.
2. Operative Risiken und Lösungsansätze
Automatisierter Handel bringt eigene, sehr spezifische Fehlerquellen mit sich.
Risiko 1: Order-Rejection bei modifizierten Stops (insb. 0DTE)
Wird eine Stop-Order bei Erreichen des Trigger-Preises modifiziert und der Kurs dreht im selben Moment zurück, kann die Order abgelehnt werden – die Position steht dann ungesichert da. Die saubere Lösung: eine zweite Stop-Order mit den neuen Parametern platzieren und die ursprüngliche erst löschen, nachdem die neue erfolgreich platziert wurde.
Das ist mir während der Entwicklung von ThetaPilot selbst passiert. Seitdem behandle ich Strategien mit häufig nachgezogenen (adjusted) Stops als eigene Risikokategorie und meide sie, wo es geht, denn auch mit der vorgeschlagenen Lösung sind Abweisungen der Order meiner Meinung nach nicht ausgeschlossen.
Risiko 2: Fehlerhafte Strike-Auswahl
Falsch berechnete Parameter führen zur Eröffnung einer ungewollten Optionsposition. Die Standardlösung sind Preconditions – etwa eine Delta-Validierung oder eine Prüfung der Price-Range vor dem Order-Versand.
Aus Trading-Communities weiß ich, dass genau das schon vielen Nutzern der Trade Automation Toolbox (TAT) passiert ist, obwohl dort eine Price-Range-Prüfung als Absicherung vorgesehen ist. In ThetaPilot laufen vor jedem Entry mehrere Konsistenzchecks parallel – nicht nur die Price-Range –, weshalb dieser Fehlerfall dort strukturell ausgeschlossen ist. Warum sich das bei TAT nicht durchgesetzt hat, ist mir ehrlich gesagt ein Rätsel.
Risiko 3: Illiquidität und hohe Spreads
Extreme Bid-Ask-Spreads führen zu Ausführungen zu unvorteilhaften Preisen. Die Standardlösung ist ein Spread-Filter: Überschreitet der Spread einen definierten Schwellenwert und es gibt keine Alternative, wird der Trade ausgesetzt.
Wichtig dabei: Hohe Spreads sind nicht immer ein reines Liquiditätsproblem. Gelegentlich sind es schlicht CBOE-Datenfehler. Ein Spread-Check gehört deshalb als fester Konsistenzcheck in jede Automatisierung – unabhängig davon, wie liquide das Underlying normalerweise ist.
Risiko 4: Überlappende Strikes bei mehreren Strategien
Laufen mehrere Strategien parallel auf demselben Underlying und DTE, können sich Long- und Short-Positionen gegenseitig aufheben. Exit-Kombos wie Take-Profit oder Stop-Loss verhalten sich dann nicht mehr deterministisch, weil sie im schlimmsten Fall Optionen handeln wollen, die gar nicht mehr im Bestand sind – bis hin zu ungedeckten Shorts. Die Lösung: den Bestand vor jedem Entry prüfen und bei Überschneidungen auf einen Nachbar-Strike ausweichen oder den Trade aussetzen.
Aus Erfahrungen in Trading-Communities überrascht mich immer wieder, wie sorglos viele Trader hiermit umgehen – vielen ist nicht bewusst, dass Tools wie TAT oder OptionsApp das eigene Portfolio auf diese Weise beschädigen können. Meines Wissens kann TAT Overlaps zwischen den eigenen automatisiert eröffneten Trades verhindern, dies muss vom Anwender jedoch so eingestellt werden. Sobald aber parallel manuell gehandelt wird, greift dieser Schutz meines Wissens nicht mehr – dann muss man den Check selbst mitdenken, und dies, obwohl die API es erlauben würde, Bestandspositionen abzufragen.
Risiko 5: Infrastruktur-Ausfälle
Fällt die Verbindung oder der Strom des lokalen Clients genau dann aus, wenn die Automatisierung für den Exit aktiv werden müsste (z.B. Time-Exit), bleibt die Position ungeschützt. Abhilfe schaffen ein stabiler Cloud-VPS mit redundanter Anbindung – und, wo möglich, serverseitige Order-Typen, die komplett ohne laufenden Client auskommen (siehe Nerd-Bonus unten).
Risiko 6: Verpasste Trades
Findet die Software temporär keine passenden Strikes oder verhindert ein API-Fehler den Entry, ist das statistisch hinzunehmen. Die gewonnene Konsistenz über viele Trades hinweg wiegt einzelne Ausfälle mehr als auf.
3. Fazit
Automatisierung ist der Hebel für zeit-effizienten, konsistenten Optionshandel: Sie eliminiert emotionale Fehlentscheidungen, setzt Backtest-Regeln 1:1 um und übernimmt die Datenauswertung und Dokumentation nebenbei. Die hier beschriebenen Risiken sind alle beherrschbar – vorausgesetzt, man baut die passenden Konsistenzchecks von Anfang an ein und prüft die TWS regelmäßig manuell nach.
Nerd-Bonus: Server-seitiger Time-Exit mit gekoppelten REL-Orders
Für Spread-Positionen lässt sich der Exit teilweise direkt bei Interactive Brokers hinterlegen, statt ihn über die eigene Automatisierung zu triggern. Das Prinzip: Die erste Order bekommt eine Preis- und eine Zeitbedingung (REL-Stop). Die zweite Order ist über hedgeType an die erste gekoppelt und wird ausgelöst, sobald die erste feuert. Läuft der REL-Stop-Preis der ersten Order an – egal ob durch die Preis- oder die Zeitbedingung – triggert IB die zweite Order automatisch mit. Das komplette Zusammenspiel läuft serverseitig bei IB ab; es muss zu diesem Zeitpunkt keine eigene Automatisierung mehr aktiv sein (siehe Risiko 5 oben).
Vereinfacht, ohne die Details aus der produktiven Implementierung, sieht das so aus:
from ibapi.order import Order
from ibapi.order_condition import PriceCondition, TimeCondition
# Bedingung 1: Preis-Trigger auf den Short-Leg
price_condition = PriceCondition()
price_condition.conId = short_leg_con_id
price_condition.price = stop_price
price_condition.isMore = True
price_condition.triggerMethod = 1
price_condition.Or()
# Bedingung 2: Zeit-Trigger kurz vor Handelsschluss
# Der time-String muss in der Zeitzone des Underlyings stehen,
# bei SPX also Chicago/CBOE – nicht die eigene Serverzeitzone.
time_condition = TimeCondition()
time_condition.time = exit_time_string # z.B. "20260904 15:50:00 US/Central"
time_condition.isMore = True
# Order 1: REL-Stop mit Preis- ODER Zeitbedingung, wird noch nicht übermittelt
stop_order = Order()
stop_order.orderId = parent_order_id
stop_order.action = "BUY"
stop_order.orderType = "REL"
stop_order.totalQuantity = quantity
stop_order.auxPrice = 0.30
stop_order.tif = "GTC"
stop_order.outsideRth = True
stop_order.conditions = [price_condition, time_condition]
stop_order.transmit = False
# Order 2: über hedgeType an Order 1 gekoppelt, feuert automatisch mit
hedge_order = Order()
hedge_order.orderId = parent_order_id + 1
hedge_order.parentId = parent_order_id # Verknüpfung zur ersten Order
hedge_order.action = "SELL"
hedge_order.orderType = "REL"
hedge_order.totalQuantity = 0.0 # IB übernimmt die Menge automatisch vom Parent
hedge_order.auxPrice = 0.10
hedge_order.hedgeType = "P" # Pair-Hedge, gekoppelt an die Parent-Order
hedge_order.hedgeParam = "1"
hedge_order.tif = "GTC"
hedge_order.outsideRth = True
hedge_order.usePriceMgmtAlgo = True
hedge_order.transmit = True # übermittelt beide Orders als PaketDie Bedingungen price_condition und time_condition werden je nach gewünschter Logik mit .Or() oder .And() verknüpft: Preis ODER Zeit löst beim ersten der beiden Ereignisse aus, Preis UND Zeit erst wenn beide erfüllt sind. transmit=False auf der ersten Order sorgt dafür, dass beide Orders erst gemeinsam übermittelt werden, sobald die zweite mit transmit=True gesendet wird – so landet nie nur eine Hälfte des Konstrukts im System.