Futures-Rollover per IBKR-API: Kontrakte, Fristen, CME-Regeln.

Ein Futures-Bot an der Interactive-Brokers-API erledigt den Futures-Rollover nicht von selbst: Orders gehen immer an einen konkreten Kontraktmonat mit eigener conId, und der Bot muss den Wechsel in den nächsten Monat selbst planen, ausführen und prüfen. Den Termin dafür leiten Sie aus den Kontraktdaten der API, der Börsenspezifikation und – bei physisch belieferten Kontrakten – aus der Close-Out-Frist von IBKR ab, denn IBKR kann solche Positionen in der Close-Out-Periode ohne weitere Vorankündigung schließen. Continuous Futures (CONTFUT) helfen nur bei historischen Daten, nicht beim Handel. Wer US-Futures über die CME per API handelt, muss zusätzlich die Vorgaben rund um CME Rule 576 beachten: Orders tragen eine Kennzeichnung als manuell oder automatisiert, und IBKR verlangt eine API User Activity Certification. Dieser Artikel zeigt, Stand Oktober 2026, wie Sie Roll-Termin, Roll-Order, Kennzeichnung, Tests und Alarme in einem Bot sauber aufsetzen. Welcher Roll-Zeitpunkt wirtschaftlich günstiger ist, ist nicht Thema.

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.

Warum muss ein Futures-Bot an der IBKR-API den Rollover selbst steuern?

Ein Future ist ein Terminkontrakt mit festem Verfall. Wer eine Position länger halten will als die Laufzeit des aktuellen Kontrakts, muss sie vor dem Verfall schließen und im nächsten Kontraktmonat neu eröffnen. Diesen Wechsel nennt man Roll oder Rollover. Bei einem Bot an der Interactive-Brokers-API (IBKR) gibt es dafür keinen Automatismus: Die API kennt keinen „Dauer-Future“, auf den man Orders schicken könnte. Jede Order geht an genau einen Kontrakt, etwa ES Dezember 2026.

Daraus folgen drei Aufgaben, die ein Futures-Bot selbst lösen muss:

• Kontraktwahl: Welcher Kontraktmonat ist gerade der handelbare, und welcher folgt?
• Roll-Termin: Bis wann muss die Position spätestens umgestellt sein, damit weder ein Verfall noch eine Zwangsschließung durch den Broker eintritt?
• Roll-Ausführung: Wie wird die alte Position geschlossen und die neue eröffnet, ohne dass der Bot zwischendurch doppelt oder gar nicht positioniert ist?

Hinzu kommt bei US-Futures an der CME eine regulatorische Ebene. Orders werden als manuell oder automatisiert gekennzeichnet, und IBKR fragt nach, mit welcher Software und unter wessen Verantwortung die API-Orders entstehen. Wie sich die Preisdifferenz zwischen zwei Kontraktmonaten als Marktphänomen verhält, beschreibt der Artikel Calendar-Spreads und Futures-Roll; hier geht es um die technische Umsetzung.

Continuous Futures: nur für Daten, nicht für Orders.

IBKR bietet mit dem Security-Typ CONTFUT eine Endlos-Darstellung an: Die API stellt automatisch den jeweils vorderen Kontrakt bereit, damit Sie lange historische Reihen abrufen können. Die Dokumentation der TWS API ist hier eindeutig. Continuous Futures dürfen nur in der TWS API für historische Daten verwendet werden. Sie sind nicht nutzbar für Orders, nicht für Live-Marktdaten, nicht für historische Abfragen mit bestimmtem Enddatum und nicht in der Web API. Der Parameter endDateTime muss bei solchen Abfragen leer bleiben.

Für die Bot-Architektur heißt das: Signalberechnung auf einer Endlosreihe ist möglich, die Order muss aber auf einen konkreten Kontrakt gemappt werden. Das betrifft auch Signale aus Drittplattformen. Ein Chart-Symbol wie „ES1!“ ist eine Darstellung, kein handelbarer Kontrakt. Der Bot braucht eine eigene Zuordnung von „aktueller ES“ zu einer konkreten conId, und diese Zuordnung ändert sich mit jedem Roll.

