Bracket- und OCA-Orders per IBKR-API: richtig verketten.

Eine Bracket-Order bei Interactive Brokers (IBKR) besteht aus drei verknüpften Orders: einer Einstiegsorder (Parent) und zwei Kind-Orders für Take-Profit und Stop-Loss, die über das Feld parentId am Parent hängen. Damit kein Teil vor dem Rest ausgeführt wird, senden Sie Parent und erste Kind-Order mit transmit=False und erst die letzte Kind-Order mit transmit=True; dann überträgt die Trader Workstation (TWS) alle drei zusammen an die IBKR-Server. Dieser Artikel zeigt Stand Oktober 2026 die richtige Reihenfolge in der TWS API mit einem Python-Beispiel für das Paper-Konto, die Kurzform über TWS-Presets, die drei OCA-Typen mit und ohne Überfüllungsschutz, was beim Neustart mit nicht übertragenen Orders passiert, wo sich Paper- und Live-Konto unterscheiden und welche Kombinationen IBKR gar nicht unterstützt. Um sinnvolle Stop-Abstände geht es hier bewusst nicht, sondern um die Technik der Verkettung und um saubere Tests.

Was ist eine Bracket-Order und wie bildet IBKR sie ab?

Eine Bracket-Order „klammert“ eine Einstiegsorder mit zwei Orders der Gegenseite ein. IBKR beschreibt das so: Eine Kauforder wird von einer höher liegenden Verkaufs-Limit-Order und einer tiefer liegenden Verkaufs-Stop-Order eingerahmt. Bei einer Verkaufsorder ist es spiegelbildlich ein Kauf-Stop oberhalb und ein Kauf-Limit unterhalb des Einstiegs. Die beiden Ausstiegsorders haben laut IBKR dieselbe Stückzahl wie die Einstiegsorder.

Technisch nutzt die TWS API dafür den Mechanismus der angehängten Orders (Attached Orders). Jede Kind-Order trägt im Feld parentId die Order-ID der Einstiegsorder. Die Kinder arbeiten erst, wenn der Parent ausgeführt ist; bis dahin sind sie an ihn gebunden. Wird eine der beiden Kind-Orders ausgeführt, storniert das System laut IBKR die andere: Erreicht der Kurs das Kursziel, verschwindet der Stop, und umgekehrt. Die Kinder verhalten sich damit wie eine OCA-Gruppe. OCA steht für „One Cancels All“: Wird eine Order der Gruppe ausgeführt, werden die anderen storniert.

Für einen Bot heißt das: Ein Bracket ist kein einzelnes Objekt, sondern drei Orders mit drei IDs, drei Statusverläufen und eigenen Ausführungsmeldungen. Ihr Code muss alle drei verfolgen und zusammen denken. Welche Ordertypen und Gültigkeiten (Time-in-Force) für Einstieg und Ausstieg in Frage kommen und warum ein Stop live börsenseitig oder vom Broker simuliert liegen kann, behandelt der Artikel Ordertypen und Time-in-Force im Bot.

Bracket-Order per TWS API: parentId und transmit richtig setzen.

Das Kernrisiko benennt IBKR selbst: Weil ein Bracket aus drei Orders besteht, kann eine davon ausgeführt werden, bevor das ganze Bracket gesendet ist. Typisches Beispiel: Ihr Programm überträgt den Parent sofort, der Kurs läuft durch das Limit, die Einstiegsorder wird ausgeführt, und genau jetzt bricht das Skript ab. Dann halten Sie eine Position ohne Stop. Die Lösung ist das Order-Feld transmit. Steht es auf False, nimmt TWS die Order entgegen, schickt sie aber nicht an die IBKR-Server.

Die Belegung der drei Orders ist deshalb fest:

Trifft die letzte Kind-Order mit transmit=True ein, wertet TWS das als Signal, auch den Parent und die übrige Kind-Order zu übertragen. Die drei Order-IDs müssen eindeutig sein und aufsteigen: Laut IBKR löst eine neue Order mit einer ID kleiner oder gleich einer früheren einen Fehler aus. Die erste freie Nummer liefert der Callback nextValidId nach dem Verbindungsaufbau. Das folgende Beispiel mit der offiziellen Bibliothek ibapi ist bewusst auf den Paper-Port gesetzt; Kontrakt und Preise sind Platzhalter, kein Handelsvorschlag.

# Nur für das Paper-Konto: TWS-Standardport Paper 7497 (IB Gateway Paper: 4002, änderbar)
from decimal import Decimal
from ibapi.client import EClient
from ibapi.wrapper import EWrapper
from ibapi.contract import Contract
from ibapi.order import Order

