IBKRTrader/docs/konzepte/KONZEPT-Datenlage-und-Strategien.md

# Analyse: Datenlage über die TWS API – und welche Strategien sie trägt

> Stand: 2026-08-04. **Alle Angaben in Abschnitt 1 und 2 sind gegen das laufende Paper-Gateway
> gemessen** (Konto DUR371528, TWS API 9.76.1, `MarketDataType = 4`), nicht aus der IBKR-Doku
> übernommen. Wo etwas nur plausibel, aber ungeprüft ist, steht es ausdrücklich dabei.
>
> Zweck: entscheiden, welche Strategien wir **ohne zusätzliche Datenanbieter** bauen können –
> und welche wir uns sparen, weil die Datengrundlage fehlt.

---

## 0. Kurzfassung

Die TWS API deckt **Preis-, Volatilitäts- und Optionsdaten sehr gut ab** und **Fundamentaldaten
gar nicht**. Zwei Grenzen bestimmen den Zuschnitt jeder Strategie:

1. **Kein Screening.** Der Marktscanner ist gesperrt (Realtime-Abo nötig). Wir können den Markt
   nicht nach Kandidaten durchsuchen – jede Strategie muss auf einer **fest gepflegten Watchlist**
   arbeiten. Das deckt sich mit der Festlegung im [OptionsWheel-Konzept](KONZEPT-Modul-OptionsWheel.md).
2. **Nur verzögerte Kurse (~15 Min).** Alles, was auf Intraday-Reaktion beruht, fällt weg.
   Entscheidungen auf Tages- oder Wochenbasis sind davon **nicht** betroffen.

Innerhalb dieser Grenzen ist die Lage gut: 30 Jahre Kurshistorie, dividendenbereinigte Serien,
Volatilitätshistorie, vollständige Optionsketten und **funktionierende Griechen auch mit
verzögerten Daten**. Das trägt Prämienstrategien und Trendfolge auf Tagesbasis ohne jeden
externen Anbieter.

**Empfehlung:** OptionsWheel als erstes Modul weiterbauen – es ist die Strategie mit dem besten
Verhältnis von vorhandener Datengrundlage zu Ertragserwartung, und die Voraussetzungen sind
inzwischen alle geprüft.

---

## 1. Was die API liefert (gemessen)

### 1.1 Kurshistorie – die stärkste Säule

| Auflösung | Verfügbarer Zeitraum | Gemessen an AAPL |
|---|---|---|
| Monatsbars | **30 Jahre** | 361 Bars ab 1996-08 |
| Wochenbars | 15 Jahre | 783 Bars ab 2011-08 |
| Tagesbars | 10 Jahre | 2.511 Bars ab 2016-08 |
| Stundenbars | 2 Jahre | 3.488 Bars |
| Minutenbars | 30 Tage | 11.453 Bars |
| Einzelticks | `reqHistoricalTicks` | 351 Ticks für 2 Tage zurück |

Zusätzlich:
- **`ADJUSTED_LAST`** – dividendenbereinigte Tageskurse. Wichtig: unbereinigte Serien erzeugen bei
  jeder Ausschüttung ein Scheinsignal in Momentum- und Mean-Reversion-Rechnungen.
- **`HISTORICAL_VOLATILITY`** – realisierte Volatilität als Zeitreihe (122 Tage je Abruf).
- **`OPTION_IMPLIED_VOLATILITY`** – **IV-Historie des Basiswerts** (122 Tage je Abruf).
  Längere Reihen lassen sich durch wiederholte Abrufe mit gesetztem `endDateTime` zusammensetzen.

Die letzten beiden sind der eigentliche Schatz: aus ihnen lässt sich **IV-Rank / IV-Perzentil**
rechnen – die zentrale Kennzahl für jede Prämienstrategie (verkaufe Volatilität, wenn sie relativ
zu ihrer eigenen Geschichte teuer ist).

### 1.2 Optionen

