Historische Daten von IBKR per API: Limits und Ladestrategie.

Über die TWS API von Interactive Brokers laden Sie historische Kursdaten mit reqHistoricalData als Bars von einer Sekunde bis zu einem Monat, Time & Sales mit reqHistoricalTicks und den ältesten verfügbaren Zeitpunkt mit reqHeadTimestamp. Für Backtests über mehrere Jahre reicht das bei Aktien, ETFs und Forex auf Minuten- oder Tagesbasis oft aus, die Lücken sind aber systematisch: Bars bis 30 Sekunden gibt es nur für sechs Monate, abgelaufene Optionen und nicht mehr gehandelte Wertpapiere gar nicht, abgelaufene Futures nur bis zwei Jahre nach Verfall. Dazu kommen Pacing-Regeln, die große Abrufe auf Stunden strecken. Dieser Artikel zeigt mit Stand Oktober 2026, welche Historie die API liefert, wie Sie große Zeiträume ohne Pacing-Verstoß stückeln und lokal speichern und ab wann ein spezialisierter Datenanbieter die bessere Grundlage für Ihre Tests ist.

Welche historischen Daten liefert die IBKR-API?

Die TWS API ist die Socket-Schnittstelle von Trader Workstation (TWS) und IB Gateway. Für die Vergangenheit kennt sie drei Funktionen. reqHistoricalData liefert Kerzen (OHLC-Bars) mit Open, High, Low und Close, je nach Datentyp zusätzlich Volumen, Anzahl der Trades und den gewichteten Durchschnittspreis (WAP). reqHistoricalTicks liefert Time & Sales, also einzelne Trades oder Bid/Ask-Änderungen, höchstens 1.000 Datenpunkte je Anfrage und nur für die letzten drei Jahre. reqHeadTimestamp beantwortet die Frage, ab wann für einen Kontrakt und einen Datentyp überhaupt Daten vorliegen.

Was in einer Bar steht, bestimmt der Parameter whatToShow. Für Backtests sind vor allem diese Werte relevant:

• TRADES: gehandelte Preise und Volumen, unter anderem für Aktien, ETFs, Futures, Optionen und Indizes; nur um Splits bereinigt.
• ADJUSTED_LAST: wie TRADES, zusätzlich um Dividenden bereinigt; nur für Aktien, ETFs und Optionen.
• MIDPOINT, BID, ASK, BID_ASK: Quotes statt Trades, ohne Volumen. Bei Forex und CFDs gibt es kein TRADES, dort arbeiten Sie mit diesen Typen.
• HISTORICAL_VOLATILITY, OPTION_IMPLIED_VOLATILITY: Volatilitätsreihen für Aktien, ETFs und Indizes.

Voraussetzung ist ein passendes Marktdatenabo: Laut IBKR decken Level-1-Abos neben Live-Kursen auch historische Bars und historische Ticks ab. Intraday-Zeitstempel kommen standardmäßig in der Zeitzone, die beim TWS-Login gewählt wurde; mit formatDate=2 liefert ib_async sie als UTC-Zeitstempel. Für einen Datenbestand, der über Jahre wächst, ist UTC die robusteste Wahl, weil Sommerzeitwechsel sonst doppelte oder fehlende Stunden erzeugen. Tagesbars kommen ohnehin nur als Datum.

Ein praktischer Hinweis zur Recherche: Am 13.10.2026 hat IBKR die bisherigen Doku-Abschnitte „Market Data: Live“, „Historical“ und „Delayed“ im neuen Abschnitt „Market Data“ zusammengeführt. Ältere Deep-Links aus Foren, Tutorials und Code-Kommentaren können deshalb ins Leere führen.

Bar-Größen und maximale Dauer: die Limits von reqHistoricalData.

Jede Anfrage besteht aus einer Bar-Größe (barSizeSetting) und einer Dauer (durationStr), die vom Endzeitpunkt aus zurückgerechnet wird. Die Dauer hat die Einheiten S (Sekunden), D (Tage), W (Wochen), M (Monate) und Y (Jahre). Die Doku nennt diese Höchstwerte je Anfrage:

Die Tabelle beschreibt, was eine Anfrage formal annehmen darf. 68 Jahre sind kein Versprechen, dass Daten so weit zurückreichen: Wo die Historie tatsächlich beginnt, verrät nur reqHeadTimestamp. Außerdem gilt: Je mehr Bars eine Antwort enthält, desto länger dauert sie. Die verbreitete Python-Bibliothek ib_async bricht eine Anfrage nach dem eingestellten Timeout ab (Standard 60 Sekunden) und gibt dann eine leere Bar-Liste zurück. Eine leere Antwort heißt also nicht automatisch „keine Daten“.

Rechenbeispiel 1-Sekunden-Bars: Ein regulärer US-Handelstag hat 6,5 Stunden, also 23.400 Sekunden. Bei 2.000 Sekunden je Anfrage sind das 12 Anfragen pro Tag. Sechs Monate mit rund 126 Handelstagen ergeben etwa 1.512 Anfragen. Bei höchstens 60 Anfragen in zehn Minuten dauert der Abruf mindestens 252 Minuten, gut vier Stunden, für ein einziges Instrument und einen Datentyp.

Rechenbeispiel 1-Minuten-Bars: Ein regulärer US-Handelstag liefert 390 Bars, ein Jahr rund 98.000. Fünf Jahre in Monatsstücken sind 60 Anfragen. Mit elf Sekunden Pause zwischen den Anfragen, wie im Beispiel weiter unten, sind das elf Minuten reine Wartezeit plus die Antwortzeiten. Für die Planung zählt also vor allem die Bar-Größe, kaum die Hardware.

Welche Daten IBKR nicht liefert: Delistings, abgelaufene Optionen, alte Futures.

Die wichtigste Frage vor einem Backtest ist nicht, wie schnell Sie Daten laden, sondern welche Daten gar nicht existieren. IBKR führt diese Lücken ausdrücklich als allgemeine Einschränkung für alle Plattformen auf:

• Bars bis 30 Sekunden, die älter als sechs Monate sind.
• Abgelaufene Futures, deren Verfall mehr als zwei Jahre zurückliegt. Jüngere abgelaufene Futures erreichen Sie über das Kontraktfeld includeExpired.
• Abgelaufene Optionen, Futures-Optionen (FOPs), Optionsscheine und strukturierte Produkte. Auch End-of-Day-Daten (EOD) für diese Produktarten führt die Doku als nicht verfügbar auf.
• Abgelaufene Future-Spreads und Wertpapiere, die nicht mehr gehandelt werden, also etwa delistete Aktien.
• Eigene Historie für Kombinationen (Combos): Was TWS anzeigt, ist die Summe der einzelnen Beine.
• Daten vor einem Börsenwechsel: Die Doku nennt den ETF SOXX, der am 15.10.2010 an die NASDAQ wechselte; Daten davor sind nicht abrufbar, obwohl der Fonds seit 2001 notiert, auch nicht mit SMART als Exchange.
• Indikatoren wie gleitende Durchschnitte oder Bollinger-Bänder; die rechnen Sie selbst.
• Time & Sales, das älter als drei Jahre ist.

Für Futures bietet die API den Sondertyp CONTFUT (Continuous Futures). Er stellt automatisch den jeweils vorderen Kontrakt dar und funktioniert nur für historische Daten, nicht für Orders, nicht für Live-Kurse und nicht in der Web API. endDateTime muss dabei leer bleiben, die Reihe reicht also immer bis heute, ein gezieltes Zeitfenster in der Vergangenheit lässt sich so nicht abfragen. Welcher Kontrakt jeweils vorne steht und wann gewechselt wird, legt IBKR fest; eine eigene Roll-Regel können Sie dabei nicht vorgeben. Für einen Test, der Ihre eigene Roll-Regel abbilden soll, brauchen Sie die Einzelkontrakte, und die reichen eben nur zwei Jahre nach Verfall zurück.