def make_order(oid, action, otype, qty, parent_id=0, lmt=None, stop=None, transmit=False):
    o = Order()
    o.orderId = oid
    o.action = action
    o.orderType = otype
    o.totalQuantity = Decimal(qty)
    if lmt is not None:
        o.lmtPrice = lmt
    if stop is not None:
        o.auxPrice = stop          # Auslösepreis der Stop-Order
    o.parentId = parent_id
    o.transmit = transmit
    return o

class App(EWrapper, EClient):
    def __init__(self):
        EClient.__init__(self, self)
        self.sent = False

    def nextValidId(self, orderId):
        if self.sent:              # nextValidId kann mehrfach kommen
            return
        self.sent = True
        c = Contract()             # Beispielkontrakt, Preise sind Platzhalter
        c.symbol, c.secType, c.exchange, c.currency = "AAPL", "STK", "SMART", "USD"
        pid = orderId
        parent = make_order(pid,     "BUY",  "LMT", 10, lmt=100.0)
        take   = make_order(pid + 1, "SELL", "LMT", 10, parent_id=pid, lmt=110.0)
        stop   = make_order(pid + 2, "SELL", "STP", 10, parent_id=pid, stop=95.0,
                            transmit=True)   # erst diese Order gibt alles frei
        for o in (parent, take, stop):
            self.placeOrder(o.orderId, c, o)

    def orderStatus(self, orderId, status, filled, remaining, *rest):
        print("Status", orderId, status, filled, remaining)

    def error(self, reqId, *rest):
        print("Meldung", reqId, rest)

app = App()
app.connect("127.0.0.1", 7497, clientId=11)
app.run()

Zwei Details im Code sind wichtig. Erstens sendet das Beispiel nur einmal, auch wenn nextValidId erneut eintrifft. Zweitens wird die Stop-Order als letzte gesendet, weil sie das Freigabe-Flag trägt. Entscheidend ist, dass genau die zuletzt gesendete Order das Flag trägt. Wer mit ib_async arbeitet, dem Community-Nachfolger des verwaisten ib_insync, bekommt mit ib.bracketOrder() eine Hilfsfunktion, die genau diese Belegung erzeugt (Stand Version 2.1.0): Parent und Take-Profit mit transmit=False, Stop mit transmit=True, beide Kinder mit der parentId des Parents. Senden müssen Sie die drei Orders trotzdem einzeln und in dieser Reihenfolge.

Take-Profit und Stop-Loss per PRESET an eine Order hängen.

Die TWS API kennt eine zweite Variante. Statt drei Orders zu bauen, senden Sie nur die Einstiegsorder und setzen dort zusätzlich die Felder ptOrderId und ptOrderType für den Profit-Taker sowie slOrderId und slOrderType für den Stop-Loss. Beide IDs müssen eindeutig sein, IBKR empfiehlt dafür ebenfalls nextValidId. Der Typ muss immer „PRESET“ lauten. Die Einzelheiten der Kind-Orders, etwa Ordertyp und Abstand, übernimmt TWS dann aus den Presets, die in der Trader Workstation hinterlegt sind.

IBKR empfiehlt diese Form für alle, die mit identischen Bracket-Parametern über viele Orders handeln. Sie spart Code und die transmit-Reihenfolge, die man falsch machen kann. Der Preis dafür: Die eigentliche Logik steckt außerhalb Ihres Programms. Ändert jemand in TWS ein Preset, ändern sich die Kind-Orders des Bots, ohne dass sich eine Zeile Code geändert hat. IBKR weist ausdrücklich darauf hin, die Presets vor dem Senden zu prüfen. Prüfen Sie außerdem, ob Ihre installierte API-Version und Ihre Bibliothek die Felder unterstützen.

• Manuell mit drei Orders: Typ, Preis und Gültigkeit jeder Kind-Order stehen im Code, sind versioniert und automatisch testbar. Dafür mehr Code und die Reihenfolge als Fehlerquelle.
• Über Presets: ein Order-Objekt, weniger Code, dieselben Parameter wie beim manuellen Handeln in TWS. Dafür hängt das Verhalten von einer Konfiguration ab, die Sie mitdokumentieren und bei jedem Wechsel der Installation oder des Benutzers prüfen müssen.

Für automatische Systeme, die Ausstiegspreise aus Daten berechnen, ist die manuelle Variante meist die passendere. Presets passen eher zu halbautomatischen Werkzeugen, bei denen ein Mensch die Parameter in TWS pflegt.

OCA-Gruppen: die drei Typen im Vergleich.