Ein zweites Werkzeug für die Historie ist das Feld includeExpired. Damit lassen sich in der TWS API Futures referenzieren, die in den letzten zwei Jahren ausgelaufen sind, um ihre historischen Marktdaten abzurufen. Handelbar sind sie nicht, und in der Web API ist die Funktion laut IBKR nicht verfügbar. Für Backtests über mehrere Rolls hinweg reicht das oft nicht: Wer längere Reihen pro Einzelkontrakt braucht, muss sie selbst archivieren oder einen Datenanbieter nutzen. Wichtig ist auch die Methodik: Eine Endlosreihe ohne Rückrechnung (Back-Adjustment) enthält an jedem Roll einen Preissprung, der in einem Backtest wie eine echte Kursbewegung aussieht.

Wie bestimmt der Bot den Roll-Termin?

Der Ausgangspunkt ist reqContractDetails. Die Funktion akzeptiert auch eine unvollständige Kontraktbeschreibung und liefert dann alle passenden Kontrakte einzeln zurück. Eine Abfrage mit Symbol, FUT, Börse und Währung, aber ohne Kontraktmonat, ergibt die Liste der aktiven Kontraktmonate. Futures werden laut IBKR mit Symbol, SecType, Exchange, Currency, lastTradeDateOrContractMonth, Multiplier und TradingClass definiert. Die Antwort (ContractDetails) enthält unter anderem diese Felder:

• contract.conId und contract.localSymbol: eindeutige Kennung und Börsenkürzel des Kontrakts.
• contract.lastTradeDateOrContractMonth: letzter Handelstag bzw. Kontraktmonat.
• realExpirationDate: das tatsächliche Verfallsdatum.
• contractMonth: in der Regel der Kontraktmonat des Basiswerts.
• underConId: die Kennung des Basiswerts bei Derivaten.
• tradingHours, liquidHours, timeZoneId: Handelszeiten und Zeitzone.
• settlementMethod: Abwicklungsart, also physische Lieferung („Physical“) oder Barausgleich („Cash“); laut IBKR-Changelog ab TWS und IB Gateway 10.49.01 enthalten.

Die Zeitzone ist kein Detail: IBKR gibt die Liquidationszeitpunkte in der Close-Out-Tabelle in lokaler Börsenzeit an, ein Bot auf einem Server in UTC muss also umrechnen. Die zweite Quelle ist die Spezifikation der Börse. Die dritte und bei physisch belieferten Kontrakten oft entscheidende ist die Close-Out-Politik von IBKR. IBKR erlaubt bei bestimmten physisch belieferten Futures keine Lieferung. Für diese Kontrakte gilt eine Close-Out-Periode vor dem Verfall, in der IBKR die Position ohne weitere Vorankündigung liquidieren kann. Für die Kenntnis der Frist ist laut IBKR der Kontoinhaber selbst verantwortlich. Die Tabelle von IBKR nennt je Kontrakt eine Frist für Long-Positionen (First Position Date) und eine für Short-Positionen (Last Trading Date). Im Beispiel von IBKR mit Mais-Futures (ZC) musste die Long-Position bis Handelsschluss einen Geschäftstag vor dieser Frist geschlossen sein, danach drohte die Liquidation.

Rechenbeispiel für den Dezember 2026: Der dritte Freitag ist der 18.12.2026, das ist laut Eurex der letzte Handelstag für FDAX; der Handel im auslaufenden Kontrakt endet an diesem Tag schon um 13:00 Uhr MEZ statt am Abend. Solche Rechnungen gehören nicht hart in den Code. Der Bot liest die Daten aus ContractDetails, gleicht sie mit einer gepflegten Kalendertabelle ab und setzt seinen Roll-Termin mit Puffer davor, etwa als „N Handelstage vor der frühesten relevanten Frist“.

Roll-Order umsetzen: Spread oder zwei Legs.

Für die Ausführung gibt es zwei Wege. Der erste ist eine Spread-Order: In der TWS API ist das ein Kontrakt vom Typ BAG mit sogenannten ComboLegs. Jedes Leg braucht laut IBKR eine conId, eine Börse, ein Verhältnis (Ratio) und eine Aktion (BUY oder SELL); Symbole oder lokale Symbole sind für Legs nicht zulässig. Für einen Roll einer Long-Position besteht der Spread aus dem Verkauf des alten und dem Kauf des neuen Monats im Verhältnis 1:1. Futures-Spreads lassen sich laut IBKR auch als Smart-geroutete, nicht garantierte Combos (Non-Guaranteed) definieren; für solche Orders muss das Non-Guaranteed-Kennzeichen auf 1 gesetzt werden. Nicht garantiert heißt: Die gemeinsame Ausführung aller Legs ist nicht zugesichert, das Risiko eines einseitig gefüllten Rolls kehrt also zurück.

