IBKR-Paper-Trading für Bots: was der Test zeigt und was nicht.

Das Paper-Konto von Interactive Brokers eignet sich gut, um einen Trading-Bot technisch zu prüfen: Anbindung, Orderlogik, Fehlerbehandlung, Neustarts und Last. Über Ausführungsqualität, Slippage und spätere Ergebnisse sagt es dagegen wenig, denn IBKR simuliert die Fills vom Top of Book, also nur auf Basis des besten Geld- und Briefkurses, simuliert Stops und komplexe Orders und bezeichnet das Ausführungsverhalten selbst als nicht repräsentativ. Dieser Artikel zeigt mit Stand Oktober 2026, welche Unterschiede zum Live-Konto dokumentiert sind, wie Sie Paper-Benutzer und Marktdatenteilung für die Interactive Brokers Paper Trading API einrichten, warum der Fehler 10197 auftaucht und wie ein Testplan vom ersten Funktionstest bis zum Dauerlauf aussieht. Danach folgt, was sich nur live prüfen lässt und wie Sie den Übergang mit begrenztem Risiko planen. Die Angaben stammen aus der IBKR-Dokumentation. Details ändern sich, deshalb gehört ein Abgleich mit der aktuellen Doku zu jedem Projekt.

Was simuliert das IBKR-Paper-Konto?

Ein Paper-Konto ist ein simuliertes Handelskonto. Es steht zur Verfügung, sobald das reguläre Konto genehmigt und finanziert ist; neue Einzelkonten erhalten es laut IBKR automatisch. Orders aus dem Paper-Konto werden an keiner Börse ausgeführt und nicht abgewickelt. Die simulierten Ausführungspreise richten sich aber nach echten Marktpreisen und Größen. Handelsberechtigungen, Marktdatenabos, Basiswährung und weitere Kontoeinstellungen übernimmt das Paper-Konto vom Live-Konto.

Jedes Paper-Konto startet mit 1.000.000 USD simuliertem Kapital. Im Client Portal lässt sich das Kapital jederzeit zurücksetzen, auf bis zum Fünffachen des Werts des Live-Kontos. Anträge vor 16 Uhr New Yorker Zeit greifen am nächsten Geschäftstag. Kontoauszüge des Paper-Kontos finden Sie im Client Portal unter „Reports“, wenn Sie sich mit dem Paper-Login anmelden. Ein praktischer Punkt: Setzen Sie das Paper-Kapital auf den Betrag, mit dem der Bot später live arbeiten soll. Sonst testen Sie Positionsgrößen, Margin-Prüfungen und Risikolimits mit Zahlen, die es im Live-Betrieb nie geben wird.

Für die Erwartung entscheidend ist eine Aussage von IBKR selbst: Paper-Konten beruhen auf einer simulierten Umgebung, das Ausführungsverhalten spiegelt die realen Handelsbedingungen nicht wider, und das Konto sollte ausschließlich dazu dienen, die Funktion der Werkzeuge zu verstehen. Auch die Doku der TWS API weist darauf hin, dass die Paper-Umgebung stärker auf Simulation beruht und sich etwa die Ausführung unterscheiden kann. Für einen Bot heißt das: Das Paper-Konto prüft, ob die Software richtig mit IBKR spricht. Ob die Strategie unter echten Bedingungen trägt, prüft es nicht.

Unterschiede zum Live-Konto im Überblick.

IBKR listet die Abweichungen im Client-Portal-Handbuch und betont, dass die Liste nicht abschließend ist. Die folgende Tabelle fasst die dokumentierten Punkte zusammen und ordnet ein, was sie für einen Bot-Test bedeuten.

Der Serverpunkt wird oft übersehen. Jedes Live-Konto ist einem vorgegebenen IBKR-Server zugeordnet, den IBKR auf Anfrage wechseln kann; neue Kunden ordnet IBKR laut Systemstatus nach Standort oder Handelspräferenzen einem von sechs Rechenzentren zu, zwei davon in Europa. Das Paper-Konto hängt dagegen immer am US-Server. Wer Reaktionszeiten misst oder Wartungsfenster plant, misst im Paper-Konto also eine andere Umgebung als später live.