OCA-Gruppen gibt es auch unabhängig von Brackets. Sie geben mehreren Orders denselben Gruppennamen im Feld ocaGroup und legen mit ocaType fest, was nach einer Ausführung mit den übrigen passiert. IBKR nennt als Einsatz zum Beispiel den Verkauf nur einer von drei gehaltenen Positionen zu jeweils eigenen Zielkursen oder zwei Wege in eine ähnliche Position, von denen nur einer zum Zug kommen soll.

„With block“ heißt laut IBKR: Es wird immer nur eine Order der Gruppe gleichzeitig geroutet, damit eine Überfüllung ausgeschlossen ist. Überfüllung bedeutet, dass mehrere Orders gleichzeitig ausgeführt werden und Sie mehr kaufen oder verkaufen als geplant. Ohne Block können mehrere Orders zugleich an Börsen liegen; IBKR nennt als Folge mögliche Überfüllungen und bei mehreren Verkaufsorders Ablehnungen, wenn eine davon als Leerverkauf markiert wird. Eine feste Regel: Verschiedene OCA-Typen in einer Gruppe sind nicht erlaubt. Außerdem sollten Gruppennamen eindeutig sein, damit sich Gruppen nicht vermischen; IBKRs Codebeispiele hängen dafür die nächste Order-ID an den Namen an.

Drei Feinheiten sind für Bots wichtig. Erstens storniert IBKR die übrigen Orders der Gruppe mit, wenn Sie als Kunde eine Order vor der Ausführung stornieren; lehnt dagegen das System eine Order ab oder storniert sie, bleiben die übrigen laut IBKR-Glossar bestehen. Zweitens ist das Stornieren laut IBKR ein automatischer Vorgang ohne Garantie, dass die Stornierung die Börse vor einer weiteren Ausführung erreicht. Drittens gilt das transmit-Prinzip auch hier: Setzen Sie alle Orders der Gruppe auf False und nur die letzte auf True, wie es eines der IBKR-Codebeispiele zeigt. Sonst arbeitet die erste Order schon, während die Gruppe noch unvollständig ist.

Was passiert bei Neustart und Verbindungsverlust?

Nicht übertragene Orders, also solche mit transmit=False, existieren laut IBKR nur in der laufenden TWS-Session. Andere Benutzernamen sehen sie nicht, und beim Neustart werden sie gelöscht. Solange sie in diesem Zustand sind, lassen sie sich per API stornieren oder übertragen, aber nicht abfragen. Für Brackets ist das zunächst beruhigend: Stürzt Ihr Bot nach Parent und Take-Profit ab, bevor die Stop-Order gesendet ist, liegt nichts am Markt. Ein Neustart von TWS räumt die Reste ab.

Das Problem liegt woanders: Ihr Bot kann diese Reste nach seinem eigenen Neustart nicht sehen und weiß nicht sicher, wie weit er gekommen ist. Deshalb gehört nach jedem Neuverbinden ein Abgleich dazu: offene Orders und Positionen abfragen, mit dem eigenen Order-Journal vergleichen, bekannte, aber nicht bestätigte IDs gezielt stornieren. Wie so ein Abgleich aufgebaut ist, beschreibt der Artikel Positionsabgleich für Trading-Bots. Zwei Einschränkungen gelten dabei: Die Abfrage offener Orders liefert nur aktive Orders; ausgeführte, abgelehnte oder von Ihnen stornierte Orders des laufenden Tages liefert getrennt davon reqCompletedOrders. Und API-Orders bleiben an die Client-ID gebunden, mit der sie gesendet wurden; laut IBKR darf nur dieser Client sie ändern. Ein Bot, der nach dem Neustart mit einer anderen Client-ID verbindet, kann seine Brackets nicht mehr direkt anpassen.

Für Unterbrechungen zwischen TWS und den IBKR-Servern gibt es die Einstellung „Maintain and resubmit orders when connection is restored“ unter Global Configuration, API, Settings. Sie ist laut IBKR standardmäßig aktiv: Orders, die während der Unterbrechung eingehen, speichert TWS und sendet sie, sobald die Verbindung wieder steht; IBKR nennt dabei auch den automatischen Neustart. Wird TWS in dieser Zeit geschlossen, sind sie gelöscht. Für einen Bot ist das zweischneidig. Ein Bracket, das während eines Ausfalls entstanden ist, kann Minuten später bei einem ganz anderen Kurs ankommen. Ob Ihr System das zulassen soll, sollten Sie bewusst entscheiden, im Paper-Konto nachstellen und in Ihrer Betriebsdokumentation festhalten.

