# Konzept: Eigenes datengetriebenes Trading-Modul („DataDriven")

> Stand: 2026-07-11
> Status: KONZEPT (noch kein Umsetzungsplan). Ziel: ein Strategiemodul, das eigene
> Handelsentscheidungen aus externen Datenquellen ableitet — je Marktkategorie eine
> eigene Datenquelle + ein eigenes Fair-Value-Modell. Die Datenanbindung wird so
> gebaut, dass das ResolutionFarming sie mitnutzen kann (State-aware-Filter, C-S2).

---

## 1. Grundidee

Alle bisherigen Module leiten Signale von ANDEREN ab (Master-Trades, Marktpreise).
DataDriven dreht das um: **Wir berechnen aus Rohdaten eine eigene faire
Wahrscheinlichkeit** und handeln nur, wenn der Marktpreis deutlich davon abweicht:

```
FairValue(Markt) aus Datenquelle → Vergleich mit Marktpreis (Bid/Ask)
→ |FairValue − Preis| > MinEdge (nach Fees) → Order (Maker bevorzugt) → Halten bis Resolution/Ziel
```

Der Edge kommt nicht aus Geschwindigkeit, sondern daraus, die **Daten besser/
konsequenter auszuwerten als der Durchschnitts-Teilnehmer** der jeweiligen Kategorie.
Deshalb ist die Kategorien-Wahl die wichtigste Entscheidung dieses Moduls.

## 2. Architektur (fügt sich in die bestehende Modul-Landschaft)

```
PolyTrader.Modules.DataDriven (IPolyTraderModule, DbPrefix dd_)
│
├── Core-Beitrag (geteilt, auch für ResolutionFarming nutzbar):
│     IMarketStateProvider          // je Kategorie: liefert konservative
│     {                             // Wahrscheinlichkeits-Schätzung + Zustand
│        bool Supports(MarketData m);
│        Task<MarketStateEstimate?> EstimateAsync(MarketData m, CancellationToken ct);
│     }
│     record MarketStateEstimate(decimal ProbLowerBound, decimal ProbUpperBound,
│                                string StateSummary, DateTime AsOf, string Source);
│
├── Provider (je Kategorie ein Adapter, einzeln aktivierbar):
│     WeatherStateProvider          // Open-Meteo/NOAA-Modelläufe
│     SportsScoreStateProvider      // Live-Scores (z. B. API-Football)
│     CryptoStrikeStateProvider     // Binance-Spot + realisierte Volatilität
│     MacroStateProvider            // Nowcasts/Konsensdaten (CPI, Zinsen)
│
├── Services:
│     DdScannerService              // Märkte je aktiver Kategorie laden, FairValue
│                                   // berechnen, Kandidaten mit Edge persistieren
│     DdExecutionService            // Sizing/Limits (Muster: FarmingRiskEngine/
│                                   // Planner wiederverwenden!), Maker-first
│     DdPositionMonitorService      // Re-Evaluation offener Positionen: dreht der
│                                   // FairValue, wird der Exit geprüft (Leiter-Muster)
│
└── Persistenz: dd_settings / dd_candidates / dd_positions / dd_closed_trades
      (Kopie des bewährten rf_-Schemas; Autoincrement-IDs, Kalibrierungs-Historie)
```

**Wichtige Wiederverwendung:** Risk-Engine, Execution-Planner, Fill-Modell,
Resolution-Monitor und UI-Aufbau des ResolutionFarming sind fast 1:1 übertragbar —
DataDriven ist strukturell „ResolutionFarming mit eigener Signalquelle statt
Preisband-Scan". Der Unterschied: DataDriven darf auch UNTER 0.90 kaufen (überall,
wo FairValue ≫ Preis) und optional vor der Resolution verkaufen, wenn der Edge
realisiert ist (Preis hat FairValue erreicht → Kapitalumschlag).

**ResolutionFarming-Synergie (C-S2):** Sobald ein `IMarketStateProvider` für eine
Kategorie existiert, nutzt ihn auch der RF-Scanner: Ein Preis-Dip wird nicht mehr
pauschal gemieden (Momentum-Filter), sondern gegen `ProbLowerBound` geprüft —
Richards 5:1-in-Minute-80-Beispiel wird damit zur Kaufgelegenheit statt zum Reject.

## 3. Kategorien-Bewertung: Wo lohnt sich ein eigenes Modell?

Bewertung nach: Datenlage (frei/billig verfügbar?), Modell-Komplexität,
Bot-Konkurrenz (Stand 2026), Fee-Satz, Kapitalbindung.