Paper-Konto für die Interactive Brokers API einrichten.

Den Paper-Benutzernamen finden Sie im Client Portal: Personensymbol oben rechts, „Settings“, dann unter „Account Configuration“ der Punkt „Paper Trading Account“. Dort stehen Paper-Benutzername, Paper-Kontonummer und die Optionen zur Verknüpfung der Marktdaten. IBKR empfiehlt, über „Reset Paper Trading Password“ ein eigenes Passwort für das Paper-Konto zu vergeben.

In der Trader Workstation (TWS) melden sich viele Kontoinhaber mit den Live-Zugangsdaten an und wählen dann das Paper-Konto. Advisors, Broker und deren Kunden, Hedgefonds, Administratoren, Referrer sowie Einwohner Indiens und Japans müssen laut IBKR die Paper-Zugangsdaten verwenden. Für die Web API und für Drittplattformen gilt das für alle: Dort braucht es die direkten Paper-Zugangsdaten. Die Web-API-Doku hält ausdrücklich fest, dass es keinen Schalter zwischen Live- und Paper-Login gibt; man meldet sich mit dem Paper-Benutzer am Client Portal Gateway an.

Für die Verbindung über TWS API oder IB Gateway gehören diese Punkte auf die Checkliste:

• Ports: Standardmäßig nutzt TWS 7497 für Paper und 7496 für Live, IB Gateway 4002 für Paper und 4001 für Live. Die Ports sind änderbar, deshalb taugen sie nicht als alleinige Absicherung.
• API-Einstellungen: „Enable ActiveX and Socket Clients“ aktivieren und „Read-Only API“ abwählen, wenn Orders getestet werden sollen.
• Kontoprüfung im Code: Der Bot liest nach dem Verbinden die Kontonummer aus und bricht ab, wenn sie nicht der hinterlegten Paper-Kontonummer entspricht.
• Getrennte Konfiguration: Paper und Live bekommen eigene Konfigurationsdateien mit Benutzer, Port und Kontonummer, keine Umschaltung per auskommentierter Zeile.
• Realistisches Kapital: Paper-Kapital auf die geplante Live-Größe zurücksetzen.

Die TWS-Oberfläche zeigt deutlich an, dass ein simuliertes Konto aktiv ist. IBKR warnt: Wer diesen Hinweis nicht sieht, handelt im Produktivkonto und haftet für alle ausgeführten Trades. Beim IB Gateway auf einem Server schaut niemand auf die Oberfläche. Die Kontoprüfung im Code ersetzt dort den Blick des Menschen.

Datenteilung und Fehler 10197.

Damit das Paper-Konto Echtzeitkurse bekommt, teilen Sie die Marktdatenabos des Live-Benutzers mit dem Paper-Konto. Jeder Live-Benutzer kann Daten mit genau einem Paper-Konto teilen, und je Live-Konto gibt es ein Paper-Konto. Eingerichtet wird das in den oben genannten Einstellungen zum Paper Trading Account. Ohne gültiges Abo lassen sich über die TWS API mit reqMarketDataType höchstens verzögerte Daten anfordern, die laut Doku 15 bis 20 Minuten alt sind und nicht für jedes Instrument angeboten werden. Für signalgetriebene Tests ist das meist ungeeignet.

Die Teilung hat einen Haken. IBKR erlaubt pro Benutzername nur eine Handelssitzung zur gleichen Zeit. Fehler 10197 („No market data during competing session“) bedeutet laut Fehlercode-Tabelle, dass der Benutzer gleichzeitig im Paper- und im Live-Konto angemeldet ist und in beiden Live-Marktdaten anfordert. Vorrang hat das Live-Konto. Zwei verwandte Fälle beschreibt die TWS-API-Doku: Eine Paper-Sitzung in TWS oder IB Gateway erhält keine Marktdaten, wenn der Live-Benutzer, von dem sie Daten teilt, im Client Portal angemeldet ist. Und eine TWS- oder Gateway-Sitzung, deren Benutzername während der Sitzung im Client Portal verwendet wurde, verbindet sich nach der nächsten Trennung, etwa dem Server-Reset, nicht automatisch neu.