Bei Aktien ist die Folge noch gravierender: Wer ein Universum aus heutigen Titeln testet, sieht Pleiten, Übernahmen und Delistings nicht. Warum das Ergebnisse systematisch schönt, erklärt der Artikel Survivorship-Bias-freie Aktienuniversen.

Pacing: wie viele historische Anfragen IBKR erlaubt.

Pacing heißt bei IBKR: Begrenzung der Anfragerate. Für historische Daten mit Bars bis 30 Sekunden liegt ein Pacing-Verstoß vor, sobald eine dieser Regeln verletzt wird:

1. identische historische Anfragen innerhalb von 15 Sekunden,
2. sechs oder mehr Anfragen für denselben Kontrakt, dieselbe Exchange und denselben Datentyp innerhalb von zwei Sekunden,
3. mehr als 60 Anfragen in einem beliebigen Zehn-Minuten-Fenster.

BID_ASK-Anfragen zählen doppelt. reqHeadTimestamp fällt unabhängig von der Bar-Größe immer unter diese Regeln und gilt als laufende historische Anfrage, die Sie nach Erhalt der Antwort mit cancelHeadTimestamp beenden sollten; ib_async erledigt das nach der Antwort selbst. Die Limits gelten laut IBKR für alle Kunden und lassen sich nicht ändern. Wer mehr braucht, wird ausdrücklich an spezialisierte Anbieter verwiesen.

Für größere Bars nennt die aktuelle Doku keine eigenen Zahlen. Es bleibt die allgemeine Grenze der TWS API: Anfragen pro Sekunde entsprechen den Marktdatenlinien geteilt durch zwei, bei den standardmäßigen 100 Linien also 50 pro Sekunde. Wird diese Grenze überschritten, hängt die Reaktion von der API-Einstellung „Reject messages above maximum allowed message rate vs applying pacing“ ab: Entweder lehnt TWS mit Fehlercode 100 ab und beendet die Sitzung nach drei Verstößen, oder TWS bremst die Anfragen selbst. Auf diese Grenze sollten Sie einen Datenlader trotzdem nicht auslegen. Große Antworten belasten TWS oder IB Gateway, und ein Lader, der parallel zum laufenden Bot Daten zieht, konkurriert mit dessen Anfragen.

Sinnvoll ist deshalb eine eigene Warteschlange vor der API: höchstens eine Anfrage je Kontrakt alle paar Sekunden, ein gleitendes Zehn-Minuten-Fenster mit Puffer unter 60, keine Wiederholung derselben Anfrage und ein lokaler Cache, damit bereits geladene Stücke nie erneut angefragt werden. Ein Verstoß äußert sich in der Regel als Fehlermeldung des Historical Market Data Service (Code 162); der Lader sollte dann pausieren und nicht sofort erneut senden.

ADJUSTED_LAST, TRADES und keepUpToDate: Fallstricke der Daten.

ADJUSTED_LAST oder TRADES: ADJUSTED_LAST rechnet Splits und Dividenden heraus, TRADES nur Splits. Für Renditevergleiche über lange Zeiträume ist die dividendenbereinigte Reihe näher an der Wirklichkeit eines Haltenden. Sie hat aber eine Eigenschaft, die beim Speichern Probleme macht: Mit jeder neuen Dividende verschieben sich rückwirkend alle älteren Preise. Bei dividendenzahlenden Titeln passt eine Reihe, die Sie im März geladen haben, im Oktober nicht mehr nahtlos an neue Daten. Für Signale, die auf echte Preisniveaus reagieren, etwa Limit-Preise oder runde Marken, ist die bereinigte Reihe ohnehin ungeeignet.

Die saubere Lösung: TRADES als Rohdaten speichern, Splits und Dividenden als eigene Tabelle führen und die Bereinigung beim Backtest selbst rechnen. Dann wissen Sie jederzeit, welcher Preis gehandelt wurde und welcher berechnet ist.

