IBKR Adaptive Algo per API: IB-Algos im Bot nutzen.

Den IBKR Adaptive Algo und die anderen Ausführungsalgorithmen von Interactive Brokers nutzen Sie über die TWS API als Zusatzfelder einer normalen Order: Sie setzen algoStrategy auf einen Wert wie Adaptive, Twap, Vwap oder ArrivalPx und übergeben die Parameter als Liste in algoParams. Wichtig für jeden Bot: IB-Algos laufen laut IBKR nur in den regulären Handelszeiten, eine Order mit outsideRth=True wird abgelehnt, und das Paper-Konto unterstützt VWAP-Orders nicht. Dieser Artikel zeigt die wichtigsten Algos mit ihren Kernparametern (Stand Oktober 2026, laut IBKR-Dokumentation), ein lauffähiges Python-Beispiel mit ib_async für das Paper-Konto und die Grenzen, die IBKR selbst nennt. Ausführlich geht es um die Order Efficiency Ratio, eine Kennzahl, mit der IBKR übermäßig viele Orders ohne Ausführung erkennt und die gerade automatisierte Systeme betrifft. Welcher Algo für Ihre Strategie günstiger ausführt, beantwortet der Artikel bewusst nicht: Das zeigt nur eine eigene Messung.

Welche Ausführungsalgorithmen bietet IBKR über die API?

Ein Ausführungsalgorithmus (kurz Algo) entscheidet nicht, ob gehandelt wird, sondern wie eine bereits beschlossene Order in den Markt kommt: in Teilstücken über den Tag verteilt, mit Blick auf das Volumen oder mit kurzer Suche nach einem besseren Preis innerhalb des Spreads. Für einen Bot heißt das: Die Strategie liefert Richtung, Menge und Preisgrenze, der Algo übernimmt die Feinarbeit beim Ausführen.

Interactive Brokers bietet eigene Algos (IB Algos) und zusätzlich Algos von Drittanbietern an. In der aktuellen IBKR-Dokumentation stehen unter den IB Algos unter anderem Adaptive, Arrival Price, Close Price, DarkIce, Accumulate/Distribute, Percentage of Volume mit mehreren Varianten, TWAP, VWAP, Balance Impact Risk, Minimise Impact und Midprice. Als Drittanbieter führt die Doku Quantitative Brokers und Fox River mit eigenen Algos auf. Midprice ist eine Ausnahme: Er wird nicht über algoStrategy, sondern als eigener Ordertyp MIDPRICE gesetzt.

Abgesehen davon ist ein IB-Algo in der TWS API kein eigener Ordertyp. IBKR beschreibt Algos als zusätzliche Parameter einer stehenden Order und nimmt in der Doku eine Limit-Order als Grundlage. Sie bauen also eine ganz normale Order mit Aktion, Menge, Ordertyp und gegebenenfalls Limitpreis und hängen zwei Felder an: algoStrategy mit dem Namen des Algos und algoParams mit den Parametern als TagValue-Paare (Name und Wert als Text). Zeitangaben erwartet IBKR im Format hh:mm:ss TMZ oder YYYYMMDD-hh:mm:ss TMZ, etwa „09:30:00 US/Eastern“. Wie TWAP und VWAP theoretisch funktionieren und wofür institutionelle Händler sie nutzen, erklärt der Grundlagenartikel VWAP und TWAP: Execution-Algorithmen verstehen. Hier geht es um das Handwerk im eigenen Code.

Algos im Überblick: Adaptive, TWAP, VWAP, Arrival Price.

Die folgende Tabelle fasst die vier Algos zusammen, nach denen Entwickler am häufigsten fragen. Die Werte stammen aus den Algo-Seiten der IBKR-Dokumentation (Stand Oktober 2026). Parameter, die Sie weglassen, übernimmt IBKR mit Standardwerten; verlassen Sie sich darauf aber nicht blind, sondern setzen Sie die für Ihr System wichtigen Werte ausdrücklich.

