Trading-Bot-Architektur für IBKR: Komponenten und Datenfluss.

Ein produktiver Trading-Bot für Interactive Brokers lässt sich in neun Bausteine gliedern: IB Gateway oder TWS, Verbindungsschicht, Marktdaten, Strategie, Risikoschicht mit Not-Aus, Order-Management, Konto- und Positionsdaten, Persistenz und Monitoring. Über die Betriebssicherheit entscheidet weniger die Strategie als der Datenfluss dazwischen. Der Bot sollte erst nach dem Callback nextValidId Aufträge senden, er hat ein begrenztes Anfragebudget von standardmäßig 50 Anfragen pro Sekunde, und Kontodaten aus reqAccountUpdates taugen nicht für Echtzeit-Risiko, weil sie ohne Positionsänderung nur alle drei Minuten kommen. Es folgt eine Referenzarchitektur in Schichten mit den IBKR-Besonderheiten jeder Komponente, Stand Oktober 2026.

Aus welchen Komponenten besteht ein IBKR-Trading-Bot?

Die TWS API ist eine Socket-Schnittstelle zu TWS oder IB Gateway, nicht zu den IBKR-Servern selbst. Interactive Brokers beschreibt sie als Werkzeug, das manuelle Abläufe in TWS automatisiert: Orders erteilen, Konto und Positionen beobachten, Kurse abrufen. Die API enthält keine eigene Logik außer der Prüfung, dass die Nachrichten intakt ankommen. Validierung findet in TWS und auf den IBKR-Servern statt. Daraus folgt eine Regel, die viele Architekturfragen klärt: Was in TWS nicht geht, geht auch über die API nicht. Ordertypen und Kombinationen probieren Sie deshalb zuerst von Hand in TWS aus.

Ein produktiver Bot braucht darum klar getrennte Bausteine:

Der Ereignisfluss läuft in eine Richtung: Marktdaten gehen an die Strategie, die erzeugt eine Order-Absicht, die Risikoschicht prüft sie, das OMS vergibt die Order-ID und übergibt an den Connector. Die Rückmeldungen von TWS fließen über das OMS in die Persistenz und von dort in die Positions- und Risikosicht. Ob ein Prozess mit Modulen oder mehrere Prozesse: Wichtig ist, dass die Strategie nie selbst Orders an die API schickt. Nur so greifen Limits, Not-Aus und Protokollierung für jede einzelne Order.

Verbindungsschicht: Client-IDs, Startreihenfolge, nextValidId.

Der Verbindungsaufbau hat drei Stufen. Zuerst öffnet das Betriebssystem einen TCP-Socket zum API-Port. Schlägt das fehl, kommt Fehler 502, der nicht von TWS stammt und deshalb auch nicht in den TWS-Logs steht. Danach handeln Client und TWS die gemeinsame Protokollversion aus. Erst dann schickt TWS die Daten der Sitzung: die erreichbaren Kontonummern, die nächste gültige Order-ID und die Verbindungszeit. Laut IBKR dient der Callback nextValidId üblicherweise als Signal, dass die Verbindung fertig ist. Aufrufe vor diesem Zeitpunkt kann TWS verwerfen.

Für die Architektur heißt das: Der Connector ist ein kleiner Zustandsautomat mit den Zuständen getrennt, verbindend, bereit und gestört. Andere Komponenten dürfen nur im Zustand bereit senden. Die Startreihenfolge eines Bots lautet deshalb: Gateway läuft und ist angemeldet, Socket verbinden, auf nextValidId warten, Abgleich von Orders und Positionen, Marktdaten abonnieren, erst dann die Strategie freigeben.

Die Order-ID verwaltet der Client selbst, sie muss streng steigend sein. Die Sequenz bleibt laut Doku über TWS-Sitzungen hinweg erhalten und lässt sich in den API-Einstellungen nur zurücksetzen, wenn keine API-Orders aktiv sind. Das OMS übernimmt beim Start den Wert aus nextValidId und zählt lokal hoch; bei Zweifeln fordert es mit reqIds einen neuen Wert an.

Jede TWS-Sitzung nimmt bis zu 32 Client-Anwendungen gleichzeitig an, unterschieden durch die Client-ID. Verbindet sich ein zweiter Client mit einer bereits belegten ID, bricht die Verbindung mit einer Socket-Ausnahme ab. Legen Sie deshalb ein festes Schema fest. Typisches Beispiel: ID 1 für den Order-Prozess, ID 2 für einen reinen Marktdaten-Prozess, eine eigene ID für Überwachung und Auswertung. Fällt die Verbindung weg, meldet die API das über connectionClosed. Ein Reconnect mit wachsenden Wartezeiten gehört in den Connector, nicht in die Strategie.