Gefiltertes Volumen: Historische Daten sind um Geschäfte abseits des NBBO (der landesweit besten Geld- und Briefkurse in den USA) bereinigt, etwa Combo-Beine, Blockgeschäfte und Derivate-Trades. Das historische Tagesvolumen ist deshalb in der Regel kleiner als das ungefilterte Echtzeit-Volumen, auch der VWAP weicht ab. Wer Volumenfilter auf historischen Daten kalibriert und live mit Echtzeitdaten rechnet, vergleicht zwei verschiedene Größen. IBKR weist außerdem darauf hin, dass Daten standardmäßig angepasst, komprimiert und gefiltert werden und sich je nach Abrufzeitpunkt unterscheiden können. Wenn Backtests reproduzierbar sein sollen, brauchen Sie einen datierten Snapshot Ihres Bestands.

keepUpToDate: Mit keepUpToDate=True hält die API die letzte, noch offene Bar aktuell, so wie ein TWS-Chart. Das funktioniert nur mit Trades, Midpoint, Bid und Ask, endDateTime muss leer sein, und die Updates kommen etwa alle vier bis sechs Sekunden mit demselben Zeitstempel, bis die Bar abgeschlossen ist. Ein Bot, der auf jedes Update wie auf eine neue Bar reagiert, handelt mehrfach auf dasselbe Signal.

Ladestrategie: Startpunkt finden, stückeln, lokal speichern.

Eine belastbare Ladestrategie folgt immer demselben Muster:

1. Kontrakt eindeutig machen: per reqContractDetails bzw. qualifyContracts die conId festlegen und mit den Daten speichern. Ein Symbol allein ist über Jahre nicht eindeutig.
2. Startpunkt finden: reqHeadTimestamp einmal je Kontrakt und Datentyp abfragen, Ergebnis cachen, Anfrage beenden.
3. Rückwärts stückeln: mit leerem endDateTime beginnen und den ältesten Bar jeder Antwort als neues Ende verwenden. Die Stückgröße so wählen, dass eine Antwort sicher vor dem Timeout fertig ist.
4. Drosseln: Wartezeit zwischen den Anfragen fest einbauen, nicht erst nach dem ersten Fehler.
5. Lokal speichern: Parquet-Dateien oder eine Zeitreihendatenbank, Schlüssel aus conId, Datentyp, Bar-Größe, useRTH und UTC-Zeitstempel. Doppelte Bars an den Stückgrenzen entfernen.
6. Lücken protokollieren statt füllen: fehlende Tage als Lücke markieren und prüfen, ob es Feiertage, Handelsaussetzungen oder Abrufprobleme sind. Warum nachträglich gefüllte Lücken Ergebnisse verzerren, beschreibt der Artikel Backfilling historischer Daten.
7. Inkrementell aktualisieren: danach nur noch den neuen Zeitraum seit dem letzten gespeicherten Bar laden, etwa nachts nach Handelsschluss.

Die folgende Skizze mit ib_async (Stand Oktober 2026 Version 2.1.0, Python ab 3.10) lädt Minutenbars rückwärts in Monatsstücken. Sie verbindet sich mit einer Paper-TWS und ruft nur Daten ab, sendet also keine Orders. Für den Produktivbetrieb fehlen Fehlerbehandlung, Wiederaufnahme nach Abbruch und das Speichern je Stück.

from ib_async import IB, Stock, util
import pandas as pd

ib = IB()
ib.connect("127.0.0.1", 7497, clientId=21)   # Paper-TWS, nur Datenabruf, keine Orders
kontrakt = Stock("AAPL", "SMART", "USD")
ib.qualifyContracts(kontrakt)                 # conId festlegen

start = ib.reqHeadTimeStamp(kontrakt, whatToShow="TRADES", useRTH=True, formatDate=2)