| Datenart | Ergebnis |
|---|---|
| Optionskette (`reqSecDefOptParams`) | 24 Verfallstermine, 127 Strikes, Multiplier 100, TradingClass |
| Griechen (`tickOptionComputation`) | **IV, Delta, Gamma, Vega, Theta + Basiswertkurs** |
| Handelsberechtigung | vorhanden (What-If-Order angenommen) |

**Wichtigster Einzelbefund:** Die Griechen kommen **auch ohne Realtime-Abo**. Gemessen an
`AAPL 20260821 C305`: IV 0,2730 / Delta 0,5443 / Gamma 0,0220 / Vega 0,2626 / Theta −0,2304.
Sie laufen über die verzögerten Tick-Felder 80–83, wobei **Feld 83 (Modell) die relevante Größe**
für eine delta-basierte Strike-Wahl ist.

Damit ist der offene Punkt 2 aus dem [OptionsWheel-Konzept](KONZEPT-Modul-OptionsWheel.md)
beantwortet: Die geplante delta-basierte Strike-Wahl im Zielband 0,15–0,30 ist umsetzbar, die
Ersatzlösung über prozentualen Abstand wird nicht gebraucht. Verzögerung heißt: Der Delta-Wert ist
~15 Minuten alt – für die Auswahl eines Strikes mit 30–45 Tagen Restlaufzeit ist das belanglos.

### 1.3 Stammdaten, Nachrichten, Sonstiges

| Datenart | Ergebnis |
|---|---|
| Kontraktstammdaten | Branche/Kategorie/Unterkategorie (AAPL: Technology / Computers / Computers), Langname, **Handelszeiten**, Zeitzone, MinTick, gültige Börsen |
| Symbolsuche (`reqMatchingSymbols`) | Fuzzy-Suche, liefert auch Indizes |
| Nachrichten | 3 Anbieter: **BRFG** (Briefing.com Markt), **BRFUPDN** (Analystenaktionen), **DJNL** (Dow Jones Newsletters) |
| Historische Nachrichten | funktioniert, Schlagzeilen mit Zeitstempel und Anbieter |
| Konto, Bestand, Ausführungen | siehe [IBKR-Integration.md](../IBKR-Integration.md) |