| Kategorie | Datenquelle (Kosten) | Modell | Bot-Konkurrenz | Fee | Bindung | Urteil |
|---|---|---|---|---|---|---|
| **Wetter (Tages-Märkte: Temperatur/Niederschlag je Stadt)** | Open-Meteo/NOAA/ECMWF-Läufe (kostenlos) | Modell-Konsens vs. Marktpreis; Update-Lag nutzen | **moderat, wachsend** — Edges von ~10 Pp (2023) auf ~3 Pp (2026) komprimiert, aber vorhanden; dünne Bücher, wenig Retail | 1,25 % | Stunden–Tage | ✅ **Bester Einstieg** |
| **Wetter (Saison: Hurrikane, Rekorde)** | wie oben + NHC | aufwendiger | gering (Kapital-Lockup schreckt ab) | 1,25 % | Wochen–Monate | ⚠️ später (Bindung) |
| **Sport pre-game (kleinere Ligen)** | API-Football o. ä. (~20–30 $/Mon.) | Elo-/Quotenvergleich vs. Buchmacher-Konsens | groß in Top-Ligen, **moderat in Nebenligen** | 0,75 % | Stunden–Tage | ✅ zweiter Kandidat |
| **Sport live (State-Provider)** | wie oben, Live-Scores | Score+Restzeit → P(Sieg), konservative Untergrenze | hoch (Latenz-Bots) — aber wir brauchen nur EINEN Fill unter FairValue, nicht den schnellsten | 0,75 % | Minuten–Stunden | ✅ als RF-Filter; als eigene Strategie nur eng begrenzt |
| **Krypto-Strikes (Wochen/Monat: „BTC über X am Y")** | Binance-WSS (kostenlos) | Distanz zum Strike + realisierte Vol → P | hoch bei 15-min/Stunde, **moderat bei Wochen-Strikes** | 1,8 % ⚠️ | Tage–Wochen | ⚠️ Fee frisst viel; nur bei großem Modell-Edge |
| **Makro (CPI, Zinsentscheide)** | Cleveland-Fed-Nowcast, Konsens-Schätzungen (frei) | Nowcast vs. Marktpreis | moderat, aber informierte Gegenseite | 1,5 % | Tage–Wochen | ⚠️ Nische, wenige Märkte |
| **Politik-Longtail (Nicht-Headline)** | Polls/Aggregatoren | Poll-Modell | gering im Long Tail | 1,0 % | Wochen+ | ⚠️ Bindung + Resolution-Risiko |
| **Kultur/Awards/Mentions** | Box-Office-Daten teils frei; sonst dünn | schwach | **gering** | 1,25–1,56 % | variabel | ❌ Resolution-Risiko (AI-Rater Pflicht), Datenlage schlecht |
| Krypto 15-min/1h Up-Down | Binance | Latenz | **extrem** (Sub-100-ms-Bots) | 1,8 % | Minuten | ❌ nicht unser Spiel |

**Antwort auf „nicht geflutete Kategorien":** Am wenigsten Bot-dominiert sind 2026
(a) **Wetter** — dünne Bücher, Nischenwissen (Stations-Regeln, Modell-Läufe), Retail
meidet die Kategorie; (b) **Long-Tail-/Nebenliga-Sport pre-game**; (c) **Makro-
Nischen** und (d) Long-Tail-Politik. Geflutet sind: Krypto-Kurzfrist, Top-Sport
in-play, Headline-Elections, Arbitrage/NegRisk-Rebalancing. Faustregel: Bots meiden
Kapitalbindung und Nischenwissen — genau dort liegt unser Fenster.

## 4. Empfohlener Aufbau-Pfad

1. **Phase DD-0:** `IMarketStateProvider`-Contract in Core + Modul-Skelett
   (rf_-Schema kopieren). Kein Provider aktiv.
2. **Phase DD-1 (Wetter, read-only):** WeatherStateProvider (Open-Meteo, tägliche
   Temperatur-Märkte 2–3 US-Städte). Scanner läuft wochenlang read-only:
   FairValue vs. Marktpreis loggen → **misst den real verbliebenen Edge, bevor
   irgendetwas gehandelt wird** (dasselbe Kalibrierungs-Gate-Prinzip wie RF).
3. **Phase DD-2:** Demo-Execution (Planner/Fill-Modell aus RF), 4 Wochen.
4. **Phase DD-3:** SportsScoreStateProvider — zuerst NUR als RF-Filter (C-S2:
   Dip-Freigabe bei klarer Führung), erst danach als eigene DD-Strategie.
5. **Phase DD-4:** Live klein (eigener Account, wie bei RF), dann weitere Provider
   nach gemessenem Edge.

## 5. Risiken dieses Moduls (ehrlich)

1. **Modell-Risiko ersetzt Master-Risiko:** Ein Bug/Bias im Fair-Value-Modell
   produziert systematisch falsche Trades. Gegenmittel: read-only-Messphase je
   Provider (DD-1-Prinzip), konservative Untergrenzen statt Punktschätzern.
2. **Edge-Kompression:** Der Wetter-Edge ist dokumentiert am Schrumpfen (10→3 Pp).
   Read-only-Messung VOR jedem Livegang, und die Bereitschaft, eine Kategorie
   wieder abzuschalten, wenn die Messung < MinEdge zeigt.
3. **Regel-Fallen:** Wetter-Märkte lösen nach exakten Stations-Regeln auf — der
   AI-Auflösequalitäts-Rater (separater Plan) und das genaue Lesen der Regeln
   je Markt-Serie sind Pflicht (welche Station, welche Rundung, welcher Zeitraum).
4. **Aufwand:** Jede Kategorie ist ein eigenes kleines Forschungsprojekt. Deshalb:
   strikt eine Kategorie nach der anderen, jede mit eigenem Go/No-Go-Gate.

## 6. Quellen (Kategorien-/Konkurrenz-Einschätzung)

- Polymarket Weather/Climate-Kategorieübersichten (Volumen/Marktzahl):
  https://polymarket.com/predictions/weather, https://polymarket.com/predictions/climate
- Weather-Bot-Funktionsweise & Edge-Kompression 2023→2026:
  https://laikalabs.ai/prediction-markets/polymarket-weather-trading-bot
- Markt-Mikrostruktur/Tiefe Wetter-Märkte: https://polymart.app/blog/polymarket-weather-markets,
  https://polymarkets.co.il/en/guide/weather-guide/