ende, teile = "", []                          # "" = jetzt
while True:
    bars = ib.reqHistoricalData(
        kontrakt, endDateTime=ende, durationStr="1 M", barSizeSetting="1 min",
        whatToShow="TRADES", useRTH=True, formatDate=2, timeout=120)
    if not bars:                              # leer: keine Daten ODER Timeout, protokollieren
        print("leere Antwort vor", ende)
        break
    teile.append(util.df(bars))
    ende = bars[0].date                       # ältester Bar wird neues Ende
    if ende <= start:
        break
    ib.sleep(11)                              # bewusst gedrosselt, unter 60 Anfragen je 10 Minuten

df = pd.concat(teile).drop_duplicates("date").sort_values("date")
df.to_parquet("AAPL_1min_TRADES_RTH.parquet")
ib.disconnect()

Zwei Details sind wichtig: useRTH=True lädt nur die regulären Handelszeiten, und diese Wahl muss im gesamten Bestand einheitlich sein. Und eine leere Antwort wird protokolliert, weil sie ein Timeout sein kann und kein Datenende.

Grenzen und Risiken: wann ein spezialisierter Datenanbieter nötig ist.

IBKR-Daten sind eine gute Grundlage für Tages- und Minutenbars aktiv gehandelter Aktien, ETFs, Forex-Paare und laufender Futures, für die Kalibrierung von Ausführung und Kosten und für den Abgleich zwischen Backtest und Paper- oder Live-Betrieb, weil Sie auf denselben Daten handeln, die Sie auch testen. An Grenzen stoßen sie in diesen Fällen:

• Aktienstrategien über ein breites Universum: Ohne delistete Titel entsteht Survivorship Bias, der Ergebnisse systematisch zu gut aussehen lässt.
• Optionsstrategien: Ohne abgelaufene Optionen gibt es keine Historie für Ketten, Greeks oder Volatilitätsflächen der Vergangenheit.
• Lange Futures-Tests mit eigener Roll-Logik: Einzelkontrakte reichen nur zwei Jahre nach Verfall zurück, CONTFUT folgt der Roll-Logik von IBKR.
• Intraday-Feinanalyse: Sekundenbars nur sechs Monate, Ticks nur drei Jahre.
• Volumenbasierte Signale: gefiltertes historisches Volumen weicht vom Echtzeit-Volumen ab.

In diesen Fällen brauchen Sie in der Regel einen spezialisierten Datenanbieter mit Delistings, Corporate Actions (Splits, Dividenden, Fusionen) und Point-in-Time-Daten, also Daten im Stand des jeweiligen Tages ohne spätere Korrekturen. Prüfen Sie vor dem Kauf, ob die Daten zu den Börsen und Handelszeiten passen, auf denen Sie später über IBKR handeln, sonst entsteht ein neuer Bruch zwischen Test und Betrieb. Klären Sie außerdem die Nutzungsrechte: Marktdaten sind lizenziert, die Weitergabe an Dritte ist in der Regel nicht erlaubt.

Zum Risiko gehört auch die ehrliche Einordnung: Ein Backtest auf sauberen Daten ist kein Beleg für künftige Ergebnisse. Je kürzer die verfügbare Historie, desto größer die Gefahr der Überanpassung an eine einzige Marktphase. Bei gehebelten Produkten wie Futures oder CFDs führen Fehler in Daten oder Positionsgröße schnell zu Verlusten bis hin zum Totalverlust.

Was Sie jetzt konkret tun können.

1. Schreiben Sie auf, welche Instrumente, Bar-Größen, Zeiträume und Datentypen Ihr Backtest wirklich braucht, und gleichen Sie die Liste mit den fehlenden Daten oben ab.
2. Fragen Sie für jedes Instrument reqHeadTimestamp ab, bevor Sie Ladezeiten planen.
3. Rechnen Sie die Zahl der Anfragen aus, besonders bei Sekundenbars, und planen Sie die Wartezeit ein.
4. Entscheiden Sie bewusst zwischen TRADES mit eigener Bereinigung und ADJUSTED_LAST und dokumentieren Sie die Wahl.
5. Bauen Sie den Lader mit Drosselung, Cache, UTC-Zeitstempeln und Lückenprotokoll, testen Sie ihn mit einem Paper-Account und frieren Sie den Datenstand als datierten Snapshot ein.
6. Prüfen Sie, ob Delistings, abgelaufene Optionen oder lange Futures-Historien nötig sind. Wenn ja, planen Sie einen spezialisierten Datenanbieter ein, bevor Sie Strategie-Code schreiben.