Typisches Beispiel: Der Bot läuft im Paper-Konto auf einem VPS. Tagsüber schauen Sie mit demselben Live-Benutzer ins Client Portal oder handeln manuell in der TWS. Ab diesem Moment bekommt der Bot keine Kurse mehr, die Strategie sieht keine Signale, und im Log steht 10197. Ohne Überwachung sieht das aus wie ein ruhiger Markttag. Drei Wege helfen:

• Zusätzlicher Benutzername: Für Client Portal und manuellen Handel einen weiteren Benutzer anlegen. Marktdatenabos werden je Live-Benutzer separat eingerichtet, das kann zusätzliche Kosten bedeuten.
• Zeitliche Trennung: Testläufe in Zeiten legen, in denen der Live-Benutzer nicht aktiv ist.
• Alarm statt Stille: Der Bot behandelt 10197 und ausbleibende Kurse als Störung und meldet sie, statt still zu warten.

Testplan: Logik, Fehlerpfade, Neustarts, Last.

Ein belastbarer Paper-Test besteht aus Stufen mit schriftlichen Prüfkriterien. Sinnvoll ist, jede Stufe im Paper-Konto abzuschließen, bevor überhaupt über Live-Betrieb gesprochen wird. Die Reihenfolge ist bewusst gewählt: Erst muss die Logik stimmen, dann die Fehlerbehandlung, dann der Betrieb.

1. Funktionstests: Jeden Weg durch die Orderlogik einmal gezielt auslösen: Einstieg, Teilausführung, Aufstocken, Ausstieg, Änderung, Storno. Prüfkriterium: Positionen, offene Orders und Ausführungen im Bot stimmen mit TWS und Paper-Kontoauszug überein. Wie dieser Abgleich aufgebaut wird, beschreibt der Artikel zum Positionsabgleich im Trading-Bot. Ergänzend liefern WhatIf-Abfragen (Order mit gesetztem WhatIf-Flag) die geschätzte Margin-Wirkung sowie Kommissionen und Gebühren, ohne dass eine Order ausgeführt wird.
2. Fehlerpfade: Fehler bewusst provozieren: Preis außerhalb der Tick-Größe (110), Instrument ohne passendes Abo (354 oder 10089), doppelte Order-ID (103), bereits belegte Client-ID (326), abgelehnte Order (201), konkurrierende Sitzung (10197). Prüfkriterium: Der Bot erkennt jeden Code, protokolliert ihn und reagiert definiert, also wiederholen, pausieren oder alarmieren, ohne Endlosschleifen.
3. Neustarts und Verbindungsabbrüche: Den Bot-Prozess während einer offenen Order beenden, das Gateway neu starten, die Netzverbindung trennen, einen Server-Reset abwarten. Nach Meldung 1101 (Verbindung wiederhergestellt, Marktdaten verloren) muss der Bot die Abos neu anfordern, bei 1102 bleiben sie erhalten. Prüfkriterium: Nach dem Neustart liest der Bot den Zustand vom Broker statt aus dem eigenen Speicher und erzeugt keine doppelten Orders. Ebenfalls in den Test gehört die wöchentliche Neuanmeldung mit zweitem Faktor, die TWS und IB Gateway trotz automatischem Neustart einmal pro Woche verlangen.
4. Last und Pacing: Die TWS API begrenzt die Anfragen pro Sekunde auf die Zahl der Marktdatenzeilen geteilt durch zwei; bei den standardmäßigen 100 Zeilen sind es 50 Anfragen pro Sekunde. Je nach Einstellung meldet TWS eine Überschreitung mit Fehler 100 und beendet die API-Sitzung nach drei Verstößen, oder es drosselt die Anfragen selbst. Historische Daten haben eigene Grenzen. Prüfkriterium: Spitzen wie Handelsbeginn, viele Symbole oder Neuabonnements nach einem Reset bleiben deutlich unter der Grenze, und der Bot drosselt sich selbst.
5. Dauerlauf: Mehrere Wochen ohne Eingriff in Bot und Strategie, abgesehen von der wöchentlichen Neuanmeldung, über tägliche Resets und Wochenwechsel hinweg. Prüfkriterium: Logs sind vollständig, Alarme kommen an, Speicher und Prozessorlast bleiben stabil, und der Bot verbindet sich nach der Wochenanmeldung selbst wieder und gleicht den Zustand ab.