Die Branchenklassifikation ist brauchbar für **Klumpenrisiko-Prüfungen** ("nicht drei Positionen
im selben Sektor"). Die Handelszeiten sind operativ wichtig: Market-Orders außerhalb der RTH
bleiben ohne Fill hängen.

`BRFUPDN` ist bemerkenswert – die Schlagzeilen sind maschinell auswertbar strukturiert:

```
2026-04-17 12:00:57 [BRFUPDN] !BNP Paribas Exane upgraded Apple (AAPL) to Outperform
2026-04-14 14:58:42 [BRFUPDN] !BofA Securities reiterated Apple (AAPL) coverage with Buy and target $325
```

---

## 2. Was die API nicht liefert

| Datenart | Fehler | Bedeutung |
|---|---|---|
| **Fundamentaldaten**, alle Reports (`ReportSnapshot`, `ReportRatios`, `ReportsFinStatements`, `RESC`, `CalendarReport`) | 10358 „Fundamentaldaten nicht zulässig" | Kein Refinitiv-Abo auf dem Konto |
| **Fundamentalkennzahlen-Tick 258** (KGV, Marktkapitalisierung, Dividendenrendite, Beta) | 10358 | dito |
| **Marktscanner-Ausführung** (alle getesteten scanCodes) | 492 „zusätzliche Berechtigungen" | Realtime-Marktdatenabo nötig |
| **Realtime-Kurse** | 10167 / 10091 | nur verzögerte Daten (~15 Min) |
| **Histogramm** (`reqHistogramData`) | leer | ungeklärt, vermutlich abo-abhängig |

Die **Scanner-Parameter** (762 scanCodes) lassen sich zwar abrufen, aber nur als Metadaten – jeder
Scanner-Lauf wird abgelehnt.

### Drei Konsequenzen, die den Zuschnitt bestimmen

1. **Keine fundamentale Titelauswahl.** Kennzahlenbasierte Ansätze (Value, Quality, Growth) sind
   ohne Zusatzquelle nicht baubar. Das ist verkraftbar, weil unsere beiden geplanten Module
   (CongressTrading, OptionsWheel) ihre Kandidaten ohnehin anders bestimmen.
2. **Keine Termine für Quartalszahlen.** `CalendarReport` ist gesperrt. Damit ist der offene
   Punkt 4 des OptionsWheel-Konzepts („Earnings-Sperre") **nicht** über die TWS API lösbar – er
   braucht eine externe Quelle oder eine manuell gepflegte Liste. Das ist die einzige Stelle, an
   der uns eine externe Abhängigkeit ernsthaft fehlt.
   Behelf ohne externe Quelle: Ein **IV-Anstieg** vor Quartalszahlen ist messbar. Ein Filter
   „keine neuen Legs, wenn die IV des Basiswerts stark über ihrem 30-Tage-Mittel liegt" fängt
   Earnings indirekt mit ab – unschärfer, aber ohne Fremddaten.
3. **Kein Universum-Screening.** Strategien müssen mit einer gepflegten Watchlist auskommen.

---

## 3. Strategiebewertung

### 3.1 Gut umsetzbar – Datenlage vollständig

| Strategie | Benötigte Daten | Status |
|---|---|---|
| **Options-Wheel** (Cash-Secured Put → Zuteilung → Covered Call) | Kette, Griechen, IV-Historie, Bestand, Berechtigung | alles vorhanden, [Konzept steht](KONZEPT-Modul-OptionsWheel.md) |
| **Covered Calls auf Bestand** | wie oben, ohne Put-Seite | Teilmenge des Wheel |
| **IV-Rank-gesteuerter Prämienverkauf** | `OPTION_IMPLIED_VOLATILITY` + `HISTORICAL_VOLATILITY` | vorhanden; liefert das Timing-Kriterium für das Wheel |
| **Trendfolge auf Tagesbasis** (gleitende Durchschnitte, Ausbrüche, ATR-Stops) | `ADJUSTED_LAST` Tagesbars, 10 J | vorhanden |
| **Relative Stärke / Dual Momentum** über die Watchlist | Tagesbars mehrerer Titel | vorhanden |
| **Mean Reversion** (RSI, Bollinger, Abstand zum gleitenden Mittel) | Tagesbars | vorhanden |
| **Paar-Handel** korrelierter Titel | Tagesbars, lange Historie | vorhanden |
| **Saisonalität / Kalendereffekte** | 30 Jahre Monatsbars | vorhanden |
| **Sektor-Klumpenrisiko-Prüfung** | Branchenklassifikation | vorhanden; gehört in den `RiskService` |

Allen gemeinsam: Sie entscheiden **auf Schlusskursen oder mit Stunden-/Tagesbezug**. Die
15-Minuten-Verzögerung ist dabei irrelevant, weil die Signale ohnehin aus abgeschlossenen Bars
kommen. Genau deshalb passen sie zu unserer Datenlage.

### 3.2 Bedingt umsetzbar

| Strategie | Einschränkung |
|---|---|
| **Analystenaktionen als Filter oder Signal** (`BRFUPDN`) | Schlagzeilen sind strukturiert und auswertbar. **Ungeprüft**: ob `reqNewsArticle` den Volltext liefert und wie weit die Historie zurückreicht. Als *Risikofilter* („keine neue Position kurz nach einer Abstufung") wertvoller denn als Einstiegssignal. |
| **Volatilitäts-Ausbruch intraday** | Minutenbars gibt es (30 Tage), aber nur verzögert. Rückrechnung möglich, Live-Handel nicht. |
| **Gap-Strategien auf Eröffnung** | Eröffnungskurs kommt verzögert; die Ausführung träfe den Markt 15 Minuten zu spät. Nur mit Realtime-Abo sinnvoll. |

### 3.3 Nicht umsetzbar

| Strategie | Grund |
|---|---|
| Fundamentales Screening (Value, Quality, Growth) | keine Fundamentaldaten |
| Earnings-Strategien (Straddle vor Zahlen, Post-Earnings-Drift) | keine Termine für Quartalszahlen |
| Marktweite Anomalie-Suche / Screener-getriebene Auswahl | Scanner gesperrt |
| Daytrading, Scalping, Orderbuch-Strategien | verzögerte Daten, keine Markttiefe geprüft |
| Nachrichten-Sentiment in der Breite | nur 3 Anbieter, Schlagzeilen |

---

## 4. Empfehlung

**Reihenfolge:**

1. **OptionsWheel** wie im [bestehenden Konzept](KONZEPT-Modul-OptionsWheel.md) bauen. Alle
   Voraussetzungen sind jetzt geprüft: Berechtigung, Kette, Griechen mit verzögerten Daten,
   Bestandsabgleich. Der einzige offene Punkt ist die Earnings-Sperre – dafür zunächst den
   IV-Behelf aus Abschnitt 2 einsetzen und die Entscheidung über eine externe Quelle vertagen.
2. **IV-Rank als Core-Baustein** ziehen, nicht als Modul-Interna. Die Kennzahl ist für jede
   Prämienstrategie nötig und gehört neben die Kurshistorie in die Datenschicht.
3. **Trendfolge/Momentum auf Tagesbasis** als zweites Modul, wenn ein zweites Standbein gewünscht
   ist. Datenlage ist komfortabel, das Risiko liegt in der Strategie, nicht in den Daten.

**Was ein Zusatzabo ändern würde** (Reihenfolge nach Nutzen je Euro):

| Abo | Schaltet frei | Für uns relevant? |
|---|---|---|
| US-Aktien-Realtime (NYSE/AMEX/NASDAQ) | Scanner, Realtime-Kurse | Nur wenn wir Screening oder Intraday wollen. Für Tages- und Prämienstrategien **nicht nötig**. |
| OPRA (Optionen-Realtime) | Realtime-Optionskurse und -Griechen | Verbessert die Ausführungsqualität beim Wheel; für die Strike-Auswahl nicht erforderlich. |
| Refinitiv-Fundamentaldaten | Kennzahlen, Bilanzen, **Termine für Quartalszahlen** | Löst die Earnings-Sperre und öffnet fundamentale Ansätze. Der Kandidat mit dem größten qualitativen Sprung. |

Alle drei sind **Erweiterungen, keine Voraussetzungen**. Der aktuelle Stand trägt die geplanten
Strategien.

---

## 5. Offen / ungeprüft

1. **`reqNewsArticle`** (Volltext zu einer Schlagzeile) – nicht getestet. Entscheidet, ob
   `BRFUPDN` mehr als ein Ereignis-Marker sein kann.
2. **Wie weit die Nachrichtenhistorie zurückreicht** – im Test kamen Meldungen bis 2026-03,
   abgefragt waren 30 Tage. Die Zeitfilter-Semantik ist offenbar anders als angenommen und
   sollte vor produktiver Nutzung geklärt werden.
3. **Markttiefe** (`reqMktDepth`) – nicht getestet, für unsere Strategien vermutlich unnötig.
4. **`reqHistogramData`** liefert leer – Ursache ungeklärt (Abo oder Parameter).
5. **Wie zuverlässig verzögerte Griechen außerhalb der Handelszeiten sind** – gemessen wurde
   während der US-Handelszeit. Außerhalb liefert TWS ggf. eingefrorene Werte.
6. **Ratenbegrenzung** bei Historienabrufen (IBKR drosselt `reqHistoricalData` bei zu vielen
   Anfragen). Für einen nächtlichen Watchlist-Abruf relevant, im Test nicht ausgereizt.