Was das Paper-Konto zeigt und was IBKR nicht unterstützt.

Das Paper-Konto ist die richtige Umgebung, um die Verkettung zu testen, aber kein exaktes Abbild des Live-Kontos. Laut IBKR werden Stops und andere komplexe Ordertypen im Paper-Trading immer simuliert, was zu leicht anderem Verhalten als im Live-Konto führen kann. Weitere dokumentierte Unterschiede: Ausführungen werden aus dem besten Geld- und Briefkurs simuliert, ohne Zugriff auf die Markttiefe; VWAP, Auction, RFQ und Pegged to Market fehlen; Combo-Handel ist eingeschränkt; teilweise ausgeführte, direkt an eine Börse geroutete Market-Orders werden im Rest abgelehnt.

Daraus folgt eine klare Arbeitsteilung. Im Paper-Konto prüfen Sie die Logik: IDs, Reihenfolge, Statusübergänge, das Stornieren der Geschwister-Order und das Verhalten nach Abbrüchen. Nicht prüfen können Sie dort die Ausführungsqualität. Slippage am Stop, Teilausführungen an der Börse und das Verhalten in schnellen Märkten können live anders aussehen. Erste Live-Läufe deshalb mit minimaler Größe planen und genau protokollieren.

Nicht jede Kombination funktioniert überhaupt. IBKR rät, eine Order-Idee zuerst manuell in TWS auszuprobieren, bevor Sie sie per API programmieren. Manche Ideen unterstützt TWS nicht, etwa ein Bracket mit einem IB-Algo (IBALGO) oder ein Stop-Limit auf einer Iceberg-Order, und dann unterstützt sie auch die API nicht. Was sich in der Oberfläche nicht anlegen lässt, lässt sich laut IBKR auch per Code nicht anlegen. Eine Fehlermeldung aus TWS ist dann kein Programmierfehler, sondern die Grenze des Systems.

Testfälle und Risiken verketteter Orders.

Bevor Bracket- oder OCA-Code live geht, sollte er im Paper-Konto mindestens diese Fälle durchlaufen haben. Halten Sie zu jedem Fall die Statusmeldungen und Ihr Journal fest.

1. Normalfall Kursziel: Parent wird ausgeführt, Take-Profit wird ausgeführt, der Stop wird storniert. Erkennt Ihr Code die Stornierung als erwartet statt als Fehler?
2. Normalfall Stop: Stop wird ausgeführt, Take-Profit storniert.
3. Abbruch zwischen den Aufrufen: Prozess nach dem zweiten placeOrder beenden. Es darf nichts übertragen sein, und der Bot darf beim Neustart keine halbe Gruppe nachschicken.
4. Teilausführung des Parents: Beobachten und dokumentieren, wie sich Mengen und Status der Kinder verhalten, statt es anzunehmen.
5. Stornierung des Parents vor Ausführung: Prüfen, ob die Kinder mit verschwinden und das Journal das abbildet.
6. Ablehnung einer Kind-Order: etwa wegen eines Preises zu weit vom Markt (laut IBKR Status „Cancelled“ mit Fehler 202). Lehnt das System eine Order ab oder storniert sie, bleiben die übrigen OCA-Orders laut IBKR bestehen; Ihr Bot muss reagieren.
7. Verbindungsabbruch nach Ausführung des Parents: Bot neu starten; der Abgleich muss Position und offene Kinder korrekt finden.

Die wichtigsten Risiken im Überblick:

• Ungeschützte Position: Ein Parent mit transmit=True oder eine abgelehnte Stop-Order lässt eine Position ohne Absicherung zurück.
• Überfüllung: OCA-Typ 3 ohne Block oder nicht stornierte Orders nach einer System-Ablehnung können zu mehr Stückzahl führen als geplant.
• Stop ist keine Preisgarantie: Eine ausgelöste Stop-Order wird zur Market-Order. Bei Kurslücken kann die Ausführung deutlich unter dem Stop-Preis liegen; bei gehebelten Produkten wie Futures oder verkauften Optionen können Verluste den Einsatz übersteigen.
• Konfigurationsdrift: Geänderte Presets oder TWS-Einstellungen ändern das Verhalten, ohne dass sich der Code ändert.
• Doppelte Brackets: Wiederholungslogik nach einem Timeout kann ein zweites Bracket senden, wenn der Status des ersten unklar ist.

Was Sie jetzt konkret tun können.