Auch das Pacing-Budget gehört in diese Schicht. IBKR erlaubt höchstens Marktdatenlinien geteilt durch 2 Anfragen pro Sekunde, bei den standardmäßigen 100 Linien also 50. Bei einem Datenstream zählt nur die erste Anfrage. Je nach Einstellung in TWS lehnt die Software Überschreitungen mit Fehler 100 ab und beendet die Sitzung nach drei Verstößen, oder sie drosselt selbst und verzögert damit Ihre Anfragen. Ein zentraler Drosselmechanismus im Connector verhindert beides.

Order-Management: Status, Ausführungen, Master Client ID.

Orders, die über die API erteilt werden, sind an die Client-ID gebunden, von der sie stammen; nur dieser Client kann sie ändern. Deshalb sollte genau ein Prozess Orders senden und ändern. Andere Prozesse lesen mit. Damit ein Überwachungsprozess laufend sieht, was der Order-Prozess tut, gibt es in der Global Configuration die Master Client ID. Nur eine Verbindung mit dieser ID erhält über openOrder und execDetails auch Orders und Ausführungen anderer API-Verbindungen. Ohne sie sieht jeder Client nur seine eigenen; reqAllOpenOrders liefert lediglich eine einmalige Momentaufnahme aller offenen Orders.

Client-ID 0 hat eine Sonderrolle: Sie erhält zusätzlich Orders, die manuell in TWS oder über FIX erteilt wurden. Ruft Client 0 reqOpenOrders auf, werden offene manuelle TWS-Orders an ihn gebunden und bekommen eine API-Order-ID. Die Bindung storniert laut Doku eine Börsen-Order und stellt sie neu ein, was den Warteschlangenplatz kosten kann. Die Master Client ID lässt sich auf 0 setzen, dann sieht eine Verbindung alles im Konto. Handelt parallel ein Mensch in TWS, muss der Bot fremde Orders erkennen und darf sie nicht als eigene behandeln.

IBKR empfiehlt für robuste Systeme, vier Callbacks zu überwachen: error, orderStatus, openOrder und execDetails. Orders können abgelehnt oder storniert werden, etwa mit Fehler 201 bei zu großer Stückzahl oder mit Status Cancelled und Fehler 202, wenn der Limitpreis zu weit vom Markt liegt. Die Doku weist zudem darauf hin, dass orderStatus-Meldungen oft doppelt eintreffen. Das OMS braucht daher einen Zustandsautomaten pro Order, der identische Meldungen ignoriert und nur gültige Übergänge zulässt.

Ausführungen identifiziert das OMS über die execId. Korrekturen einer Ausführung kommen laut IBKR als zusätzlicher execDetails-Callback, bei dem sich nur die Ziffern nach dem letzten Punkt der execId unterscheiden. Wer Fills einfach aufsummiert, zählt Korrekturen doppelt. Hinzu kommt: reqExecutions liefert standardmäßig nur Ausführungen seit Mitternacht. In TWS lässt sich der Zeitraum über die Trade-Log-Einstellung auf bis zu sieben Tage erweitern, IB Gateway bleibt auf den aktuellen Handelstag beschränkt. Orders des Tages, die nicht mehr änderbar sind, liefert reqCompletedOrders. Für alles darüber hinaus brauchen Sie eine eigene Datenbank mit Order-ID, permId, Client-ID, Status und Ausführungen.

Eine Einstellung verdient besondere Aufmerksamkeit: „Maintain and resubmit orders when connection is restored“ ist standardmäßig aktiv. Orders, die während eines Verbindungsverlusts eingehen, werden gespeichert und nach der Wiederherstellung automatisch übertragen. Für einen Bot kann das heißen, dass ein veraltetes Signal Minuten später ausgeführt wird. Entscheiden Sie bewusst, ob Sie das wollen.

Wie sichern Risikoschicht und Not-Aus einen IBKR-Bot ab?

Die Risikoschicht sitzt zwischen Strategie und OMS und prüft jede Order-Absicht nach festen Regeln, bevor eine Order-ID vergeben wird. Sinnvoll sind wenige, harte Grenzen, die als Konfiguration und nicht im Strategiecode stehen:

• maximale Stückzahl oder maximaler Nominalwert je Order
• maximale Position je Instrument und gesamt
• maximale Zahl offener Orders und Orders pro Minute
• Preisband: Limitpreis nicht weiter als ein festgelegter Abstand vom aktuellen Kurs
• Tagesverlustgrenze auf Basis der laufenden P&L
• Handelsfenster: keine neuen Orders in den Reset-Zeiten oder kurz vor Handelsschluss

Für größere Orders kann die Risikoschicht mit whatIf eine Vorschau anfordern. TWS führt dann eine Margin-Prüfung durch, ohne die Order auszuführen, und liefert im OrderState die erwartete Margin-Wirkung sowie Kommissionen und Gebühren.

Die Prüfungen von IBKR ersetzen Ihre eigenen Grenzen nicht. Ablehnungen wegen Ordergröße oder Preisabstand schützen den geordneten Markt, nicht Ihre Positionslimits. Auch die Order Precautions in TWS, die API-Orders anhalten können, sind eine zweite Linie und kein Risikomanagement.

Der Not-Aus besteht aus mehreren Schritten. Erstens sperrt die Risikoschicht alle neuen Orders. Zweitens storniert reqGlobalCancel alle offenen Orders; laut IBKR ausdrücklich auch die direkt in TWS erteilten. Drittens prüft der Bot über offene und abgeschlossene Orders, ob wirklich nichts mehr im Markt liegt. Viertens entscheidet eine vorher festgelegte Regel, ob Positionen geschlossen werden, denn ein Storno schließt keine Position. Fünftens geht ein Alarm an einen Menschen. Wie Sie das vollständig aufbauen, beschreibt der Artikel zum Kill-Switch für Trading-Bots.

Konto- und Positionsdaten: Takt und Abgleich.

reqAccountUpdates liefert dieselben Werte wie das Kontofenster in TWS. Ohne Positionsänderung aktualisiert IBKR diese Daten nur alle drei Minuten, und die Funktion bedient nur ein Konto gleichzeitig. Für eine Tagesverlustgrenze, die bei schnellen Bewegungen greifen soll, ist das zu langsam. Die P&L-Funktionen reqPnL für das Konto und reqPnLSingle für einzelne Positionen liefern die Werte des Portfoliofensters; Einzelpositionen laut Doku etwa einmal pro Sekunde. Für die Konto-P&L muss in TWS die Option „Prepare portfolio PnL data when downloading positions“ aktiv sein.

Positionen über mehrere Konten liefert reqPositions: zuerst alle Positionen, dann positionEnd, danach Updates bei jeder Änderung. Sinnvoll ist eine klare Arbeitsteilung: Die Risikoschicht nutzt reqPnL und eigene Berechnungen aus Ausführungen, die Kontowerte aus reqAccountUpdates dienen der Kontrolle von Margin und Cash.

Der Abgleich ist der Moment, in dem der Bot seine eigene Sicht mit der von IBKR vergleicht: beim Start, nach jedem Reconnect und in festen Abständen. Er umfasst offene Orders, Positionen und die Ausführungen des Tages. Weicht die Datenbank ab, bleibt der Bot im Schutzmodus und sendet keine neuen Orders, bis die Differenz erklärt ist. Den Ablauf bei unklarem Order-Status im Detail beschreibt der Artikel Positionsabgleich für Trading-Bots.

Betrieb: Reset-Fenster, Logs, Monitoring.

IB Gateway und TWS sind laut IBKR für einen täglichen Neustart ausgelegt, etwa um Kontraktdefinitionen neu zu laden. Mit Auto-Restart entfällt die tägliche Anmeldung; einmal pro Woche ist trotzdem eine manuelle Anmeldung mit zweitem Faktor nötig. Den Zeitpunkt beschreibt die IBKR-Doku nicht einheitlich (Server-Reset in der Nacht auf Sonntag bzw. ein Zyklus, der montags beginnt). Planen Sie die Anmeldung vor dem ersten Handelszeitpunkt der Woche ein.