Einige Details aus der Doku sind für die Planung wichtig. TWAP und VWAP sind laut IBKR für alle US-Aktien verfügbar; für andere Märkte müssen Sie die Verfügbarkeit je Instrument prüfen. Beim VWAP handelt es sich um einen „Best Efforts“-Algo: Die früher angebotene garantierte VWAP-Variante gibt es nicht mehr. Wer noTakeLiq setzt, um keine Liquidität zu nehmen, riskiert laut IBKR, dass die Order nicht vollständig ausgeführt wird. Auch für TWAP schreibt IBKR ausdrücklich, dass eine Ausführung nicht garantiert ist, weil der Algo nur handelt, wenn die gewählte Bedingung erfüllt ist.

Arrival Price richtet sich an Orders, die einen spürbaren Anteil am durchschnittlichen Tagesvolumen ausmachen. Je höher die Dringlichkeit (riskAversion), desto schneller führt der Algo aus und desto größer wird laut IBKR der Markteinfluss. maxPctVol begrenzt bei VWAP und Arrival Price den Anteil am Volumen, der Wert 0,1 steht für 10 Prozent. Für einen Bot mit kleinen Stückzahlen in liquiden Werten sind TWAP, VWAP und Arrival Price oft überdimensioniert; Adaptive passt dann eher, weil er eine einzelne Order behandelt, ohne sie über Stunden zu verteilen.

IBKR Adaptive Algo in Python setzen: algoStrategy und Priorität.

Der Adaptive Algo verbindet laut IBKR das Smart Routing mit einer vom Nutzer gewählten Priorität. Smart Routing bedeutet, dass IBKR den Handelsplatz selbst auswählt. Die Priorität legt fest, wie lange der Algo nach einem besseren Preis sucht: „Urgent“ sucht nur kurz, „Patient“ arbeitet langsamer und hat nach IBKR-Beschreibung eine höhere Chance auf einen insgesamt besseren Fill. „Normal“ liegt dazwischen. IBKR gibt an, dass Adaptive im Durchschnitt bessere Preise erziele als reine Limit- oder Market-Orders. Das ist eine Herstellerangabe; ob sie für Ihre Instrumente, Uhrzeiten und Ordergrößen zutrifft, zeigt nur eine eigene Auswertung.

Das folgende Beispiel nutzt ib_async, den aktiv gepflegten Nachfolger von ib_insync, und verbindet sich mit dem Paper-Konto über IB Gateway. Es setzt eine kleine Limit-Order mit Adaptive-Priorität „Normal“, schreibt Status und Meldungen ins Log und zeigt, wie eine Preisänderung als Modify gesendet wird: dieselbe Order mit unveränderter orderId geht erneut an placeOrder. Symbol und Preise sind reine Beispielwerte.

from ib_async import IB, Stock, LimitOrder, TagValue

PAPER_PORT = 4002          # IB Gateway Paper; TWS Paper: 7497
ib = IB()
ib.connect("127.0.0.1", PAPER_PORT, clientId=17)

contract = Stock("AAPL", "SMART", "USD")   # Beispielkontrakt, kein Handelsvorschlag
ib.qualifyContracts(contract)

order = LimitOrder("BUY", 10, 180.00)      # Basisorder: Limit, Preis als Obergrenze
order.algoStrategy = "Adaptive"
order.algoParams = [TagValue("adaptivePriority", "Normal")]  # Urgent, Normal, Patient
order.outsideRth = False                   # IB-Algos nur in regulären Handelszeiten
order.tif = "DAY"

trade = ib.placeOrder(contract, order)
ib.sleep(3)
print(trade.orderStatus.status)
for entry in trade.log:
    print(entry.time, entry.status, entry.message, entry.errorCode)

# Preis anpassen: dieselbe Order mit gleicher orderId erneut senden (Modify)
if not trade.isDone():
    order.lmtPrice = 180.50
    ib.placeOrder(contract, order)