• Legen Sie ein Bracket einmal manuell in TWS im Paper-Konto an und sehen Sie sich an, wie TWS Parent und Kinder verknüpft, bevor Sie es programmieren.
• Prüfen Sie Ihren Code auf eine einzige Regel: Nur die zuletzt gesendete Order einer Gruppe hat transmit=True, alle IDs stammen aus nextValidId und steigen auf.
• Entscheiden Sie bewusst zwischen drei manuellen Orders und der PRESET-Variante, und dokumentieren Sie die Presets, falls Sie sie nutzen.
• Wählen Sie den OCA-Typ nach dem gewünschten Verhalten und vergeben Sie eindeutige Gruppennamen.
• Prüfen Sie die Einstellung „Maintain and resubmit orders when connection is restored“ und entscheiden Sie, ob verspätete Orders für Ihr System akzeptabel sind.
• Arbeiten Sie die sieben Testfälle oben im Paper-Konto ab und bauen Sie den Abgleich nach Neustart, bevor Sie live gehen.

Wenn Sie ein System mit sauber verketteten Orders nicht selbst bauen wollen: Marcel Gautsche aus Stuttgart entwickelt Python-Systeme für Interactive Brokers nach Ihren Vorgaben, testet sie im Paper-Konto und übergibt sie dokumentiert. Die Live-Aktivierung auf Ihrem Konto nehmen Sie selbst vor. Mehr dazu auf der Seite Trading-Automatisierung.

Häufige Fragen.

Wie erstelle ich eine Bracket-Order mit der Interactive Brokers API in Python?

Sie bauen drei Order-Objekte: eine Einstiegsorder und zwei Kind-Orders für Take-Profit und Stop-Loss, die im Feld parentId die ID der Einstiegsorder tragen. Einstieg und erste Kind-Order bekommen transmit=False, die zuletzt gesendete Kind-Order transmit=True. Dann senden Sie alle drei nacheinander mit placeOrder. Die IDs holen Sie aus nextValidId. Testen Sie das zuerst im Paper-Konto.

Was bedeuten ocaType 1, 2 und 3 bei IBKR?

Der ocaType legt fest, was nach einer Ausführung mit den übrigen Orders einer OCA-Gruppe passiert. Typ 1 storniert sie, Typ 2 verkleinert sie proportional, beide mit Überfüllungsschutz, bei dem nur eine Order der Gruppe gleichzeitig geroutet wird. Typ 3 verkleinert proportional ohne diesen Schutz. Verschiedene Typen in derselben Gruppe sind nicht erlaubt.

Was passiert mit nicht übertragenen Orders, wenn TWS neu startet?

Orders mit transmit=False existieren nur in der laufenden TWS-Session und werden beim Neustart gelöscht. Andere Benutzernamen sehen sie nicht. Solange sie bestehen, können Sie sie per API stornieren oder übertragen, aber nicht abfragen. Ein Bot sollte deshalb nach jedem Neuverbinden offene Orders und Positionen mit seinem eigenen Journal abgleichen.

Funktionieren Bracket-Orders im IBKR-Paper-Konto genauso wie live?

Die Logik der Verkettung lässt sich im Paper-Konto gut testen, die Ausführung nicht. Laut IBKR werden Stops und komplexe Orders dort immer simuliert, Ausführungen kommen aus dem besten Geld- und Briefkurs ohne Markttiefe. Das Verhalten kann daher leicht vom Live-Konto abweichen. Erste Live-Läufe sollten mit kleiner Größe und genauer Protokollierung erfolgen.

Kann ich ein Bracket mit einem IB-Algo kombinieren?

Laut IBKR nicht: Ein Bracket mit IBALGO gehört zu den Kombinationen, die TWS nicht unterstützt, und was TWS nicht kann, kann auch die API nicht. IBKR empfiehlt, jede Order-Idee zuerst manuell in TWS auszuprobieren, bevor Sie sie programmieren. Lässt sie sich dort nicht anlegen, brauchen Sie eine andere Konstruktion.

Quellen und Stand.

• Bracket Orders — Interactive Brokers
• Adding a Profit Taker and Stop Loss — Interactive Brokers
• OCA Types — Interactive Brokers
• One-Cancels-All (OCA) Order (Glossar) — IBKR Campus
• Placing Orders: Introduction — Interactive Brokers
• Intelligent Order Resubmission — Interactive Brokers
• Order Types: Notes and Limitations — Interactive Brokers
• About Paper Trading Accounts — Interactive Brokers (IBKR Guides)

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

Sie wollen Einstieg, Kursziel und Stop in Ihrem IBKR-System sauber verketten lassen? Unverbindlich anfragen — wir klären Order-Logik, Testfälle im Paper-Konto und den Abgleich nach Neustarts. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.