Trading-Bot für IBKR entwickeln lassen: der Projektablauf.
Ein Trading-Bot für Interactive Brokers (IBKR) entsteht in einem seriösen Projekt in festen Phasen: Regelwerk schriftlich fixieren, Schnittstelle wählen, Daten und Kosten prüfen, mit echten Gebühren backtesten, im Paper-Konto testen, abnehmen und erst dann durch den Kunden selbst live schalten. Der Entwickler liefert Software für das eigene Konto des Kunden; er handelt nicht auf diesem Konto und entscheidet nicht über Strategie oder Anlage. Dieser Artikel beschreibt den Ablauf Stand Oktober 2026 so, dass Sie ihn als Leitfaden für Ihr eigenes Vorhaben nutzen können: was in ein Pflichtenheft gehört, was Sie bei IBKR selbst vorbereiten müssen (IBKR-Pro-Konto, API-fähige Zwei-Faktor-Authentifizierung, Marktdaten-Abos und Freigaben), wie Tests aussehen, die etwas aussagen, und welche Lizenz- und Datenfragen Sie vor dem Start klären sollten. Am Ende stehen Warnsignale, an denen Sie unseriöse Angebote erkennen, und eine kurze Liste der nächsten Schritte.
Hinweis: Dieser Beitrag gibt den Rechts- und Steuerstand zum unten angegebenen Datum allgemein wieder. Er ist keine Rechts- oder Steuerberatung und ersetzt nicht die Prüfung Ihres Einzelfalls durch eine Rechtsanwältin, einen Rechtsanwalt, eine Steuerberaterin oder einen Steuerberater. Alle Angaben ohne Gewähr für Vollständigkeit und Aktualität.
Wie läuft ein Projekt für einen IBKR-Trading-Bot ab?
Ein Trading-Bot, also ein automatisiertes, algorithmisches Handelssystem, ist ein Programm, das nach festen Regeln Marktdaten auswertet, Orders an den Broker sendet und Positionen überwacht. Bei Interactive Brokers geschieht das meist über die TWS API, die über eine laufende Trader Workstation (TWS) oder das schlankere IB Gateway mit dem Konto verbunden ist. Die Programmierung ist dabei oft nicht der schwierigste Teil. Häufig scheitern Projekte an unklaren Regeln, fehlenden Freigaben im Konto oder an Tests, die echte Kosten ausblenden.
Ein geordneter Ablauf verhindert, dass solche Lücken erst im Live-Betrieb auffallen. Die folgende Tabelle zeigt die Phasen eines geordneten IBKR-Projekts mit dem jeweiligen Ergebnis und dem Beitrag des Kunden.
| Phase | Inhalt | Ergebnis | Beitrag des Kunden |
|---|---|---|---|
| 1. Regelwerk | Einstieg, Ausstieg, Positionsgröße, Risikogrenzen, Handelszeiten schriftlich beschreiben | Pflichtenheft mit prüfbaren Regeln | Strategie und alle Parameter |
| 2. Schnittstelle | TWS API, Web API oder Drittplattform wählen, Betriebsmodell festlegen | Architektur-Entscheidung | Anforderungen an Betrieb und Verfügbarkeit |
| 3. Daten und Kosten | Benötigte Marktdaten, Abos, historische Daten und Gebührenmodell prüfen | Daten- und Kostenliste | Abos im eigenen Konto abschließen |
| 4. Backtest | Regeln auf historischen Daten mit Kommissionen, Spreads und Slippage testen | Testbericht mit Annahmen | Bericht prüfen, Regeln bestätigen oder ändern |
| 5. Paper-Test | Bot im Paper-Konto über mehrere Wochen laufen lassen, Fehlerfälle provozieren | Protokoll aller Orders, Fehler und Abweichungen | Paper-Zugang bereitstellen, Verhalten beobachten |
| 6. Abnahme | Pflichtenheft Punkt für Punkt gegen das Verhalten prüfen | Abnahmeprotokoll | Freigabe oder Mängelliste |
| 7. Live-Aktivierung | Bot mit eigenem Benutzer und kleinen Größen live schalten | Laufendes System | Aktivierung im eigenen Konto |
| 8. Betrieb | Neustarts, wöchentliche Anmeldung, Monitoring, Alarme, Updates | Betriebshandbuch, auf Wunsch VPS mit Überwachung | Anmeldung mit Zwei-Faktor, Reaktion auf Alarme |
Die Reihenfolge ist kein Formalismus. Jede Phase liefert ein Dokument, auf das sich beide Seiten später berufen können. Wer Phase 1 überspringt, diskutiert in Phase 6 darüber, was eigentlich bestellt war.
Was gehört in ein Pflichtenheft für einen IBKR-Trading-Bot?
Ein Bot kann nur umsetzen, was eindeutig beschrieben ist. „Kaufen, wenn der Trend dreht“ ist keine Regel, sondern eine Idee. Eine Regel nennt Instrument, Zeiteinheit, Bedingung, Ordertyp und Größe so genau, dass zwei Entwickler unabhängig voneinander dasselbe Programm schreiben würden. Die Strategie kommt dabei vom Kunden. Der Entwickler übersetzt sie in Code, stellt Rückfragen zu Lücken und weist auf technische Folgen hin, bewertet aber nicht, ob die Strategie Geld verdient.
Ein brauchbares Pflichtenheft für einen IBKR-Bot enthält mindestens diese Punkte:
- Instrumente: Aktien, Futures, Optionen oder Forex, mit Börse und Währung; bei Futures auch die Regel für den Kontraktwechsel.
- Signale: exakte Formeln, Datenquelle, Bar-Größe, Berechnung auf geschlossenen oder laufenden Bars.
- Orders: Ordertyp, Limit-Abstand, Time-in-Force, Verhalten bei Teilausführung und Ablehnung.
- Risikogrenzen: maximale Positionsgröße, Tagesverlustgrenze, maximale Zahl offener Orders, Notaus.
- Zeiten: Handelsfenster, Verhalten rund um die täglichen Server-Resets von IBKR und an Feiertagen.
- Fehlerfälle: was bei Verbindungsabbruch, fehlenden Daten oder unklarem Order-Status passiert.
- Berichte: welche Protokolle, Benachrichtigungen und Kennzahlen der Kunde sehen will.
Die Fehlerfälle sind der Teil, den Auftraggeber am häufigsten unterschätzen. Ein Bot verbringt die meiste Zeit nicht mit Signalen, sondern mit Warten, Wiederverbinden und Abgleichen. Warum genau dort viele Systeme scheitern, beschreibt der Artikel Warum 90 % der Trading-Bots scheitern.
In derselben Phase fällt die Wahl der Schnittstelle. Für Python-Systeme ist die TWS API über IB Gateway der verbreitete Weg. Die Web API, eine REST-Schnittstelle über HTTPS, eignet sich für schlankere Anwendungen, hat aber eigene Sitzungsregeln und Limits. Drittplattformen mit IBKR-Anbindung bringen eigene Einschränkungen mit, die vorab zu prüfen sind.
Was Sie bei IBKR selbst vorbereiten (Checkliste).
Viele Schritte kann nur der Kontoinhaber erledigen, weil sie im Client Portal mit seinen Zugangsdaten stattfinden. Wer sie vor dem Projektstart abhakt, spart Wochen. Stand Oktober 2026 gilt laut IBKR-Dokumentation:
- IBKR-Pro-Konto: Die TWS API setzt ein eröffnetes und finanziertes IBKR-Pro-Konto voraus. Konten mit provisionsfreiem Handel (IBKR Lite) haben keinen API-Zugang.
- Zwei-Faktor-Methode: Mit der API funktionieren nur IB Key, Handy Key, SMS und Digital Security Card+. Security Code Card und Online Code Card werden nicht unterstützt.
- Marktdaten-Abos: Die API braucht passende, meist kostenpflichtige Abos im Client Portal; bei Einzelkonten verlangt IBKR dafür 500 USD Guthaben zusätzlich zu den Abo-Kosten. Daten, die TWS kostenlos anzeigt, sind nicht automatisch über die API verfügbar.
- Market Data API Acknowledgement: Ohne dieses im Client Portal digital unterschriebene Formular liefert die API keine Marktdaten, auch nicht an Drittsoftware.
- Automation and Software Disclosure: Wer mit US-Futures-Rechten per API handelt, bekommt am Tag nach dem ersten API-Trade die API User Activity Certification zugewiesen. Wer Orders automatisch ohne manuelle Freigabe sendet, wählt dort die Option für automatisierte Systeme, nennt die eingesetzte Software und gibt an, wer die Order-Übermittlung steuert.
- Eigener Benutzer für den Bot: Ein Benutzername kann nur in einer Handelsanwendung gleichzeitig angemeldet sein. Ein zusätzlicher Benutzer für TWS oder IB Gateway verhindert, dass eine Anmeldung im Client Portal den Bot nach dem nächsten Server-Reset vom Netz trennt. Marktdaten-Abos werden je Live-Benutzer eingerichtet.
- Paper-Konto: Zugang zum Paper-Konto des eigenen Kontos für die Testphase; Abos lassen sich mit einem Paper-Benutzer teilen.
IBKR ermöglicht außerdem Benutzer mit eingeschränkten Rechten, die über das Account-Configuration-Team eingerichtet werden; als Beispiel nennt IBKR einen Entwickler, der am Live-Konto ohne Auszahlungs- oder direkte Handelsrechte arbeitet. Ob und in welchem Umfang ein Entwickler überhaupt Zugriff braucht, gehört ins Pflichtenheft. In vielen Projekten reicht ein Paper-Zugang, und den Live-Betrieb übernimmt der Kunde selbst.
Tests: Backtest mit echten Kosten und Paper-Betrieb.
Ein Backtest spielt die Regeln auf historischen Daten durch. Er sagt nur dann etwas aus, wenn er die Kosten so abbildet, wie sie im Konto anfallen: Kommissionen nach dem tatsächlich gewählten Gebührenmodell, Börsen- und Regulierungsgebühren, Spread und eine realistische Annahme für Slippage, also die Differenz zwischen erwartetem und tatsächlichem Ausführungspreis. Bei IBKR kommen Details hinzu, die das Ergebnis spürbar verändern können, etwa dass Änderungen einer Order als Storno und Neuaufgabe gelten und Mindestgebühren dadurch an manchen Börsen mehrfach anfallen können.
Ebenso wichtig ist die Frage, wie viele Varianten getestet wurden. Wer hundert Parameterkombinationen probiert und die beste zeigt, hat vor allem eine Kurve an die Vergangenheit angepasst. Ein ehrlicher Testbericht nennt Datenzeitraum, Datenquelle, Kostenannahmen, Zahl der getesteten Varianten und einen Zeitraum außerhalb der Optimierung. Wie der Weg vom Test zum Live-System aussieht, zeigt der Artikel vom Backtest zur Live-Strategie.
Der Paper-Test prüft danach die Technik: Verbindung, Order-Logik, Fehlerbehandlung, Protokolle. IBKR schreibt selbst, dass das Ausführungsverhalten im Paper-Konto nicht repräsentativ für echte Marktbedingungen ist und Paper-Konten nur dazu dienen sollten, die Funktionsweise von Werkzeugen zu verstehen. Füllungen werden vom besten Geld- und Briefkurs simuliert, Stop-Orders und komplexe Orders sind im Paper-Konto immer simuliert, manche Ordertypen fehlen ganz. IBKR rät außerdem, eine Order-Idee zuerst manuell in TWS zu testen, weil eine Kombination, die TWS nicht kann, auch über die API nicht funktioniert.
Ein sinnvoller Paper-Betrieb läuft deshalb über mehrere Wochen und enthält gezielt provozierte Störungen: Gateway beenden, Netz trennen, Order ablehnen lassen, Daten-Abo entziehen. Erst wenn der Bot all das protokolliert und sich danach korrekt abgleicht, ist er reif für die Abnahme.
Wer was verantwortet: Software, Konto, Live-Freigabe.
Saubere Rollen schützen beide Seiten. Wenn ich Trading-Systeme für IBKR entwickle, liefere ich Software, Tests und auf Wunsch den technischen Betrieb. Ich handle nicht auf Kundenkonten, verwalte kein Kundengeld, verkaufe keine Strategien und gebe keine Anlageempfehlungen. Die Live-Aktivierung nimmt der Kunde in seinem eigenen Konto vor.
Diese Trennung ist mehr als eine Formsache. Die BaFin beschreibt, dass die Verwaltung fremden Vermögens mit Entscheidungsspielraum als Finanzportfolioverwaltung erlaubnispflichtig ist (§ 32 KWG bzw. § 15 WpIG). Wer also für andere über Anlagen entscheidet oder auf fremden Konten handelt, bewegt sich in der Regel in einem regulierten Bereich. Ein Entwickler, der ein vom Kunden vorgegebenes Regelwerk programmiert, tut etwas anderes. Wo genau die Grenze im Einzelfall verläuft, klären Sie im Zweifel mit einem Anwalt.
Eine zweite Abgrenzung betrifft fertige Produkte. Für Drittanbieter, deren Software mit Kundenkonten interagiert, ohne dass eine formale Beziehung zu IBKR besteht, hat IBKR eigene Regeln. Solche Anbieter durchlaufen ein Onboarding mit mehrwöchiger Compliance-Prüfung, und von Anbietern automatisierter Handelslösungen erwartet IBKR eine Registrierung bei der Finanzaufsicht in allen bedienten Regionen, sofern nicht etwa ein Rechtsgutachten begründet, warum keine nötig ist. Eine individuell entwickelte Software, die der Kontoinhaber selbst betreibt, ist kein solches Produkt. Wer dagegen einen Bot an viele Nutzer vertreiben will, muss diese Anforderungen früh einplanen.
Im Betrieb bleibt der Kunde in der Verantwortung für sein Konto. Dazu gehört die wöchentliche Neuanmeldung: IBKR empfiehlt API-Nutzern für TWS und IB Gateway die Einstellung „Auto restart“, einmal pro Woche (laut IBKR-Doku je nach Seite nach dem Server-Reset in der Nacht auf Sonntag bzw. zu Beginn eines montags startenden Zyklus) ist aber trotzdem eine manuelle Anmeldung mit Zwei-Faktor nötig. Details stehen im Artikel IB Gateway im Dauerbetrieb. Das verbreitete Community-Werkzeug IBC zur Automatisierung des Logins ist inzwischen archiviert (Stand Oktober 2026) und wird nicht mehr gepflegt. Sauberer ist deshalb ein Betriebskonzept, bei dem der Kontoinhaber die Anmeldung selbst vornimmt und der Entwickler seine Zugangsdaten nicht kennt.
Lizenz- und Datenfragen: GPL und Marktdaten-Weitergabe.
Zwei Punkte sollten vor Vertragsschluss auf der Prüfliste stehen. Der erste ist die Lizenz der TWS API: Laut IBKR-Changelog steht sie ab Version 10.49 vom 03.08.2026 unter der GNU General Public License (GPL). Die GPL knüpft Pflichten vor allem an die Weitergabe von Software. Für ein System, das nur im eigenen Konto des Auftraggebers läuft, ist das eine andere Lage als für ein Produkt, das verkauft oder an Dritte verteilt wird. Welche Folgen die GPL für Ihr konkretes Vorhaben hat, ist eine Rechtsfrage und im Einzelfall anwaltlich zu klären.
Der zweite Punkt sind Marktdaten. Die Installationsseite der TWS API untersagt, die API ohne vorherige schriftliche Genehmigung von IBKR zur Weitergabe von Marktdaten oder anderen lizenzierten Informationen an Dritte oder nicht registrierte Kunden zu nutzen. Ein Bot, der Kurse nur für das eigene Konto verarbeitet, ist davon in der Regel nicht betroffen. Ein Dashboard, das dieselben Kurse an Partner, Kunden oder eine Community ausliefert, braucht dagegen eine Genehmigung von IBKR.
- Soll die Software nur im eigenen Konto laufen oder später an andere gehen?
- Sehen Personen außerhalb des Kontos Kurse, Charts oder abgeleitete Daten?
- Wem gehören Quellcode und Nutzungsrechte nach der Abnahme?
- Welche Bibliotheken mit welchen Lizenzen stecken im Projekt?
Die Antworten gehören ins Pflichtenheft. Sie entscheiden über Architektur, Vertrag und gegebenenfalls über eine rechtliche Prüfung vor dem Start.
Grenzen und Risiken eines automatisierten Systems.
Ein Bot führt Regeln schneller und konsequenter aus als ein Mensch. Er macht eine Strategie aber nicht besser. Ein Regelwerk, das im Backtest nur durch Überanpassung gut aussieht, verliert live genauso, nur automatisch. Bei gehebelten Produkten wie Futures, verkauften Optionen oder Forex können Verluste das eingesetzte Kapital übersteigen; ein Totalverlust ist möglich.
Hinzu kommen technische und betriebliche Risiken:
- Verbindung: IBKR setzt täglich Server zurück; in diesem Zeitfenster kann das Konto kurzzeitig nicht erreichbar sein. Nach einer Wiederverbindung müssen Marktdaten unter Umständen neu angefordert werden.
- Order-Status: Zwischen Absenden und Bestätigung gibt es Zustände, in denen unklar ist, ob eine Order ausgeführt wurde. Ein Bot muss Positionen mit dem Konto abgleichen, statt sich auf seinen eigenen Zustand zu verlassen.
- Marktereignisse: Kurslücken, Handelsunterbrechungen und dünne Märkte führen zu Ausführungen weit vom erwarteten Preis.
- Änderungen bei IBKR: API-Versionen, Dokumentation und Regeln ändern sich laufend. Software braucht deshalb Pflege.
- Menschliche Fehler: falsche Parameter, versehentlich live statt Paper, verpasste wöchentliche Anmeldung.
Gegenmittel sind bekannt, aber kein Schutz vor jedem Fall: harte Risikogrenzen im Code, ein Notaus, Alarme bei Abweichungen, kleine Positionsgrößen zu Beginn und ein Betriebshandbuch, das beschreibt, wer wann was tut. Spricht ein Anbieter diese Risiken nicht von sich aus an, ist das ein Warnsignal.
Woran Sie einen seriösen Entwickler erkennen und was Sie jetzt tun können.
Seriöse Entwickler und Dienstleister fragen mehr, als sie versprechen. Sie wollen das Regelwerk schriftlich sehen, sprechen über Fehlerfälle und Kosten, bevor sie über Signale reden, und legen offen, was sie nicht übernehmen. Warnsignale sind dagegen eindeutig:
- Rendite- oder Trefferquoten-Versprechen, „bewährte“ Strategien zum Kauf, Erfolgsbeteiligung am Konto.
- Die Bitte um Benutzername, Passwort oder Zwei-Faktor-Code für Ihr Live-Konto.
- Das Angebot, den Bot selbst auf Ihrem Konto zu betreiben und Entscheidungen zu treffen.
- Kein Pflichtenheft, keine Testberichte, kein Abnahmeprotokoll, kein Quellcode.
- Kein Impressum, keine überprüfbare Identität, Druck zur schnellen Entscheidung.
Konkret können Sie jetzt drei Dinge tun. Erstens: Schreiben Sie Ihr Regelwerk auf eine Seite, mit Instrument, Signal, Order, Größe und Ausstieg. Zweitens: Gehen Sie die IBKR-Checkliste oben durch und klären Sie Kontotyp, Zwei-Faktor-Methode, Abos und Freigaben. Drittens: Notieren Sie, ob die Software nur für Ihr Konto gedacht ist oder später weitergegeben werden soll.
Mit diesen Unterlagen lässt sich in einem Erstgespräch klären, ob das Vorhaben technisch sinnvoll umsetzbar ist, welche Phasen nötig sind und welcher Testumfang passt. Das Angebot entsteht danach individuell, je nach Umfang und Betriebsmodell, und das Erstgespräch selbst ist kostenlos. Für die Umsetzung finden Sie die Details auf der Seite Trading-Systeme entwickeln lassen.
Häufige Fragen.
Was muss ich vorbereiten, bevor ich einen Trading-Bot für Interactive Brokers entwickeln lasse?
Sinnvoll sind ein schriftliches Regelwerk mit Instrument, Signal, Ordertyp, Größe und Ausstieg sowie ein vorbereitetes Konto: eröffnetes und finanziertes IBKR-Pro-Konto, eine API-taugliche Zwei-Faktor-Methode wie IB Key, die nötigen Marktdaten-Abos, das unterschriebene Market Data API Acknowledgement und ein zusätzlicher Benutzer für den Bot. Mit diesen Unterlagen lässt sich der Aufwand im Erstgespräch realistisch einschätzen.
Braucht der Entwickler meine IBKR-Zugangsdaten?
Für das Live-Konto in aller Regel nicht. Entwicklung und Tests laufen im Paper-Konto, die Live-Aktivierung und die wöchentliche Zwei-Faktor-Anmeldung übernimmt der Kontoinhaber. Wenn ein Zugriff am Live-Konto nötig ist, kann IBKR Benutzer mit eingeschränkten Rechten einrichten, etwa ohne Auszahlungsrecht. Verlangt jemand Passwort oder Zwei-Faktor-Codes Ihres Hauptbenutzers, ist das ein klares Warnsignal.
Ist ein Test im IBKR-Paper-Konto aussagekräftig?
Für die Technik ja, für die Ertragskraft nein. Das Paper-Konto zeigt, ob Verbindung, Order-Logik, Fehlerbehandlung und Protokolle funktionieren. IBKR schreibt jedoch selbst, dass das Ausführungsverhalten dort nicht repräsentativ ist: Füllungen werden vom besten Kurs simuliert, Stops und komplexe Orders sind immer simuliert, einige Ordertypen fehlen. Ein ehrlicher Test kombiniert deshalb Backtest mit echten Kosten, Paper-Betrieb und einen vorsichtigen Live-Start mit kleinen Größen.
Was kostet es, einen IBKR-Trading-Bot entwickeln zu lassen?
Das hängt vom Umfang ab: Zahl der Instrumente, Komplexität der Regeln, Testumfang, Schnittstelle und ob ein betreuter Betrieb mit Monitoring gewünscht ist. Hinzu kommen laufende Kosten im eigenen Konto, vor allem Kommissionen, monatliche Marktdaten-Abos und gegebenenfalls ein Server. Ein seriöses Angebot entsteht deshalb individuell nach einem Gespräch über das Regelwerk, nicht als Pauschalpreis ohne Kenntnis des Regelwerks.
Quellen und Stand.
- TWS API: Requirements — Interactive Brokers
- TWS API: Daily and Weekly Reauthentication — Interactive Brokers
- Market Data API Acknowledgement — Interactive Brokers
- Automation and Software Disclosure — Interactive Brokers
- Web API: Trading Access for Third Parties — Interactive Brokers
- TWS API Changelog: August 3, 2026 release (GPL) — Interactive Brokers
- TWS API Software Download (Hinweis zur Datenweitergabe) — Interactive Brokers
- Order Types: Notes and Limitations (Paper Trading) — Interactive Brokers
- Automatisierte und signalbezogene Beratungs- und Handelssysteme — BaFin
Stand: 22. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.
Sie wollen Ihr Regelwerk als Trading-Bot für Interactive Brokers umsetzen lassen? Unverbindlich anfragen — wir klären Regelwerk, Schnittstelle, Testumfang und den Weg in den Live-Betrieb in Ihrem eigenen Konto. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.