Drei Dinge sind im Code bewusst gesetzt. Erstens outsideRth=False, damit die Order nicht wegen der Handelszeiten abgelehnt wird. Zweitens der feste Paper-Port als Konstante: Ein Bot sollte nie stillschweigend auf einen Live-Port wechseln können. Drittens die Prüfung isDone() vor der Änderung, denn eine bereits ausgeführte oder stornierte Order lässt sich nicht mehr modifizieren. Laut IBKR lässt sich eine API-Order direkt ändern, wenn der Client mit demselben TWS-Benutzernamen und derselben Client-ID verbunden ist wie beim Absenden; bei einer Sitzung mit anderem Benutzernamen muss die Order zuerst über Client-ID 0 gebunden werden.

Welche Grenzen gelten für IB-Algos per API?

Die wichtigste Grenze steht prominent in der IBKR-Doku: IB-Algo-Orders werden nur während der regulären Handelszeiten unterstützt, Orders mit outsideRth auf „true“ werden abgelehnt. Ein Bot, der vorbörslich oder nachbörslich handeln soll, braucht für diese Zeiten einen anderen Ordertyp. Praktisch heißt das: Die Ordererzeugung muss die Uhrzeit des Zielmarkts kennen und den Algo nur innerhalb der regulären Sitzung anhängen. Bei US-Werten gehört dazu auch die Zeitumstellung, die in Europa und den USA an unterschiedlichen Tagen stattfindet.

Das Paper-Konto ist für Algo-Tests nur eingeschränkt brauchbar. Laut IBKR-Leitfaden unterstützt es unter anderem VWAP-, Auction-, RFQ- und Pegged-to-Market-Orders nicht. Fills werden vom besten Geld- und Briefkurs simuliert, ohne Zugriff auf das tiefere Orderbuch, und komplexe Ordertypen werden immer simuliert. IBKR schreibt selbst, dass Paper-Konten ausschließlich dazu dienen sollten, die Funktionsweise der Werkzeuge zu verstehen. Ausführungsqualität lässt sich dort nicht seriös messen.

Hinzu kommen Grenzen, die nicht in den Parametern stehen:

• Kombinationen: IBKR nennt als Beispiel, dass eine Bracket-Order mit IB-Algo oder ein Stop-Limit auf eine Iceberg-Order in TWS nicht unterstützt sein kann und dann auch über die API nicht funktioniert. Die Empfehlung lautet, eine Order-Idee zuerst manuell in TWS auszuprobieren.
• Änderungen: Laut IBKR-Doku sollten bei einer Modifikation nur Preis, Menge und Gültigkeit (DAY zu IOC) geändert werden. Für andere Felder, etwa andere Algo-Parameter, ist Stornieren und neu Erteilen oft der bessere Weg.
• Produkte: Nicht jeder Algo steht für jedes Instrument bereit. TWAP und VWAP nennt die Doku ausdrücklich für US-Aktien, Midprice nur für US-Aktien mit Smart Routing. Was in TWS für ein Instrument nicht angeboten wird, funktioniert auch per API nicht.
• Bruchstücke: Die IBKR-APIs unterstützen laut Doku keinen Handel mit Bruchstücken oder Geldbeträgen, außer bei Kryptowährungen und Forex.

Order Efficiency Ratio: was Bots beachten müssen.

Neben den technischen Pacing-Grenzen der API kennt Interactive Brokers eine Kennzahl für das Orderverhalten: die Order Efficiency Ratio (OER). Sie betrifft laut IBKR normale Trader in der Regel nicht, wohl aber automatisierte Systeme, die tausende Orders senden, ohne dass es regelmäßig zu Ausführungen kommt. Die Formel aus der IBKR-Wissensdatenbank (Artikel „Order management overview“):

OER = (neue Orders + Änderungen + Stornierungen) / (ausgeführte Orders + 1), berechnet für die gesamte Orderaktivität eines Tages.

Ein Wert über 20 gilt laut IBKR in der Regel als exzessiv und als Zeichen ineffizienter Orderlogik. Wer die Schwelle regelmäßig überschreitet, wird benachrichtigt und aufgefordert, die Logik zu verbessern. Wer darauf nicht reagiert oder einen besonders auffälligen Wert erreicht, kann mit Handelsbeschränkungen belegt werden. Rechenbeispiel: Ein Bot sendet an einem Tag 150 neue Orders, ändert sie 600-mal und storniert 120; ausgeführt werden 30 Orders. Das ergibt 870 geteilt durch 31, also rund 28. Schon ein unruhiger Nachführmechanismus für Limitpreise reicht für solche Werte.

