Sentinel - Plattform für Trading-Strategien

Das Problem

Die meisten Retail-Trading-Tools erzwingen eine Wahl. Nutze ein Backtesting-Framework: deine Strategie lebt in einem mentalen Modell, ausgelegt fürs Wiederabspielen historischer Bars. Nutze eine Plattform für Live-Ausführung: schreibe die Strategie in einem anderen mentalen Modell neu, mit anderen Gebührenannahmen, anderen Order-Typen, anderen State Machines. Jeder Rewrite ist eine Gelegenheit, dass das Live-Verhalten still und leise von dem abweicht, was der Backtest versprochen hat.

Die Plattformen, die beides zu vereinen versuchen (QuantConnect, MetaTrader, die größeren institutionellen Tools), sind entweder zu teuer, an einen bestimmten Broker gebunden oder um meinungsstarke Strategy-DSLs gebaut, die die Multi-Source-Signal-Aggregation, die echte systematische Strategien brauchen, nicht ausdrücken können.

Sentinel wurde gebaut, um den Rewrite überflüssig zu machen. Von "Idee" zu "validiert gegen vier Jahre historische Daten" sollte ein einziger CLI-Befehl reichen. Von validiert zu Live-Paper-Trading sollte ein Config-Flip reichen. Und der Code-Pfad zwischen diesen beiden Zuständen sollte derselbe Code-Pfad sein.

Der Ansatz

Sentinel ist ein Python + FastAPI-Backend mit einem Vue-3-Dashboard, das auf TimescaleDB läuft. Drei architektonische Entscheidungen tragen die Plattform.

Eine Execution-Engine, zwei Betriebsarten. Ein gemeinsames Execution-Modul modelliert Gebühren, Slippage, Teilausführungen, Bracket-Orders (Parent + Take-Profit + Stop-Loss als ein atomarer Submit) und Exit-Stufen. Sowohl der Live-Runner als auch die Backtest-Replay-Engine rufen dasselbe Modul auf. Der einzige Unterschied zwischen den Betriebsarten ist die Quelle der Wahrheit: Alpacas API für Live, OHLCV-Bar-Daten für Backtest. Gleiches Gebührenmodell, gleiche Lot-Aufteilung, gleiche Exit-Logik. Kein Drift.

Ein Signal-Store, zwei Zugriffsmuster. Jedes Signal, aus jeder Quelle, für jedes Asset, zu jedem Zeitstempel, lebt in einer einzigen TimescaleDB-Hypertable, indiziert nach (asset, source_id, ts). Backtest fragt sie mit ts <= X ab, um Point-in-Time-Korrektheit zu erzwingen: kein Durchsickern zukünftiger Daten in historische Entscheidungen. Live fragt sie mit latest ab. Ein Datenmodell bedient beide Betriebsarten; Backtest-Genauigkeit und Live-Entscheidungsfindung teilen sich dieselbe Quelle der Wahrheit.

Pure-Function-Scorer, komponierbare Signale. Jede Signalquelle (RSI, MACD, Fear-Greed, Claude-kalibriertes News-Sentiment usw.) ist eine reine Funktion: bei gegebenem Kontext liefert sie ein Tupel (score in [-100, +100], confidence). Das Composite ist Σ (source_score × weight × confidence/100), normalisiert gegen Schwellen pro Asset. Eine neue Quelle hinzuzufügen heißt eine Scorer-Funktion plus ein Config-Eintrag, und sie steht sofort sowohl im Backtest- als auch im Live-Modus zur Verfügung.

Die Claude-Integration verdient eine eigene Erwähnung. Die meiste LLM-getriebene Sentiment-Arbeit ist Klassifikation ("bullish/bearish/neutral"): grob, schwer zu gewichten, schwer zu debuggen. Sentinel nutzt Claude für kalibriertes numerisches Scoring: bei einem Batch von News-Headlines für ein Asset liefert das Modell ein strukturiertes {sentiment: -100..+100, confidence: 0..100, reasoning: string}. Der Reasoning-String wird neben jedem Score gespeichert, zur Auditierbarkeit. Wenn eine Strategie aufgrund von News-Sentiment auslöst, kann später nachgelesen werden, warum das Modell so bewertet hat.

Operativ: GitHub Actions deployen in ~90 Sekunden über ein idempotentes Deploy-Skript auf Hetzner. Postgres wird täglich nach S3 gesichert. HetrixTools-Monitoring mit Slack-Alerts. Eine source_health-Tabelle verfolgt für jede externe Integration den letzten Erfolg und die rollierende Fehlerrate, sichtbar im Dashboard, sodass ein ausgefallener News-Feed oder ein RPC-Ausfall sofort auffällt.

Das Ergebnis

Sentinel ist in aktiver Entwicklung und läuft live im Paper-Trading-Modus gegen die Alpaca-API. Die erste Strategie, validiert per Walk-Forward-Analyse, eine Opening-Range-Breakout-Strategie, führt echte Bracket-Orders gegen aktuelle Marktdaten aus. Composite-Multi-Source-Scoring läuft über vier Crypto- und vier Equity-Ticker, mit 8 gewichteten Quellen pro Asset.

Drei Strategien wurden bisher gebaut und ausgewertet: die ORB-Strategie (validiert, live), Mean Reversion (per Walk-Forward verworfen und beiseitegelegt) und eine Composite-Stocks-Variante (nur mit MACD validiert und zurückgestellt, bis der Quellen-Mix abgestimmt ist). Verworfene Ergebnisse bleiben im Engineering-Protokoll: negative Ergebnisse sind für die Iteration der Strategie genauso informativ wie positive.

Walk-Forward-Validierung über ein Vier-Jahres-Fenster mit zwölf Splits und einem vollständigen Threshold-Grid läuft in etwa fünf Minuten. Rund 38.000 Signal-Zeilen werden alle 30 Tage erzeugt. Neun externe Integrationen werden live verfolgt (FRED, Polygon, Etherscan, Helius RPC, News-Feeds, Reddit, Alpaca, Solscan, LunarCrush), mit Health-Anzeige im Dashboard.

Als nächstes: weitere Broker-Anbindungen, erweiterte Asset-Klassen und ein Early-Access-Programm für systematische Trader.