Dazu kommen die täglichen Server-Resets. IBKR schreibt, dass Sie sehr wahrscheinlich mindestens einmal am Tag die Verbindung zu den Servern verlieren. Laut Statusseite liegt das europäische Fenster von Sonntag bis Freitag bei 06:25 bis 07:45 Uhr CET, das nordamerikanische bei 00:15 bis 01:45 Uhr ET, samstags gilt 00:00 bis 02:00 Uhr ET (Stand Oktober 2026). Während des Resets können Anmeldung und Order-Verwaltung unterbrochen sein; native Orders laufen weiter, Ausführungsmeldungen und simulierte Orders kommen verzögert. IBKR rät davon ab, in diesen Zeiten zu handeln. Der Bot reagiert auf die Systemcodes: 1100 heißt Verbindung verloren, 1101 wiederhergestellt mit verlorenen Marktdaten-Abos, 1102 wiederhergestellt mit erhaltenen Abos. Nach 1101 abonniert der Marktdaten-Adapter neu, nach jedem Reset läuft der Abgleich.

Das API-Log ist Ihr Nachweis, was der Bot tatsächlich gesendet hat. Es ist standardmäßig ausgeschaltet und wird in der Global Configuration unter API über „Create API Message Log File“ aktiviert; das Logging-Level sollte vor einem Vorfall auf „Detail“ stehen. Die Dateien heißen api.[clientId].[Wochentag].log, sind lokal verschlüsselt und können groß werden. Ergänzend schreibt der Bot ein eigenes strukturiertes Log, in dem jede Order mit Order-ID, permId und execId verknüpft ist.

Das Monitoring überwacht mindestens: Läuft der Gateway-Prozess, ist der Connector im Zustand bereit, wann kam der letzte Kurs, gibt es Orders, die ungewöhnlich lange ohne Bestätigung hängen, stimmen Soll- und Ist-Positionen. Alarme laufen über einen Kanal, der nicht vom Bot-Server abhängt.

Typische Fehler in der Trading-Bot-Architektur und Risiken.

Viele Probleme in IBKR-Bots entstehen an den Übergängen zwischen Komponenten, nicht in der Strategie:

• Strategie ruft placeOrder direkt auf. Dann gibt es keine zentrale Stelle für Limits, Not-Aus und Protokoll.
• Senden vor nextValidId. Aufrufe gehen verloren, der Bot hält sie für gesendet.
• Mehrere Prozesse ohne Client-ID-Schema oder ohne Master Client ID, sodass die Überwachung die Orders des Order-Prozesses nicht sieht.
• Risiko auf Basis von reqAccountUpdates. Die Werte können drei Minuten alt sein.
• Statusmeldungen und Fills nicht idempotent verarbeitet. Doppelte orderStatus-Meldungen oder Korrekturen von Ausführungen verfälschen Positionen.
• Kein eigener Speicher. Nach einem Neustart weiß der Bot nicht, welche Orders er gestern erteilt hat.
• Automatisches Nachsenden nach Verbindungsverlust nicht bedacht und Reset-Fenster nicht eingeplant.
• Not-Aus nie getestet, oder er storniert im gemischten Betrieb unbemerkt auch die manuellen Orders eines Menschen.

Auch eine saubere Architektur senkt nur Betriebsrisiken, nicht das Marktrisiko. Eine fehlerhafte Regel wird in Sekunden vielfach ausgeführt, Kurslücken überspringen Stopps, und bei gehebelten Produkten wie Futures oder verkauften Optionen sind Verluste über den Einsatz hinaus möglich. Im Paper-Konto simuliert IBKR laut eigener Doku Stopps und andere komplexe Ordertypen immer, die Ausführung kann sich daher vom Live-Konto unterscheiden. Ein Bot braucht außerdem Wartung, Tests nach jedem Update von Gateway und API und eine Person, die Verantwortung für den Live-Betrieb übernimmt. Eine Gewinnzusage ergibt sich aus keiner Architektur.

Was Sie jetzt konkret tun können.

Vor der ersten Zeile Strategiecode:

1. Komponenten aufschreiben. Übernehmen Sie die Tabelle oben und notieren Sie zu jeder Zeile, welches Modul oder welcher Prozess sie übernimmt.
2. Client-IDs festlegen. Ein Prozess sendet Orders, die übrigen lesen. Setzen Sie die Master Client ID in der Global Configuration für die Überwachung.
3. Startreihenfolge definieren. Gateway, Verbindung, nextValidId, Abgleich, Marktdaten, dann erst die Strategie.
4. Limits als Konfiguration. Ordergröße, Position, Orderrate, Preisband, Tagesverlust, Handelsfenster.
5. Not-Aus im Paper-Konto testen, einschließlich der Prüfung, dass danach wirklich keine Order mehr offen ist.
6. Protokolle einschalten. API-Log auf „Detail“, dazu ein eigenes Order- und Ausführungsjournal.
7. Fehlerpfade gezielt auslösen. Gateway beenden, Netzwerk trennen, abgelehnte Orders provozieren und prüfen, ob der Bot in den Schutzmodus geht.