Aus den Hinweisen von IBKR und aus der Formel selbst ergeben sich Regeln, die sich direkt in Code übersetzen lassen:

• Ändern statt Stornieren und neu Senden: Eine Änderung zählt als eine Aktion, Storno plus neue Order als zwei.
• Nur sinnvoll ändern: Preis oder Menge erst anpassen, wenn der bisherige Preis nicht mehr wettbewerbsfähig ist und der neue es ist. Änderungen um einen Tick, die die Chance auf eine Ausführung kaum verändern, sollten wegfallen.
• DAY-Orders auslaufen lassen: Strategien mit DAY-Orders, die auf die reguläre Sitzung beschränkt sind, sollten nach 16:00 Uhr New Yorker Zeit keine eigenen Stornos senden, sondern das automatische Verfallen durch IBKR nutzen.
• IB-Logik statt Eigenbau: Wer Limitpreise selbst im Sekundentakt nachführt, erzeugt viele Änderungen. Laut IBKR zählt die Änderungslogik in IB-eigenen Ordertypen nicht als Orderaktion für die OER; als Beispiele nennt IBKR Trailing-Stop-, Volatility- und Pegged-to-Market-Orders. Algos nennt IBKR dabei nicht ausdrücklich, beobachten Sie die Wirkung deshalb über die eigene Zählung.

Ein Kostendetail gehört dazu: Laut IBKR-Kommissionsseite wird eine geänderte Order bei der Kommission wie Storno und neue Order behandelt. An manchen Börsen kann deshalb die Mindestgebühr mehrfach anfallen. IBKR nennt das Beispiel einer Order über 200 Aktien, von denen 100 ausgeführt werden; nach einer Änderung werden weitere 100 ausgeführt, und auf beide Teile wird je eine Mindestkommission berechnet. Modify ist also gut für die OER, aber nicht automatisch kostenneutral. Ein Bot sollte daher selten und gezielt ändern. Eine eigene Zählung im Bot erfasst nur die Orders, die dieses Programm selbst sendet, ändert oder storniert; manuelle Orders oder andere Programme auf demselben Konto sieht sie nicht. Sie ist deshalb nur eine Schätzung, aber ein gutes Frühwarnsystem:

from collections import Counter

zaehler = Counter()
ausgefuehrt = set()            # permIds mit mindestens einer Ausführung

# Diese Events melden nur Orders, die dieser Client selbst sendet, ändert oder storniert
ib.newOrderEvent += lambda t: zaehler.update(["neu"])
ib.orderModifyEvent += lambda t: zaehler.update(["geaendert"])
ib.cancelOrderEvent += lambda t: zaehler.update(["storniert"])
ib.execDetailsEvent += lambda t, fill: ausgefuehrt.add(fill.execution.permId)

def oer_schaetzung() -> float:
    aktionen = zaehler["neu"] + zaehler["geaendert"] + zaehler["storniert"]
    return aktionen / (len(ausgefuehrt) + 1)

# z. B. jede Minute loggen und ab 10 warnen, lange vor der Schwelle 20

Ausführungsqualität messen statt vermuten.

Ob ein Algo Ihrem System hilft, lässt sich nicht aus der Beschreibung ablesen. Messbar ist die Differenz zwischen dem Preis zum Entscheidungszeitpunkt und dem tatsächlichen Durchschnittspreis, einschließlich Gebühren. Dieses Konzept heißt Implementation Shortfall und wird im Artikel Implementation Shortfall: Die wahren Execution-Kosten ausführlich erklärt. Für einen IBKR-Bot genügt ein schlankes Protokoll je Order:

1. Zeitpunkt der Signalentscheidung, Geld- und Briefkurs sowie Mittelkurs in diesem Moment.
2. Gewählter Algo und alle Parameter, also algoStrategy, Priorität und Zeitfenster.
3. Jede Teilausführung aus den Ausführungsmeldungen (execDetails) mit Preis, Menge und Uhrzeit.
4. Kommissionen und Gebühren aus dem Kommissionsbericht, den IBKR je Ausführung liefert.
5. Zahl der Änderungen und Stornos je Order, als Grundlage für die eigene OER-Schätzung.