Der zweite Weg sind zwei einzelne Orders. Das ist einfacher zu bauen, verlangt aber eine klare Reihenfolge. Wird zuerst der neue Kontrakt gekauft, hält der Bot kurz die doppelte Position, mit entsprechender Margin-Belastung. Wird zuerst der alte geschlossen, ist er kurz ohne Position und trägt das Risiko einer Kurslücke bis zur zweiten Ausführung. Beherrschbar wird das mit einem kleinen Zustandsautomaten:

1. ROLL_DUE: Termin erreicht, Zielkontrakt per conId bestimmt, Positionsgröße aus dem aktuellen Bestand gelesen.
2. LEG1_SENT und LEG1_FILLED: erste Order unterwegs bzw. vollständig ausgeführt; Teilausführungen werden mitgezählt.
3. LEG2_SENT und ROLL_DONE: zweite Order mit der tatsächlich gefüllten Menge aus Schritt 2.
4. ROLL_ERROR: Zeitlimit überschritten, Order abgelehnt oder Verbindung verloren; der Bot stoppt neue Signale und alarmiert.

Jeder Zustand wird gespeichert, damit ein Neustart mitten im Roll nicht zu einer doppelten Order führt. Nach jedem Schritt gleicht der Bot seinen internen Stand mit den Positionen ab, die IBKR meldet. Wie man diesen Abgleich robust baut, zeigt der Artikel Positionsabgleich für Trading-Bots. Für beide Wege gilt: Limit-Orders mit einer Preisgrenze und einer zeitlichen Obergrenze sind in der Regel besser kontrollierbar als Market-Orders, gerade in Phasen mit dünner Liquidität im Folgemonat. Dafür braucht der Bot passende Marktdaten für beide Kontraktmonate: US-Futures-Kurse der Ebene 1 sind laut IBKR im „US Securities Snapshot and Futures Value Bundle“ enthalten.

CME Rule 576 und API User Activity Certification.

CME Rule 576 ist eine Regel der CME zur Identifizierung derjenigen, die Orders an die Handelsplattform Globex geben. Mit Verweis auf diese Regel enthält das Order-Objekt der TWS API das Feld manualOrderIndicator. Laut Referenz kennzeichnet es, ob eine Order manuell (1) oder automatisiert (0) ist. Ein weiteres Feld, extOperator, soll nach derselben Regel den verantwortlichen API-Bediener zum Zeitpunkt des Handels angeben. IBKR schreibt, dass die Vorgaben vor allem diejenigen betreffen, die Futures über die CME handeln. Ob und wie Ihr Konto die Felder setzen muss, ist eine Compliance- und Rechtsfrage; das klären Sie im Einzelfall mit einem Anwalt.

Die zweite Pflicht betrifft das Konto. Nutzer mit US-Futures-Handelsrechten, die über die API handeln, bekommen am Tag nach dem ersten API-Trade die API User Activity Certification zugewiesen, die Abfrage erscheint beim Login. Dort gibt es drei Antworten: keine API-Nutzung (die API-Funktion wird dann deaktiviert), manuell freigegebene API-Orders etwa über eine Drittoberfläche, oder ganz bzw. teilweise automatisch erzeugte und gesendete Orders. Wer per API ohne manuelle Freigabe handelt, soll laut IBKR die dritte Option wählen, die verwendete Software angeben und festlegen, wer die Ordererteilung verantwortet: eine Person, ein wechselndes Team oder je Order.

Für den Roll ist das relevant, weil die Roll-Orders automatisch entstehen. Die Kennzeichnung muss deshalb im gleichen Code-Pfad gesetzt werden wie bei Einstiegs- und Ausstiegsorders. Handelt ein Nutzer anders, als er es in der Zertifizierung angegeben hat, weist IBKR die Aufgabe erneut zu. Ein Bot, der Roll-Orders als manuell markiert, obwohl niemand sie freigibt, passt nicht zu einer Zertifizierung als automatisiertes System.

Testfälle und Alarme rund um den Roll.

