Risiko beginnt beim Gesamtkonto, nicht beim Einstiegssignal
Die CFTC weist darauf hin, dass Kryptoassets volatil sind und Hebel Verluste verstärkt. Bei Futures kann eine ungünstige Bewegung Nachschuss oder Liquidation auslösen. Ein Bot beseitigt dieses Marktrisiko nicht. Er kann es sogar schneller vervielfachen, wenn mehrere Strategien dieselbe Exponierung aufbauen.
Das Risikomodell muss deshalb Konto, Strategie, Markt und technische Ausführung verbinden. Ein Stop-Loss pro Order reicht nicht, wenn drei Bots gleichzeitig BTC long handeln oder wenn ein fehlerhafter Webhook denselben Auftrag wiederholt. Ausgangspunkt ist ein Verlustbudget, das auch Gebühren, Slippage, Funding und offene Orders berücksichtigt.
| Ebene | Kontrolle | Messgröße |
|---|---|---|
| Konto | maximales Brutto- und Netto-Exposure | Positionswert und Delta über alle Strategien |
| Strategie | Kapital- und Verlustbudget | realisierter plus offener P&L |
| Symbol | Klumpenlimit | Positionen und offene Orders pro Markt |
| Order | Größe, Preisabweichung, Reduce-only | Nominal, Limitpreis und aktueller Positionsstatus |
| Technik | Fehlerrate und Datenalter | API-Antworten, Heartbeat und letzte Synchronisation |
Der Krypto-Trading-Bot-Leitfaden erklärt Strategie und Betrieb; hier geht es ausschließlich um Kontrollen.
Limits müssen eindeutig und gemeinsam wirken
Es gibt keine universell sichere Hebel- oder Stop-Distanz. Volatilität, Liquidität, Margin-Modell und Strategie unterscheiden sich. Seriöse Voreinstellungen sind konservative Startwerte, keine Renditegarantie. Jedes Limit braucht eine definierte Bezugsgröße, Zeitzone und Reaktion.
- Maximales Exposure: offene Positionen plus noch ausführbare Orders zählen.
- Leverage-Cap: geringer als das Börsenmaximum und zum Margin-Modell passend.
- Tagesverlust: realisierte und offene Verluste sowie Gebühren definieren.
- Drawdown-Limit: vom festgelegten Equity-Hoch, nicht von einer beliebigen Einzahlung.
- Symbol-Limit: korrelierte Märkte und mehrere Bots zusammenfassen.
- Orderrate: Burst, Retry und Exchange-Rate-Limits begrenzen.
- Datenalter: keine neuen Orders bei veraltetem Markt- oder Kontostand.
- Liquiditätsfilter: Spread, Markttiefe und maximale Slippage berücksichtigen.
Bei DCA- oder Mean-Reversion-Strategien ersetzt „kein enger Stop“ nicht das Risikoende. Dann müssen maximale Nachkäufe, Gesamtgröße, Zeitlimit oder ein harter Portfolio-Stopp feststehen. Der Artikel zum Binance-Futures-Bot beschreibt die zusätzliche Margin- und Liquidationsdimension.
Exposure-Limit mit offenen Orders durchrechnen
Ein Konto hat ein freigegebenes Exposure-Limit von 20.000 Euro. Bereits offene Positionen beanspruchen 12.000 Euro; noch nicht gefüllte, risikosteigernde Orders könnten weitere 5.000 Euro eröffnen. Für einen zusätzlichen Einstieg über 4.000 Euro wäre die mögliche Gesamtbelastung 12.000 + 5.000 + 4.000 = 21.000 Euro. Er wird abgelehnt, obwohl allein die aktuellen Positionen noch unter dem Limit liegen. Ohne andere Änderungen bleiben rechnerisch höchstens 3.000 Euro Spielraum.
Die Rechnung setzt eine gemeinsame Definition von Exposure und konsistente Preise voraus; sie ist kein allgemeiner Binance-Marginrechner. Hebel reduziert möglicherweise die gebundene Initial Margin, aber nicht automatisch die wirtschaftliche Positionsgröße. Korrelation, Kurslücken und Gebühren können zusätzliche Reserve verlangen.
Prüfen Sie außerdem zwei gleichzeitig eintreffende Einstiege. Wenn beide denselben freien Spielraum lesen, darf nicht jeder ihn vollständig reservieren. Für unbekannte Orderstatus bleibt die risikosteigernde Menge bis zum Abgleich berücksichtigt. Eine bestätigte Stornierung kann Reserve freigeben; die gesendete Stornierungsanfrage allein kann es nicht. Risikoreduzierende Schließungen und Schutzorders benötigen eine eigene Behandlung, damit ein Entry-Stopp bestehende Risiken nicht festschreibt.
Orderausführung ist ein verteiltes System
Eine Timeout-Antwort beweist nicht, dass keine Order angelegt wurde. Der Bot darf deshalb nicht blind erneut senden. Jede Handelsabsicht benötigt eine eindeutige Client-Order-ID, einen dauerhaften Status und eine nachgelagerte Abfrage bei der Börse. Erst die bestätigte Börsenrealität aktualisiert die interne Position.
- Signal normalisieren und fachlich validieren.
- Risikoprüfung auf aktuellem Konto-Snapshot durchführen.
- Handelsabsicht mit eindeutiger ID dauerhaft speichern.
- Order senden und Antwort protokollieren.
- Bei Timeout Status über Order-ID abfragen, nicht sofort duplizieren.
- Teilausführungen, Storno und Gebühren übernehmen.
- Position regelmäßig unabhängig mit der Börse abgleichen.
Retries brauchen Backoff und Obergrenzen. Eine Endlosschleife kann aus einem temporären Fehler eine Orderflut machen. Nicht dokumentierte oder inoffizielle API-Eigenschaften dürfen laut Binance-Entwicklerdokumentation nicht für den Produktionsbetrieb vorausgesetzt werden.
Ein Kill Switch braucht definierte Zustände
„Bot stoppen“ kann drei verschiedene Maßnahmen bedeuten: keine neuen Orders, offene Orders stornieren oder Positionen schließen. Die letzte Variante erzeugt selbst Marktorders und kann bei illiquiden Märkten zusätzlichen Verlust verursachen. Deshalb darf ein Kill Switch nicht als einzelner unklarer Button implementiert sein.
| Zustand | Wirkung | Typischer Auslöser |
|---|---|---|
| Pause | keine neuen Entries, Überwachung bleibt aktiv | Daten verspätet oder Strategieprüfung |
| Cancel | zusätzlich offene Orders stornieren | Orderstatus unsicher oder Limit verletzt |
| Reduce only | nur risikoreduzierende Orders erlauben | Exposure über Ziel oder Marginwarnung |
| Emergency close | Positionen nach bestätigtem Ablauf schließen | explizite Notfallentscheidung |
Jeder Übergang muss auditierbar sein: Auslöser, Benutzer, Zeit, betroffene Konten und Börsenantworten. Nach einem Stopp darf der Bot nicht automatisch wieder starten, bevor Positionsabgleich und Ursache geklärt sind.
API-Schlüssel nach dem Prinzip der kleinsten Berechtigung
Binance weist darauf hin, dass API-Key und Secret sensibel sind und Schlüssel unterschiedliche Berechtigungen erhalten können. Für einen Trading-Bot sind Auszahlungen regelmäßig nicht erforderlich. Handels- und reine Leserechte sollten getrennt werden, sofern Börse und Architektur dies unterstützen.
- keine Secrets in Logs, Webhooks, Browser oder Quellcode;
- Auszahlungsrecht deaktivieren;
- IP-Allowlist verwenden, wenn verfügbar;
- Schlüssel pro Umgebung und Konto trennen;
- Rotation und sofortigen Widerruf vorbereiten;
- ungewöhnliche Order- und Login-Aktivität alarmieren;
- Testnet und Produktion strikt trennen;
- Secrets verschlüsselt und zugriffsbeschränkt speichern.
Testen heißt mehr als profitable Backtests
TradingView dokumentiert Lookahead Bias, Selection Bias und Overfitting als typische Strategierisiken. Hinzu kommen im Live-Betrieb Gebühren, Slippage, Latenz und abweichende Fills. Ein belastbarer Freigabeprozess umfasst Unit-Tests, Replay historischer Signale, Paper Trading, Testnet und einen kleinen kontrollierten Live-Rollout.
Fehlerszenarien müssen absichtlich getestet werden: doppeltes Signal, Timeout nach Orderannahme, Teilausführung, Rate Limit, abgelaufener Schlüssel, falsche Symbolpräzision, Börsenwartung und Neustart bei offener Position. Die CFTC warnt zudem vor garantierten Bot- oder KI-Renditen. Ein Risk-System darf deshalb keine Gewinnwahrscheinlichkeit vortäuschen.
Risikokontrolle und Steuerreport teilen dieselben Ausführungsdaten
Für den Steuerreport zählen tatsächliche Fills, Gebühren, Funding und realisierte Close-P&L — nicht bloße Signale oder Backtest-Orders. Der Bot sollte die Rohantwort der Börse, Client-Order-ID, Exchange-Order-ID, Fill-ID und Zeitstempel unverändert sichern. Der Leitfaden Trading-Bot mit Steuerreport zeigt die Datenkette.
Ein offener Long, ein Snapshot oder eine gesendete, aber nicht ausgeführte Order ist noch kein realisierter Close-P&L. Werden technische Zeilen als Steuerereignisse gezählt, entstehen Doppelungen. Umgekehrt fehlen Ergebnisse, wenn Teilausführungen oder separate Funding-Ereignisse ignoriert werden. Der TradingView-Webhook-Guide erklärt die vorgelagerte Signalstrecke.
Häufige Fragen
Braucht jede Strategie einen Stop-Loss?
Nicht zwingend dieselbe Orderart, aber jede Strategie braucht ein festgelegtes maximales Risiko und einen eindeutig ausführbaren Ausstieg.
Ist ein niedriger Hebel sicher?
Nein. Er reduziert einen Risikofaktor, beseitigt aber Volatilität, Liquidität, Ausführungs- und Plattformrisiko nicht.
Soll der Kill Switch alle Positionen sofort schließen?
Nicht automatisch. Pause, Storno, Reduce-only und Emergency Close müssen als unterschiedliche Zustände definiert sein.
Darf ein Timeout einfach erneut gesendet werden?
Nein. Zuerst muss anhand einer eindeutigen Order-ID geprüft werden, ob die Börse die erste Order angenommen hat.
Garantiert ein Risk Guard einen begrenzten Verlust?
Nein. Gaps, Slippage, Liquidation, technische Ausfälle und Plattformereignisse können geplante Grenzen überschreiten.
Primärquellen
- CFTC: Risiken von Krypto-Spot-, Futures- und Optionshandel
- CFTC: AI und Trading-Bots sind keine Geldmaschinen
- Binance Developer Docs: API-Sicherheit und Berechtigungen
- Binance: Margin-Level, Hebel und Liquidationsrisiko
Technischer Quellenstand: 9. Oktober 2026. Keine Strategie oder technische Kontrolle garantiert Gewinne oder die Einhaltung eines maximalen Verlusts.