Mit diesen Daten vergleichen Sie zum Beispiel Adaptive „Urgent“ gegen „Patient“ für dieselbe Instrumentengruppe. Achten Sie auf die Stichprobe: Wenige Dutzend Orders erlauben kaum belastbare Aussagen, weil Spread, Volatilität und Tageszeit stark schwanken. Vergleichen Sie zudem nicht nur den Preis, sondern auch die Ausführungsquote. Ein Algo, der bessere Preise erzielt, aber jede fünfte Order nicht füllt, kann für eine Strategie mit festen Ein- und Ausstiegen schlechter sein.

Dieses Protokoll sollte von Beginn an Teil des Systems sein, nicht erst nachgerüstet werden, weil es die Grundlage für jede spätere Entscheidung über die Ausführung ist. Aussagekräftig ist die Messung nur mit echten Kosten im Live-Konto, weil das Paper-Konto Fills lediglich simuliert.

Risiken und Testplan.

Ein Algo verschiebt Verantwortung, er nimmt sie nicht ab. Eine Order, die über Stunden verteilt ausgeführt wird, bleibt in dieser Zeit dem Markt ausgesetzt; bei einem Kurssprung kann der Durchschnittspreis deutlich vom Signalpreis abweichen. Ein Bot muss deshalb jederzeit wissen, wie viel einer Algo-Order schon ausgeführt ist, und darf eine neue Order erst senden, wenn der Positionsabgleich stimmt. Ohne Limitpreis als Obergrenze kann ein Algo bei dünnem Markt zu ungünstigen Preisen kaufen oder verkaufen. Der Handel mit Hebelprodukten kann zu Verlusten bis zum Totalverlust führen, auch wenn die Ausführung technisch einwandfrei ist.

Weitere typische Fehlerquellen sind Zeitzonen in startTime und endTime, Orders kurz vor Sitzungsende, die nicht mehr vollständig ausgeführt werden, und Code, der nach einer Ablehnung in einer Schleife neu sendet. Letzteres verschlechtert die OER und kann Pacing-Fehler auslösen. Ein sinnvoller Testplan geht in Stufen vor:

1. Order-Idee manuell in TWS ausprobieren und prüfen, ob die Kombination aus Ordertyp, Algo und Instrument angeboten wird.
2. Im Paper-Konto die Technik testen: Ablehnungen, Statusmeldungen, Änderungen, Stornos, Verhalten nach Verbindungsabbruch. VWAP lässt sich dort nicht testen.
3. Live mit minimaler Größe und harten Grenzen für Stückzahl, Orderwert und Orders pro Tag starten; die Live-Aktivierung erfolgt bewusst durch den Kontoinhaber.
4. Ausführungsprotokoll und OER-Schätzung täglich auswerten und erst danach Größe oder Parameter ändern.

Was Sie jetzt konkret tun können.

• Prüfen Sie im Code, ob irgendwo outsideRth=True zusammen mit einer algoStrategy gesetzt werden kann, und verhindern Sie das mit einer Regel in der Ordererzeugung.
• Ersetzen Sie Muster aus Storno und Neueingabe durch Modify, wo nur Preis oder Menge geändert werden, und führen Sie Limitpreise nur bei echter Wirkung nach.
• Zählen Sie neue Orders, Änderungen, Stornos und ausgeführte Orders je Tag und setzen Sie eine Warnung deutlich unter dem Wert 20.
• Protokollieren Sie Signalpreis, Algo, Parameter, Fills und Gebühren je Order, bevor Sie Algos vergleichen.
• Lesen Sie die Kommissionsregeln Ihres Gebührenmodells zu geänderten Orders und Mindestgebühren für die Börsen, an denen Ihr Bot handelt.

