Wenn ein Trading-Bot unerwartet handelt, solltest du zuerst jede neue Ausführung sperren und zugleich sämtliche Protokolle unverändert sichern. So begrenzt du weiteres Risiko, ohne genau die Daten zu zerstören, die später zeigen können, was passiert ist.
Um 6:12 Uhr sitzt Martin, ein erfahrener Privatanleger aus Köln, mit einer kalten Kaffeetasse vor seinem Laptop. Auf dem Bildschirm steht eine offene Aktienposition, die dort nicht stehen sollte. Sein Bot hatte sie während der Nacht eröffnet, obwohl Martin glaubte, die betreffende Strategie pausiert zu haben.
Noch ist unklar, ob nur ein Auftrag falsch ausgelöst wurde oder weitere in der Warteschlange liegen. Wenn Martin jetzt hektisch Einstellungen ändert, Prozesse neu startet oder Protokolle löscht, könnte er die Ursache unauffindbar machen. Lässt er alles weiterlaufen, könnte der nächste Auftrag das Kontorisiko erneut erhöhen.
Zuerst die Ausführung stoppen
Martins erster sinnvoller Schritt ist eine Trennung: Neue Aufträge dürfen nicht mehr ausgeführt werden, vorhandene Daten müssen erhalten bleiben. Dazu deaktiviert er die Ausführungsberechtigung des Bots und prüft anschließend getrennt, wie er mit der bereits offenen Position umgeht.
Diese Reihenfolge zählt. Wer zuerst nach dem Fehler sucht, während der Bot weiter handeln darf, untersucht ein System, das den Schaden gleichzeitig vergrößern kann. Wer dagegen sofort alles zurücksetzt, verliert möglicherweise Zeitstempel, Signalparameter, Statusänderungen und Fehlermeldungen.
Das Ziel der ersten Minuten lautet deshalb weder Ursachenanalyse noch Rückkehr zum Normalbetrieb. Es lautet Schadensbegrenzung:
- Neue Ausführungen sperren.
- Offene Orders und Positionen separat prüfen.
- Logs, Konfigurationen und Signalverläufe sichern.
- Den Zeitpunkt der Entdeckung festhalten.
- Erst danach nach der Ursache suchen.
Falls der Bot direkt mit einem Broker oder einer Börse verbunden ist, muss die Sperre dort überprüfbar sein. Ein ausgeschaltetes Dashboard reicht nicht als Beleg dafür, dass keine Aufträge mehr übertragen werden können.
Protokolle sind Beweise, keine Aufräumreste
Ein Log ist nur dann nützlich, wenn es den Zustand während des Vorfalls abbildet. Nachträgliche Änderungen können genau jene Spur überschreiben, die zwischen einem fehlerhaften Signal, einer falschen Konfiguration und einer unerwarteten Ausführung unterscheidet.
Martin legt deshalb eine unveränderte Kopie der verfügbaren Aufzeichnungen an. Er notiert, wann er den Vorfall entdeckt und wann er die Ausführung gesperrt hat. Screenshots können den sichtbaren Zustand ergänzen, ersetzen aber keine exportierbaren Protokolle mit Zeitstempeln.
Für die spätere Prüfung braucht er konkrete Antworten:
- Welches Signal wurde erzeugt?
- Welche Daten und Regeln lagen diesem Signal zugrunde?
- Wann wurde daraus ein Auftrag?
- Welche Freigabe oder Berechtigung erlaubte die Ausführung?
- Welche Einstellungen waren zu diesem Zeitpunkt aktiv?
- Gab es weitere Signale, Aufträge oder Wiederholungsversuche?
- Stimmen die Zeitangaben in Bot, Brokerkonto und Export überein?
Fehlt diese Kette, bleibt nur eine Vermutung. Das ist besonders gefährlich, wenn der offensichtliche Fehler gar nicht die eigentliche Ursache war. Eine scheinbar pausierte Strategie kann beispielsweise weiterhin eine bestehende Warteschlange abarbeiten. Ob das in einem konkreten System möglich ist, muss aus dessen tatsächlichen Aufzeichnungen hervorgehen.
Die gleiche Gefahr zeigt sich, wenn ein Bot eine Risikoregel nie ausdrücklich erhalten hat. Der Beitrag Was passiert, wenn dein Trading-Bot eine unausgesprochene Risikoregel nicht kennt? behandelt genau diese Lücke zwischen menschlicher Annahme und maschinell hinterlegter Regel.
Kontrolle braucht eine Freigabe vor der Order
Am selben Morgen erkennt Martin den entscheidenden Konstruktionsfehler: Sein System konnte ein Signal erzeugen und selbst zur Ausführung bringen. Zwischen Einschätzung und realer Order gab es keinen verbindlichen menschlichen Prüfpunkt.
Ein Approval Gate trennt diese Schritte. Die KI kann ein Signal mit Begründung und Risikodaten erzeugen und in eine Warteschlange legen. Die Ausführung beginnt erst, wenn ein Mensch den konkreten Auftrag genehmigt. Ohne Freigabe bleibt das Signal ein Vorschlag.
Für Martin hätte das bedeutet, dass er vor der Order mindestens Richtung, Positionsgröße, vorgesehenen Einstieg, Risikogrenze und Zusammenhang mit bestehenden Positionen hätte prüfen können. Er hätte das Signal auch ablehnen können, obwohl es formal zu den hinterlegten Regeln passte. Warum eine solche Ablehnung sinnvoll sein kann, zeigt KI Trading Freigabe: Warum Jonas einen regelkonformen Auftrag ablehnte.
Eine Freigabe verhindert keine Verluste und macht ein Signal nicht richtig. Sie verschiebt die letzte Entscheidung dorthin, wo sie hingehört: zu der Person, deren Kapital betroffen ist.
Neustart erst nach einer prüfbaren Erklärung
Um 8:03 Uhr ist Martins Bot weiterhin gesperrt. Die offene Position ist geklärt, die Logs liegen unverändert vor, und der fragliche Auftrag lässt sich zeitlich vom Signal bis zur Ausführung verfolgen. Der schlechte Ausgang, weitere unbemerkte Orders und eine verwischte Ursache, ist damit zunächst abgewendet.
Jetzt beginnt die eigentliche Arbeit. Martin braucht eine nachvollziehbare Erklärung, eine korrigierte Regel und einen begrenzten Test ohne unbeaufsichtigte Ausführung. Ein Neustart allein beweist nichts. Auch ein einmalig fehlerfreier Test zeigt noch nicht, dass die Ursache behoben wurde.
Vor einer erneuten Freigabe sollte feststehen:
- welche konkrete Bedingung den Auftrag ausgelöst hat,
- warum die erwartete Sperre nicht wirkte,
- welche Änderung denselben Ablauf künftig verhindert,
- wie diese Änderung getestet wurde,
- und ob jede neue Order wieder eine ausdrückliche Genehmigung verlangt.
Der ruhige Bildschirm nach dem Abschalten ist noch keine Lösung. Er schafft den Zustand, in dem eine Lösung überhaupt möglich wird: kein neues Risiko aus derselben Quelle, erhaltene Beweise und eine klare Entscheidung darüber, ob das System wieder handeln darf.
Educational content, keine Finanzberatung.
Kommentare
Noch keine Kommentare.