Kill-Switch für Trading-Bots Notaus auch für KI-Agenten.
Ein Kill-Switch ist der Notaus eines automatisierten Handelssystems: Er sperrt neue Orders, storniert offene Orders und bringt das System in einen sicheren, definierten Zustand, ohne dass der Bot selbst dabei mitspielen muss. Ein Stop-Loss schützt eine einzelne Position, ein Kill-Switch schützt das ganze Konto vor einem System, das außer Kontrolle geraten ist. Für Wertpapierfirmen mit algorithmischem Handel ist diese Funktion seit MiFID II Pflicht, für private Systeme ist sie gute Praxis. Weil KI-Agenten inzwischen über offizielle Schnittstellen einzelner Börsen und Handelsplattformen Orders auslösen können, wird das Thema dringlicher. Dieser Artikel zeigt die vier Ebenen eines Notaus, sinnvolle Auslöser, Tests und eine Minimalausstattung. Stand Oktober 2026; Funktionen von Brokern und Plattformen ändern sich schnell, prüfen Sie deshalb die aktuelle Dokumentation Ihres Anbieters.
Hinweis: Dieser Beitrag gibt den Rechts- und Steuerstand zum unten angegebenen Datum allgemein wieder. Er ist keine Rechts- oder Steuerberatung und ersetzt nicht die Prüfung Ihres Einzelfalls durch eine Rechtsanwältin, einen Rechtsanwalt, eine Steuerberaterin oder einen Steuerberater. Alle Angaben ohne Gewähr für Vollständigkeit und Aktualität.
Was ist ein Kill-Switch und warum reicht ein Stop-Loss nicht?
Ein Stop-Loss ist eine Order, die eine einzelne Position bei einem bestimmten Kurs schließt. Er setzt voraus, dass das System grundsätzlich richtig arbeitet. Genau diese Annahme fällt bei den gefährlichen Fehlern weg: eine Schleife, die dieselbe Order hundertfach sendet, ein falsch skaliertes Volumen, ein eingefrorener Kursstrom, auf dessen Basis der Bot weiter handelt, oder ein KI-Agent, der eine Anweisung falsch versteht. In solchen Fällen ist nicht eine Position das Problem, sondern das System selbst.
Ein Kill-Switch setzt deshalb eine Ebene höher an. Er beantwortet die Frage: Wie stoppe ich alles, schnell, vollständig und auch dann, wenn der Bot nicht mehr reagiert? Dazu braucht es drei Eigenschaften:
- Unabhängigkeit: Der Notaus darf nicht davon abhängen, dass der fehlerhafte Code kooperiert.
- Vollständigkeit: Er erfasst alle Strategien, Konten und Instrumente, die das System bedient.
- Definierter Endzustand: Nach dem Auslösen ist klar, welche Orders weg sind, welche Positionen offen bleiben und wer das System wieder freigibt.
Stop-Loss und Position-Sizing bleiben wichtig, sie sind die erste Verteidigungslinie im Normalbetrieb. Wie Sie Positionsgrößen systematisch festlegen, beschreibt der Artikel zu Risk-Management und Position-Sizing. Der Kill-Switch ist die letzte Linie für den Fall, dass genau diese Regeln nicht mehr greifen.
Was verlangt die Aufsicht von professionellen Algo-Händlern?
Ein gutes Vorbild für private Systeme liefert die Regulierung, die für Wertpapierfirmen gilt. Die Delegierte Verordnung (EU) 2017/589, oft kurz RTS 6 genannt, konkretisiert die organisatorischen Anforderungen an algorithmischen Handel nach MiFID II. Drei Artikel sind für das Thema zentral:
- Art. 12, Kill-Funktion: Die Firma muss als Notfallmaßnahme alle oder einzelne nicht ausgeführten Orders sofort stornieren können. Außerdem muss sie jede Order einem Algorithmus, Händler, Handelstisch oder Kunden zuordnen können.
- Art. 15, Pre-Trade-Kontrollen: Vor dem Absenden prüft das System automatisch Preisbänder, maximalen Orderwert, maximales Ordervolumen und eine Höchstzahl von Nachrichten.
- Art. 16, Echtzeitüberwachung: Algorithmische Handelsaktivität wird in Echtzeit überwacht; Echtzeit-Warnmeldungen müssen innerhalb von fünf Sekunden nach dem relevanten Ereignis erzeugt werden.
Am 26.02.2026 hat die ESMA ein Supervisory Briefing zum algorithmischen Handel veröffentlicht, ein nicht bindendes Instrument, mit dem die nationalen Aufsichtsbehörden ihre Praxis angleichen. Laut der Zusammenfassung der Kanzlei CMS nennt es als Pre-Trade-Kontrollen Preisbänder, maximale Orderwerte und -volumen, Nachrichtenlimits und Bremsen für wiederholte automatisierte Ausführung. Bei ausgelagerten Systemen sollen Firmen den algorithmischen Handel zudem jederzeit selbst überwachen, aussetzen oder beenden können, ohne auf die Zustimmung des Dienstleisters angewiesen zu sein. Laut Macfarlanes stellt das Briefing klar, dass algorithmischer Handel schon vorliegt, wenn ein Algorithmus einzelne Orderparameter bestimmt, auch wenn ein Mensch beteiligt ist, und dass die nationalen Aufsichtsbehörden prüfen sollen, wie Firmen ihren KI-Einsatz in der jährlichen Selbstbewertung nach RTS 6 berücksichtigen.
Wichtig zur Einordnung: Diese Pflichten gelten für Wertpapierfirmen, nicht für Privatanleger, die einen eigenen Bot auf ihrem Konto betreiben. Die Logik dahinter lässt sich aber gut übertragen. Wenn Aufsichtsbehörden nach Jahren der Erfahrung mit Fehlfunktionen bei Profis auf Stornierung, Vorabkontrollen und schnelle Alarme bestehen, ist das ein guter Maßstab auch für ein kleines System.
Welche Ebenen hat ein Kill-Switch?
Ein Kill-Switch ist kein einzelner Knopf, sondern eine Abfolge von Eingriffen, die unterschiedlich weit gehen. Es hilft, sie getrennt zu planen und getrennt auslösen zu können.
| Ebene | Was passiert | Typische Umsetzung | Worauf achten |
|---|---|---|---|
| 1. Sperren | Keine neuen Orders, KI-Agent verliert Order-Rechte | Sperr-Flag, das jede Order-Funktion prüft; Agent-Tools für Handel deaktivieren; in MetaTrader 5 den automatisierten Handel für Expert Advisors in der Plattform abschalten (der EA läuft weiter, darf aber nicht mehr handeln) | Sperre muss persistent sein und einen Neustart überleben |
| 2. Stornieren | Alle offenen, nicht ausgeführten Orders löschen | Stornierungsbefehl der Broker-API für alle Orders des Kontos oder der Strategie | Je nach Broker sind Stop-Orders eigene Orders; wer sie mit storniert, lässt Positionen ungeschützt |
| 3. Glätten | Offene Positionen schließen oder absichern | Gegenorders nach vorher festgelegter Regel | In dünnen Märkten oder bei Kurslücken kann sofortiges Schließen teurer sein als Halten |
| 4. Zugang kappen | Das System kann den Broker nicht mehr erreichen | API-Schlüssel beim Broker widerrufen, Sitzungen beenden | Danach geht auch kein automatisches Aufräumen mehr; Ebene 2 vorher erledigen |
Die Reihenfolge ist kein Zufall. Ebene 1 kommt zuerst, damit der Bot nicht neue Orders nachschiebt, während Sie die alten stornieren. Ebene 2 entspricht dem, was RTS 6 als Kill-Funktion beschreibt. Ebene 3 ist eine Handelsentscheidung und sollte nicht reflexhaft passieren, sondern nach einer Regel, die Sie vorab festgelegt haben, etwa: Positionen bleiben mit Schutz-Stop offen, außer der Auslöser war ein Datenfehler, bei dem Sie den Bestand nicht mehr sicher kennen. Ebene 4 ist der letzte Schritt, wenn Sie dem System insgesamt nicht mehr trauen, etwa bei Verdacht auf einen kompromittierten Server.
Welche Auslöser sollten den Kill-Switch ziehen?
Ein Notaus, den nur ein Mensch auslösen kann, kommt oft zu spät. Deshalb braucht es automatische Auslöser. Bewährt haben sich vier Kategorien, die sich gut messen lassen:
- Drawdown: Der Verlust gegenüber dem Kontostand zu Tagesbeginn oder gegenüber dem letzten Höchststand überschreitet eine Grenze. Diese Grenze leiten Sie aus Ihrem Risikobudget ab, nicht aus dem Bauch.
- Order-Rate: Mehr Orders, Änderungen oder Stornierungen pro Zeiteinheit, als die Strategie plausibel erzeugen kann. Sie ist ein sehr direkter Hinweis auf Schleifen und auf Agenten, die sich in einer Wiederholung verfangen.
- Datenausfall: Der Kursstrom liefert keine neuen Ticks, Zeitstempel springen, oder Kurse weichen stark von einer zweiten Quelle ab. Ein Bot, der auf eingefrorenen Kursen weiterhandelt, handelt blind.
- Heartbeat: Der Bot meldet in festen Abständen ein Lebenszeichen an einen Wächter. Bleibt es aus, gilt der Bot als hängend oder abgestürzt.
Dazu kommen Plausibilitätsprüfungen, die RTS 6 als Pre-Trade-Kontrollen beschreibt: maximales Volumen pro Order, maximaler Orderwert, ein Preisband um den letzten Kurs und eine Positionsobergrenze je Instrument. Sie verhindern einzelne Fehlorders, bevor der Kill-Switch überhaupt gebraucht wird.
Technisch gehört die Prüfung in einen eigenen Prozess, idealerweise auf einer anderen Maschine als der Bot. Das folgende Gerüst zeigt das Prinzip; die Grenzwerte sind ein Rechenbeispiel, keine Empfehlung:
# Rechenbeispiel: Wächter-Prozess, getrennt vom eigentlichen Bot
import time
MAX_DAY_LOSS = -0.02 # -2 % gegenüber Equity zum Tagesbeginn
MAX_ORDERS_60S = 20 # mehr Orders pro Minute = Verdacht auf Schleife
MAX_DATA_GAP_S = 30 # so lange darf der Kursstrom schweigen
MAX_HEARTBEAT_S = 10 # so lange darf der Bot schweigen
def check(s, now):
if s.equity / s.equity_day_start - 1 <= MAX_DAY_LOSS:
return "drawdown"
if s.orders_last_60s > MAX_ORDERS_60S:
return "order_rate"
if now - s.last_tick > MAX_DATA_GAP_S:
return "data_gap"
if now - s.last_heartbeat > MAX_HEARTBEAT_S:
return "heartbeat"
return None
reason = check(state, time.time())
if reason:
set_trading_lock(reason) # Ebene 1: keine neuen Orders, Agent-Tools aus
cancel_open_orders() # Ebene 2: offene Orders stornieren
alert(reason) # Mensch informieren, Zustand protokollieren
# Ebene 3 (Positionen glätten) nur nach vorher festgelegter RegelNoch robuster ist ein Dead Man's Switch beim Broker oder der Börse selbst, weil er auch dann greift, wenn Ihr Server komplett ausfällt. Kraken bietet dafür den Endpunkt CancelAllOrdersAfter: Ein Countdown storniert alle Orders des Kontos, wenn er nicht regelmäßig erneuert wird. Kraken empfiehlt, ihn alle 15 bis 30 Sekunden mit einer Laufzeit von 60 Sekunden zu erneuern. Ob Ihr Broker etwas Vergleichbares anbietet, steht in dessen API-Dokumentation.
Was ist bei KI-Agenten mit Order-Rechten anders?
Ein klassischer Bot folgt festen Regeln; seine Fehler sind reproduzierbar. Ein KI-Agent, der über das Model Context Protocol (MCP, ein offener Standard, über den KI-Modelle externe Werkzeuge aufrufen) mit einem Broker verbunden ist, entscheidet dagegen anhand von Sprache, Kontext und Werkzeugbeschreibungen. Die im Dezember 2025 veröffentlichten OWASP Top 10 for Agentic Applications 2026 führen genau die Risiken auf, die hier relevant sind, unter anderem Tool Misuse and Exploitation (Werkzeuge werden für schädliche Zwecke eingesetzt), Identity and Privilege Abuse (Zugangsdaten, Rechte oder Delegationen des Agenten werden missbraucht) und Cascading Failures (ein falsches Signal pflanzt sich durch automatisierte Systeme fort).
Daraus folgt eine klare Regel: Der Notaus für Agenten gehört in die Rechte und die Infrastruktur, nicht in den Prompt. Eine Anweisung wie „Handle nie mehr als 1 Lot“ im Systemprompt ist eine Bitte an das Modell, keine Grenze. Prompt-Guardrails sind sinnvoll, um Fehlverhalten unwahrscheinlicher zu machen; wie man sie aufbaut, steht im Artikel Guardrails für Trading-Agenten. Die harte Grenze muss aber außerhalb des Modells liegen. Einige Anbieter bauen dafür bereits Mechanismen ein:
- Kraken MCP: Standardmäßig laufen nur Marktdaten, Kontoabfragen und Paper-Trading, für Live-Guthaben also nur lesend. Dienste wie trade, futures und funding gelten als gefährlich und verlangen pro Aufruf
acknowledged: true, außer der Server wird mit--allow-dangerousgestartet. Kraken empfiehlt zusätzlich minimal berechtigte API-Schlüssel, Positionslimits und Allowlists für Handelspaare. - MetaTrader 5: Seit Build 6060 vom 23.07.2026 lassen sich KI-initiierte Handelsoperationen ausdrücklich erlauben, verbieten oder an eine manuelle Bestätigung koppeln.
- Freigabe-Modelle: Eine Integration lässt sich so bauen, dass die KI nur Order-Entwürfe erzeugt, die ein Mensch selbst prüft und abschickt. Das ist faktisch ein dauerhaft eingeschalteter Kill-Switch auf Ebene 1.
Für den Notaus heißt das: Ebene 1 bedeutet bei Agenten, die handelnden Werkzeuge zu entziehen, also den MCP-Server ohne Handelsdienste neu zu starten, die Bestätigungsstufe zu verschärfen oder den Schlüssel auf reine Leserechte umzustellen. Wer den Agenten nur per Chat bittet aufzuhören, hat keinen Notaus.
Wie testen Sie einen Kill-Switch, bevor Sie ihn brauchen?
RTS 6 verlangt von Wertpapierfirmen in Art. 5 klar abgegrenzte Methoden, um Systeme vor dem Einsatz zu testen, und laut ESMA-Briefing erneute Tests nach jeder Änderung, die Verhalten oder Risikoprofil verändern kann. Für private Systeme ist das ein guter Maßstab. Ein Kill-Switch hat die unangenehme Eigenschaft, dass er im Normalbetrieb nie gebraucht wird. Fehler in ihm bleiben deshalb unbemerkt, bis es zu spät ist.
Ein sinnvoller Testplan auf einem Demo- oder Paper-Konto:
- Jeden Auslöser einzeln provozieren: Grenzwert für Drawdown künstlich niedrig setzen, eine Order-Schleife simulieren, den Kursstrom trennen, den Bot-Prozess hart beenden.
- Endzustand prüfen: Sind wirklich alle Orders storniert, auch auf allen Konten und Instrumenten? Sind Schutz-Stops noch da, wo sie bleiben sollen?
- Neustart prüfen: Startet der Bot nach einem Absturz wieder, darf er die Sperre nicht einfach überschreiben. Die Freigabe muss bewusst erfolgen.
- Alarmweg prüfen: Kommt die Benachrichtigung tatsächlich an, auch nachts und auf dem Smartphone?
- Manuellen Weg üben: Wissen Sie, wie Sie über die Weboberfläche oder App des Brokers alle Orders stornieren und den API-Schlüssel sperren, falls Ihr Server nicht erreichbar ist?
Wiederholen Sie diese Tests nach jedem Update des Bots, der Broker-Bibliothek oder des KI-Modells. Gerade bei Agenten kann ein Modellwechsel das Verhalten ändern, ohne dass sich eine Zeile Ihres Codes geändert hat.
Wo liegen die Grenzen eines Kill-Switches?
Ein Notaus verhindert nicht jeden Schaden. Er begrenzt ihn. Einige Grenzen sollten Sie kennen:
- Teilausführungen: Zwischen Auslösen und Stornierung können Orders noch ganz oder teilweise ausgeführt werden. Die Stornierung wirkt nur auf das, was noch nicht ausgeführt ist.
- Fehlauslösungen: Zu enge Grenzen stoppen das System bei normalen Schwankungen oder kurzen Datenlücken. Das kostet Gelegenheiten und verleitet dazu, die Grenzen später zu großzügig zu setzen.
- Glätten kann teuer sein: Positionen in einem hektischen oder illiquiden Markt per Marktorder zu schließen, kann zu erheblichem Schlupf führen. Deshalb gehört Ebene 3 in eine vorab definierte Regel.
- Gemeinsame Fehlerquelle: Läuft der Wächter auf demselben Server, im selben Prozess oder über dieselbe Verbindung wie der Bot, fällt er im schlimmsten Fall gemeinsam mit ihm aus.
- Abhängigkeit vom Broker: Wenn die Broker-API selbst gestört ist, helfen auch Ihre Stornierungsbefehle nicht. Dann bleibt nur der manuelle Weg über Weboberfläche, App oder Telefon.
Und schließlich: Ein Kill-Switch macht aus einer schlechten Strategie keine gute. Er schützt vor technischen Ausfällen und Kontrollverlust, nicht vor Marktrisiko. Automatisierter Handel mit Hebel kann bis zum Totalverlust des eingesetzten Kapitals führen, auch wenn alle Schutzmechanismen funktionieren.
Minimalausstattung für private Systeme: was Sie jetzt tun können.
Auch ein kleines System sollte eine Grundausstattung haben. Diese Liste ist ein pragmatischer Startpunkt:
- Ein zentrales Sperr-Flag, das jede Order-Funktion vor dem Senden prüft und das einen Neustart überlebt.
- Pre-Trade-Kontrollen für maximales Volumen, maximalen Orderwert, Preisband und Positionsobergrenze je Instrument.
- Vier automatische Auslöser: Tagesverlust, Order-Rate, Datenausfall, Heartbeat.
- Ein getrennter Wächter, wenn möglich auf einer anderen Maschine, plus ein Dead Man's Switch beim Broker, wo verfügbar.
- Minimal berechtigte API-Schlüssel: keine Auszahlungsrechte, für KI-Agenten zunächst nur Leserechte oder Freigabe pro Order.
- Ein dokumentierter manueller Notfallweg, den Sie mindestens einmal geübt haben.
- Ein Protokoll, das jede Order ihrer Strategie oder ihrem Agenten zuordnet, so wie es Art. 12 RTS 6 für Profis verlangt. Ohne diese Zuordnung wissen Sie im Ernstfall nicht, was Sie stoppen müssen.
Wenn ich Trading-Systeme entwickle, plane ich den Notaus zusammen mit der Order-Logik und nicht als Nachtrag. Er ist Teil der Architektur, so wie Logging und Monitoring. Wenn Sie dabei Unterstützung beim Aufbau oder beim Testen wollen, finden Sie mehr dazu auf der Seite zur Trading-Automatisierung.
Häufige Fragen.
Was ist ein Kill-Switch bei einem Trading-Bot?
Ein Kill-Switch ist ein Notaus für automatisierte Handelssysteme. Er sperrt neue Orders, storniert offene Orders und bringt das System in einen definierten, sicheren Zustand. Anders als ein Stop-Loss schützt er nicht eine einzelne Position, sondern das ganze Konto vor einem fehlerhaften System, etwa bei Order-Schleifen, Datenausfällen oder einem KI-Agenten, der Anweisungen falsch umsetzt.
Müssen Privatanleger einen Kill-Switch nach MiFID II haben?
Nein. Die Kill-Funktion nach Art. 12 der Delegierten Verordnung (EU) 2017/589 (RTS 6) und die Pre-Trade-Kontrollen nach Art. 15 gelten für Wertpapierfirmen mit algorithmischem Handel. Für private Systeme sind sie keine Pflicht, aber ein sinnvolles Vorbild, weil sie genau die Fehlerfälle adressieren, die auch kleine Bots treffen können. Für Ihre konkrete rechtliche Einordnung ist ein Anwalt zuständig.
Reicht es, einem KI-Agenten im Prompt das Handeln zu verbieten?
Nein. Eine Anweisung im Prompt beeinflusst das Verhalten des Modells, setzt aber keine technische Grenze. Ein wirksamer Notaus entzieht dem Agenten die Werkzeuge oder Rechte: Handelsdienste im MCP-Server abschalten, eine Bestätigung pro Order verlangen oder den API-Schlüssel auf Leserechte umstellen. Prompt-Guardrails sind eine sinnvolle Ergänzung, ersetzen die harte Sperre aber nicht.
Was ist ein Dead Man's Switch beim Trading?
Ein Dead Man's Switch ist ein Zeitgeber, den Ihr System regelmäßig erneuern muss. Bleibt die Erneuerung aus, etwa weil der Server abgestürzt ist, storniert der Broker oder die Börse automatisch alle offenen Orders. Kraken bietet dafür den Endpunkt CancelAllOrdersAfter und empfiehlt eine Erneuerung alle 15 bis 30 Sekunden mit 60 Sekunden Laufzeit. Ob Ihr Broker so etwas anbietet, steht in seiner API-Dokumentation.
Sollte ein Kill-Switch auch alle Positionen schließen?
Nicht automatisch. Das Stornieren offener Orders ist fast immer richtig, das Schließen von Positionen dagegen eine Handelsentscheidung. In hektischen oder illiquiden Märkten kann sofortiges Schließen per Marktorder teurer sein als das Halten mit Schutz-Stop. Legen Sie vorab eine Regel fest, wann Positionen geglättet werden, etwa wenn der Bestand wegen eines Datenfehlers nicht mehr sicher bekannt ist.
Quellen und Stand.
- Delegierte Verordnung (EU) 2017/589 (RTS 6), Art. 5, 12, 15, 16 — EUR-Lex
- ESMA issues Supervisory Briefing on algorithmic trading — ESMA (26.02.2026)
- ESMA supervisory briefing on algorithmic trading in the EU: key points and practical implications — CMS
- Algorithmic trading and artificial intelligence: ESMA supervisory briefing — Macfarlanes
- Kraken MCP Server — Kraken Docs
- Cancel All Orders After X (Dead Man's Switch) — Kraken API Docs
- MetaTrader 5 Build 6060: MCP und AI Assistant — MetaQuotes (Release Notes, 23.07.2026)
- Algo Trading: Expert Advisors in der Plattform deaktivieren — MetaQuotes (MetaTrader 5 Hilfe)
- OWASP Top 10 for Agentic Applications for 2026 — OWASP GenAI Security Project
Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.
Sie wollen Ihren Trading-Bot oder KI-Agenten mit einem belastbaren Notaus absichern? Unverbindlich anfragen — wir klären Auslöser, Sperrlogik, Tests und den Weg in den kontrollierten Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.