Wenn Sie den Datenlader und die Backtest-Umgebung nicht selbst bauen wollen, entwickle ich das als Teil eines Trading-Systems nach Ihren Vorgaben, von der Datenstrecke über Tests mit echten Kosten bis zum Betrieb; mehr dazu unter Trading-Automatisierung.

Häufige Fragen.

Wie weit reichen historische Daten bei Interactive Brokers zurück?

Das hängt von Bar-Größe und Instrument ab. Bars bis 30 Sekunden gibt es nur für die letzten sechs Monate, Time & Sales nur für drei Jahre. Minuten-, Stunden- und Tagesbars reichen bei aktiv gehandelten Aktien oft viele Jahre zurück. Den tatsächlichen Beginn für einen Kontrakt und Datentyp liefert die Funktion reqHeadTimestamp der TWS API.

Wie viele historische Datenanfragen erlaubt die IBKR-API?

Für Bars bis 30 Sekunden gelten feste Regeln: keine identische Anfrage binnen 15 Sekunden, nicht sechs oder mehr Anfragen für denselben Kontrakt binnen zwei Sekunden und höchstens 60 Anfragen in zehn Minuten. BID_ASK zählt doppelt. Darüber hinaus gilt die allgemeine Grenze von Marktdatenlinien geteilt durch zwei pro Sekunde, standardmäßig 50.

Liefert IBKR historische Daten von delisteten Aktien?

Nein. Laut Doku sind Daten für Wertpapiere, die nicht mehr gehandelt werden, nicht verfügbar. Ein Backtest über ein Aktienuniversum aus heutigen Titeln enthält deshalb keine Pleiten oder Übernahmen und ist anfällig für Survivorship Bias. Für solche Tests braucht es in der Regel einen spezialisierten Datenanbieter mit Delistings.

Was ist der Unterschied zwischen ADJUSTED_LAST und TRADES bei IBKR?

TRADES liefert gehandelte Preise, die nur um Aktiensplits bereinigt sind. ADJUSTED_LAST ist zusätzlich um Dividenden bereinigt und nur für Aktien, ETFs und Optionen verfügbar. Weil sich die bereinigte Reihe mit jeder neuen Dividende rückwirkend ändert, empfiehlt es sich, TRADES als Rohdaten zu speichern und die Bereinigung selbst zu rechnen.

Kann ich mit CONTFUT Futures über viele Jahre backtesten?

Eingeschränkt. CONTFUT liefert eine fortlaufende Reihe des jeweils vorderen Kontrakts, aber nur als historische Daten bis heute, mit leerem Enddatum und nach der Roll-Logik von IBKR. Einzelne abgelaufene Kontrakte sind nur bis zwei Jahre nach Verfall abrufbar. Für eigene Roll-Regeln über lange Zeiträume brauchen Sie meist einen spezialisierten Datenanbieter.

Quellen und Stand.

• Historical Bars (OHLC) — Interactive Brokers, TWS API Documentation
• Market Data (Abschnitt Historical Data Limitations) — Interactive Brokers, TWS API Documentation
• Earliest Data Point — Interactive Brokers, TWS API Documentation
• Historical Time & Sales — Interactive Brokers, TWS API Documentation
• Contract Reference: Futures (Continuous und Expired Futures) — Interactive Brokers, TWS API Documentation
• Pacing Limitations: Introduction — Interactive Brokers, TWS API Documentation
• Understanding Market Data Subscriptions — Interactive Brokers
• TWS API Changelog, 13.10.2026 — 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 historische IBKR-Daten sauber für Ihre Backtests laden und aufbereiten lassen? Unverbindlich anfragen — wir klären Datenbedarf, Ladestrategie und Speicherung, bevor die erste Zeile Strategie-Code entsteht. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.