Die Handelsergebnisse aus dem Paper-Konto dienen dabei nur als Plausibilitätskontrolle. Ein Vergleich mit dem Backtest hilft, Fehler zu finden, etwa abweichende Signale oder falsch gerundete Stückzahlen. Eine Prognose für den Live-Betrieb ist er nicht.

Was sich nur live prüfen lässt.

Einige Eigenschaften eines Systems zeigen sich erst mit echten Orders am echten Markt. Diese Punkte sollten im Testprotokoll ausdrücklich als „im Paper-Konto nicht prüfbar“ markiert sein, damit niemand sie für erledigt hält:

• Ausführungsqualität: echte Fills, Position in der Warteschlange, Teilausführungen und Slippage über mehrere Orderbuchebenen.
• Marktwirkung: wie eigene Orders den Kurs bewegen, vor allem in weniger liquiden Werten.
• Stops und komplexe Orders: wie sie im Live-Konto behandelt und ausgelöst werden.
• Fehlende Ordertypen: VWAP, Auction, RFQ, Pegged to Market und alles, was darauf aufbaut.
• Eigener Server: Latenz und Wartungsfenster des zugewiesenen Live-Servers; für Europa nennt der IBKR-Systemstatus ein Reset-Fenster sonntags bis freitags von 06:25 bis 07:45 CET.
• Tatsächliche Kosten: WhatIf liefert Schätzungen, die tatsächlichen Kommissionen und Gebühren zeigt erst die Abrechnung des Live-Kontos.
• Regulatorische Snapshots und andere Funktionen, die nur live verfügbar sind.

Daraus folgt kein Verzicht auf den Paper-Test, sondern eine klare Arbeitsteilung. Das Paper-Konto beseitigt die technischen Fehler, die sonst echtes Geld kosten würden. Die verbleibenden Fragen beantwortet eine kurze, eng begrenzte Live-Phase.

Grenzen und Risiken beim Übergang in den Live-Betrieb.

Das größte technische Risiko ist die Verwechslung der Umgebungen. Live und Paper unterscheiden sich in Benutzer, Port, Kontonummer und Server. Ein Konfigurationsfehler kann echte Orders auslösen, obwohl alle Beteiligten einen Test erwarten. Getrennte Konfigurationen, die Kontoprüfung beim Start und ein Positionslimit, das im Code fest hinterlegt ist, senken dieses Risiko deutlich, schließen es aber nicht aus.

Das zweite Risiko ist falsche Sicherheit. Fills vom Top of Book ohne Markttiefe sind für viele Strategien zu optimistisch. Wer mit kleinem Vorteil je Trade arbeitet, kann im Paper-Konto im Plus und live im Minus liegen. Paper-Ergebnisse sind kein Beleg für künftige Ergebnisse, genauso wenig wie ein Backtest. Dazu kommt das Marktrisiko selbst: Bei gehebelten Produkten wie Futures, Optionen oder Margin-Positionen können Verluste den Einsatz übersteigen, ein Totalverlust ist möglich. Ein simuliertes Konto mit 1.000.000 USD verdeckt zudem Margin-Engpässe, die ein kleineres Live-Konto sofort trifft.

Für den Übergang eignet sich ein kurzer Start mit kleiner Größe, festen Abbruchkriterien und einem jederzeit erreichbaren Notaus. Wie sich die Größe danach stufenweise erhöhen lässt, beschreibt der Artikel zu Canary-Rollouts mit wenig Kapital. In Projekten mit Kunden schalte ich den Live-Betrieb nicht selbst frei: Die Aktivierung auf dem eigenen Konto übernimmt der Kunde.

Was Sie jetzt konkret tun können.