Marcel Gautsche aus Stuttgart entwickelt seit über zehn Jahren automatisierte Trading-Systeme, darunter Python-Systeme für Interactive Brokers nach Kundenvorgaben. Er testet mit echten Kosten und betreibt Systeme auf Wunsch auf einem VPS mit Monitoring. Die Live-Aktivierung erfolgt durch Sie im eigenen Konto; Marcel handelt nicht auf Kundenkonten und verkauft keine Strategien.

Häufige Fragen.

Welche Komponenten braucht ein Trading-Bot für Interactive Brokers?

Ein produktiver IBKR-Bot braucht IB Gateway oder TWS, eine Verbindungsschicht mit Reconnect und Drosselung, einen Marktdaten-Adapter, die Strategie, eine Risikoschicht mit Not-Aus, ein Order-Management für IDs, Status und Ausführungen, eine Persistenz sowie Monitoring und Logs. Entscheidend ist, dass die Strategie keine Orders direkt an die API sendet, sondern jede Order über Risikoschicht und Order-Management läuft.

Was ist die Master Client ID bei Interactive Brokers?

Die Master Client ID wird in der Global Configuration von TWS oder IB Gateway eingestellt. Nur eine API-Verbindung mit dieser ID erhält auch Orders und Ausführungen anderer API-Clients. Ohne sie erhält jede Verbindung laufend nur ihre eigenen Orders. Client-ID 0 bekommt zusätzlich manuell in TWS erteilte Orders. Damit ein getrennter Überwachungsprozess laufend alle Orders und Ausführungen sieht, braucht er deshalb diese ID.

Warum muss ein IBKR-Bot auf nextValidId warten?

Nach dem Öffnen des Sockets handeln Client und TWS zuerst die Protokollversion aus und tauschen Sitzungsdaten aus. Laut IBKR dient der Callback nextValidId üblicherweise als Signal, dass die Verbindung fertig ist; Aufrufe davor können verworfen werden. Außerdem liefert er die nächste gültige Order-ID, die das Order-Management für neue Orders braucht. Ein Bot sollte deshalb erst danach Orders oder Datenanfragen senden.

Reicht reqAccountUpdates für die Risikoüberwachung eines Bots?

Für schnelle Grenzen meist nicht. reqAccountUpdates aktualisiert ohne Positionsänderung nur alle drei Minuten und bedient nur ein Konto gleichzeitig. Für eine Tagesverlustgrenze eignen sich reqPnL und reqPnLSingle besser, ergänzt durch eigene Berechnungen aus den Ausführungen. Die Kontowerte aus reqAccountUpdates bleiben nützlich, um Margin und Cash zu kontrollieren.

Wie stoppt man alle offenen Orders eines IBKR-Bots auf einmal?

Die TWS API bietet dafür reqGlobalCancel. Der Aufruf storniert alle offenen Orders, auch die direkt in TWS erteilten. Positionen schließt er nicht. Ein vollständiger Not-Aus sperrt zusätzlich neue Orders, prüft danach, ob wirklich nichts mehr offen ist, entscheidet nach fester Regel über das Schließen von Positionen und alarmiert einen Menschen. Testen Sie den Ablauf im Paper-Konto.

Quellen und Stand.

• Establishing an API connection — Interactive Brokers (TWS API Documentation)
• Pacing Limitations: Introduction — Interactive Brokers (TWS API Documentation)
• ClientId 0 and the Master Client ID — Interactive Brokers (TWS API Documentation)
• Account Updates: Introduction — Interactive Brokers (TWS API Documentation)
• Cancel All Open Orders — Interactive Brokers (TWS API Documentation)
• TWS API Limitations — Interactive Brokers (TWS API Documentation)
• The IB Gateway — Interactive Brokers (TWS API Documentation)
• System Message Codes — Interactive Brokers (TWS API Documentation)

Stand: 22. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie planen einen Bot für Interactive Brokers und wollen die Architektur von Anfang an belastbar aufsetzen? Unverbindlich anfragen — wir klären Komponenten, Client-IDs, Risikolimits, Tests im Paper-Konto und den Betrieb mit Monitoring. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.