Wenn Sie ein Ausführungsmodul für Interactive Brokers nicht selbst bauen wollen: Marcel Gautsche entwickelt Python-Systeme für IBKR nach Ihren Vorgaben, mit Ausführungsprotokoll, OER-Überwachung und Tests mit echten Kosten, auf Wunsch mit Betrieb auf einem VPS mit Monitoring. Die Strategie und die Freigabe des Live-Handels bleiben bei Ihnen. Mehr dazu auf der Seite Trading-Automatisierung.

Häufige Fragen.

Wie setze ich den Adaptive Algo von Interactive Brokers per API?

Sie erstellen eine normale Order, meist eine Limit-Order, und setzen zusätzlich das Feld algoStrategy auf „Adaptive“. In algoParams übergeben Sie ein TagValue-Paar mit dem Namen adaptivePriority und dem Wert Urgent, Normal oder Patient. Die Order senden Sie wie gewohnt mit placeOrder. Achten Sie darauf, outsideRth nicht auf True zu setzen, weil IB-Algos nur in den regulären Handelszeiten unterstützt werden.

Warum wird meine IBKR-Algo-Order abgelehnt?

Häufige Gründe sind ein gesetztes outsideRth, eine Kombination, die TWS für dieses Instrument nicht anbietet, etwa eine Bracket-Order mit IB-Algo, ein Algo, der für den Markt nicht verfügbar ist, oder falsch formatierte Parameter wie Zeitangaben ohne Zeitzone. Im Paper-Konto werden außerdem VWAP-Orders nicht unterstützt. Prüfen Sie die Fehlermeldung im Log und testen Sie die gleiche Order manuell in TWS.

Was ist die Order Efficiency Ratio bei Interactive Brokers?

Die Order Efficiency Ratio ist eine Kennzahl von IBKR für das Orderverhalten eines Tages: neue Orders plus Änderungen plus Stornierungen, geteilt durch die ausgeführten Orders plus eins. Ein Wert über 20 gilt als exzessiv. Wer ihn regelmäßig überschreitet, wird benachrichtigt; bleibt eine Verbesserung aus, sind Handelsbeschränkungen möglich. Betroffen sind vor allem automatisierte Systeme mit vielen Orders ohne Ausführung.

Kann ich IBKR-Algos im Paper-Konto testen?

Teilweise. Die Technik, also Ordererzeugung, Statusmeldungen, Änderungen und Ablehnungen, lässt sich im Paper-Konto prüfen. VWAP-Orders unterstützt das Paper-Konto laut IBKR nicht, und Fills werden nur vom besten Geld- und Briefkurs simuliert. Aussagen über die Ausführungsqualität eines Algos sind dort deshalb nicht möglich. Dafür braucht es eine vorsichtige Messung im Live-Konto mit kleinen Größen.

Kostet das Ändern einer Order bei IBKR zusätzliche Kommission?

Es kann. Laut IBKR-Kommissionsseite wird eine geänderte Order wie eine Stornierung mit neuer Order behandelt. An manchen Börsen kann dadurch die Mindestkommission erneut anfallen, etwa wenn ein Teil vor und ein Teil nach der Änderung ausgeführt wird. Für die Order Efficiency Ratio ist eine Änderung trotzdem günstiger als Storno und Neueingabe. Ein Bot sollte daher selten und gezielt ändern.

Quellen und Stand.

• Algorithmic Orders: Introduction — Interactive Brokers
• IB Algorithms: Adaptive Algo — Interactive Brokers
• IB Algorithms: VWAP — Interactive Brokers
• Order Management Overview (Order Efficiency Ratio) — Interactive Brokers Knowledge Base
• Notes & Limitations: Introduction — Interactive Brokers
• About Paper Trading Accounts — Interactive Brokers
• Considerations for Optimizing Order Efficiency — Interactive Brokers FAQ
• Commissions: Stocks, ETFs and Warrants — Interactive Brokers

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

Sie wollen IB-Algos sauber in Ihren Bot einbauen oder die Ausführung Ihres IBKR-Systems messbar machen? Unverbindlich anfragen — wir klären Orderlogik, Ausführungsprotokoll, Tests im Paper-Konto und den Weg in den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.