1. Paper-Benutzername und Paper-Kontonummer im Client Portal nachschlagen und ein eigenes Paper-Passwort setzen.
2. Paper-Kapital auf die geplante Live-Größe zurücksetzen und die Marktdatenteilung aktivieren.
3. Für Client Portal und manuellen Handel einen zusätzlichen Benutzer prüfen, damit Fehler 10197 den Bot nicht ausbremst.
4. Kontoprüfung, getrennte Konfigurationen und ein festes Positionslimit in den Bot einbauen, bevor die erste Order läuft.
5. Den Testplan mit Funktions-, Fehler-, Neustart-, Last- und Dauertests schriftlich festhalten, mit Prüfkriterien je Stufe.
6. Eine Liste der Punkte führen, die nur live prüfbar sind, und dafür eine kurze Live-Phase mit kleiner Größe und klaren Abbruchregeln planen.

Wenn Sie Unterstützung bei Entwicklung, Tests oder Betrieb eines IBKR-Systems möchten, finden Sie die Leistungen auf der Seite zur Trading-Automatisierung.

Häufige Fragen.

Kann ich die Interactive Brokers API mit einem Paper-Konto nutzen?

Ja. Sobald das Live-Konto genehmigt und finanziert ist, lässt sich ein Paper-Konto nutzen, das die TWS API, das IB Gateway und die Web API unterstützt. In der TWS genügen meist die Live-Zugangsdaten mit Auswahl des Paper-Kontos, für Web API und Drittplattformen braucht es die eigenen Paper-Zugangsdaten. Standardports sind 7497 bei der TWS und 4002 beim IB Gateway, beide lassen sich ändern.

Warum bekommt mein IBKR-Paper-Konto keine Marktdaten?

Häufig liegt es an der Datenteilung. Fehler 10197 zeigt an, dass Live- und Paper-Sitzung gleichzeitig Live-Marktdaten anfordern; das Live-Konto hat dann Vorrang. Auch eine Anmeldung des Live-Benutzers im Client Portal kann die Paper-Sitzung in TWS oder IB Gateway ohne Daten lassen. Abhilfe schaffen ein zusätzlicher Benutzername, getrennte Nutzungszeiten oder die Prüfung, ob die Teilung überhaupt aktiviert ist.

Wie realistisch sind Paper-Trading-Ergebnisse bei Interactive Brokers?

Für die Technik sind sie aussagekräftig, für die Ausführungsqualität kaum. IBKR simuliert Fills vom Top of Book ohne Markttiefe, simuliert Stops und komplexe Orders und schreibt selbst, dass das Ausführungsverhalten nicht den realen Bedingungen entspricht. Slippage, Marktwirkung und echte Kosten zeigen sich erst live. Paper-Ergebnisse eignen sich daher zur Fehlersuche, nicht als Prognose.

Welche Ordertypen funktionieren im IBKR-Paper-Konto nicht?

Laut IBKR-Handbuch, Stand Oktober 2026, werden unter anderem VWAP, Auction, RFQ und Pegged to Market nicht unterstützt. Combo-Handel ist eingeschränkt, Investmentfonds sind nicht handelbar, US-Optionen erhalten keine Penny-Fills. Der Rest teilgefüllter exchange-directed Market-Orders wird abgelehnt. IBKR betont, dass die Liste nicht abschließend ist, deshalb sollten Sie jeden genutzten Ordertyp selbst im Paper-Konto prüfen.

Quellen und Stand.

• About Paper Trading Accounts — Interactive Brokers (Client Portal User Guide)
• Order Types: Notes and Limitations, Introduction — Interactive Brokers
• Connected IB Server Location in TWS — Interactive Brokers (TWS API)
• Using a Paper Account — Interactive Brokers (Web API)
• TWS API Error Codes — Interactive Brokers (TWS API)
• Logging into multiple applications — Interactive Brokers (TWS API)
• Market Data Sharing — Interactive Brokers
• TWS API Limitations — Interactive Brokers (TWS API)

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

Sie wollen Ihren IBKR-Bot vor dem Live-Start strukturiert im Paper-Konto testen? Unverbindlich anfragen — wir klären Testplan, Fehlerbehandlung und den Weg in den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.