Bei Index-Futures mit Quartalsverfall wie FDAX wird viermal im Jahr gerollt, Fehler fallen deshalb spät auf. Testen Sie die Roll-Logik gezielt im Paper-Konto und mit simulierten Zeitpunkten, statt auf den nächsten echten Verfall zu warten. Sinnvolle Testfälle:

• Kontraktwahl: Die Abfrage liefert mehrere Monate; der Bot wählt den richtigen nächsten, auch wenn die Liste unsortiert zurückkommt oder ein Monat fehlt.
• Zeitzonen: Roll-Termin in Börsenzeit, Server in UTC, Umstellung auf Sommer- oder Winterzeit zwischen Planung und Ausführung.
• Teilausführung: Das erste Leg wird nur zum Teil gefüllt; das zweite Leg folgt mit genau dieser Menge.
• Ablehnung: Der neue Kontrakt wird abgelehnt, etwa wegen fehlender Marktdaten oder Margin; der Bot stoppt und meldet sich.
• Neustart mitten im Roll: Der Bot startet zwischen Leg 1 und Leg 2 neu und setzt aus dem gespeicherten Zustand fort, ohne doppelt zu handeln.
• Feiertage: Der geplante Roll-Tag ist an der Börse kein Handelstag.
• Kennzeichnung: Jede Roll-Order trägt die gleiche Kennzeichnung nach Rule 576 wie die übrigen automatisierten Orders.

Im Live-Betrieb gehören Alarme dazu, die nicht vom Erfolg des Rolls abhängen. Sinnvoll sind drei Stufen: eine Vorwarnung einige Handelstage vor dem geplanten Roll, ein Alarm, wenn der Roll zum geplanten Zeitpunkt nicht abgeschlossen ist, und ein dringender Alarm, wenn eine Position im alten Kontrakt einen festgelegten Abstand zur Close-Out-Frist oder zum letzten Handelstag unterschreitet. Den letzten Alarm sollte ein unabhängiger Prozess auslösen, der nur die Positionen bei IBKR liest. So greift er auch, wenn der Bot selbst hängt.

Grenzen und Risiken: Hebel, Lücken, fehlgeschlagene Rolls.

Futures sind gehebelte Produkte. Schon kleine Kursbewegungen verändern das Konto spürbar, und Verluste können die eingesetzte Margin übersteigen. Ein Roll-Fehler verstärkt das. Typische Fehlerbilder sind eine verdoppelte Position, weil ein Neustart die erste Order erneut gesendet hat, eine fehlende Position, weil das zweite Leg abgelehnt wurde, oder eine vergessene Position im alten Kontrakt, die dann in die Close-Out-Periode läuft und von IBKR geschlossen wird. Dazu kommt der Zeitpunkt der Zwangsschließung: Er richtet sich nach der Frist von IBKR, nicht nach Ihrer Strategie, und kann in eine ungünstige Marktphase fallen.

Bei zwei getrennten Orders besteht zwischen den Ausführungen ein Kurslücken-Risiko, bei Spreads mit Non-Guaranteed-Kennzeichen ein Leg-Risiko. Im Folgemonat ist die Liquidität vor dem üblichen Roll-Zeitraum oft geringer, Spreads zwischen Geld und Brief sind breiter. Hinzu kommen Datenrisiken: Endlosreihen ohne Rückrechnung verfälschen Backtests an den Roll-Tagen, und abgelaufene Kontrakte liefern über die API nur noch historische Daten.

Ein Bot kann diese Risiken nicht beseitigen, aber begrenzen: mit Positionslimits, Zeitlimits für jeden Roll-Schritt, einem harten Stopp neuer Signale bei unklarem Zustand und einem Menschen, der die Alarme tatsächlich liest.

Was Sie jetzt konkret tun können.

Wenn Sie einen Futures-Bot an der IBKR-API betreiben oder planen, helfen diese Schritte:

1. Prüfen Sie, ob Ihr Code irgendwo CONTFUT oder ein Endlos-Symbol für Orders verwendet, und ersetzen Sie das durch eine Zuordnung auf die konkrete conId.
2. Legen Sie je Kontrakt eine Roll-Regel fest: Quelle des Termins (ContractDetails, Börsenspezifikation, Close-Out-Tabelle von IBKR), Puffer in Handelstagen, Zeitzone.
3. Entscheiden Sie zwischen Spread-Order und zwei Legs, und dokumentieren Sie für den zweiten Fall die Reihenfolge und die Zwischenzustände.
4. Setzen Sie die Kennzeichnung nach CME Rule 576 zentral für alle automatisierten Orders, und beantworten Sie die API User Activity Certification passend zu dem, was der Bot tatsächlich tut.
5. Spielen Sie die Testfälle aus dem vorigen Abschnitt im Paper-Konto durch, mit simulierten Roll-Terminen.
6. Richten Sie die drei Alarmstufen ein, mit einem unabhängigen Prozess für den letzten Alarm.

Wenn ich Trading-Systeme für Interactive Brokers entwickle, gehört die Roll-Logik mit Zustandsautomat, Positionsabgleich und Alarmen zum Grundgerüst eines Futures-Bots. Wer das nicht selbst bauen will, kann die Umsetzung über die Trading-Automatisierung anfragen; die Live-Aktivierung und die Handelsentscheidungen bleiben beim Kontoinhaber.

Häufige Fragen.

Kann ich mit CONTFUT bei Interactive Brokers Orders platzieren?

Nein. Continuous Futures mit dem SecType CONTFUT sind laut IBKR-Dokumentation nur für historische Daten in der TWS API gedacht. Für Orders, Live-Marktdaten und die Web API sind sie nicht nutzbar. Ein Bot muss das Signal deshalb auf einen konkreten Kontraktmonat mit eigener conId übertragen und diese Zuordnung bei jedem Roll aktualisieren.

Warum schließt Interactive Brokers meine Futures-Position vor dem Verfall?

Bei bestimmten physisch belieferten Futures erlaubt IBKR keine Lieferung. Für diese Kontrakte gilt eine Close-Out-Periode vor dem Verfall, in der IBKR Positionen ohne weitere Vorankündigung liquidieren kann. Die Fristen stehen je Kontrakt in einer Tabelle, getrennt für Long- und Short-Positionen; die Liquidationszeitpunkte sind in lokaler Börsenzeit angegeben. Wer die Position halten will, muss vor der Close-Out Deadline schließen oder rollen.

Wie finde ich per API den nächsten Futures-Kontrakt?

Mit reqContractDetails und einer Kontraktbeschreibung ohne Kontraktmonat, also Symbol, SecType FUT, Börse und Währung. Die API liefert dann alle passenden Kontrakte einzeln zurück. Der Bot sortiert sie nach letztem Handelstag oder realExpirationDate, wählt den Folgemonat und merkt sich dessen conId. Zeitzone und Handelszeiten stehen ebenfalls in den ContractDetails.

Was bedeutet manualOrderIndicator in der IBKR API?

Das Feld gehört zum Order-Objekt der TWS API und folgt laut IBKR-Referenz der CME Rule 576. Es kennzeichnet, ob eine Order manuell (Wert 1) oder automatisiert (Wert 0) erzeugt wurde. Ergänzend gibt es das Feld extOperator für den verantwortlichen API-Bediener. Ob ein bestimmtes Konto die Felder setzen muss, ist eine Compliance- und Rechtsfrage, die im Einzelfall mit einem Anwalt zu klären ist.

Was ist die API User Activity Certification bei Interactive Brokers?

Die API User Activity Certification ist eine Abfrage von IBKR, die Nutzer mit US-Futures-Handelsrechten am Tag nach ihrem ersten API-Trade zugewiesen bekommen. Sie geben an, ob sie die API nicht nutzen, API-Orders manuell freigeben oder Orders automatisch erzeugen lassen. Bei automatisiertem Handel nennen sie die Software und wer die Ordererteilung verantwortet. Weicht das tatsächliche Verhalten ab, weist IBKR die Abfrage erneut zu.

Quellen und Stand.

• Futures (Contract Reference, TWS API) — Interactive Brokers
• Futures Close-Out Policy — Interactive Brokers
• ContractDetails (TWS API Reference) — Interactive Brokers
• Combos & Spreads (Contract Reference, TWS API) — Interactive Brokers
• Order (TWS API Reference): manualOrderIndicator, extOperator — Interactive Brokers
• API User Activity Certification: Introduction — Interactive Brokers
• API User Activity Certification: Automation and Software Disclosure — Interactive Brokers
• DAX Futures: Contract Specifications — Eurex

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

Sie wollen den Roll in Ihrem Futures-Bot für Interactive Brokers sauber automatisieren? Unverbindlich anfragen — wir klären Kontrakte, Roll-Regeln, Tests im Paper-Konto und Alarme für den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.