Trading-Bot selbst programmieren: Architektur, Bausteine und die Reihenfolge für Einsteiger

Einen Trading-Bot programmiert man nicht als ein Programm, sondern als eine Kette von Bausteinen: Marktdaten-Anbindung, Datenhaltung, Strategie-Modul, Risk-Layer, Order-Ausführung, Zustandsverwaltung, Logging und Kill-Switch. Angefangen wird nicht bei der Strategie und nicht bei der Order, sondern bei den Daten. Erst wenn historische Kurse sauber gespeichert sind und ein Backtest auf ihnen läuft, entsteht das Strategie-Modul; erst wenn das im Dry-Run wochenlang stabil ist, folgt der Live-Betrieb mit einem Betrag, dessen Verlust nicht wehtut. Diese Reihenfolge ist kein Ratschlag, sondern die Bauweise, die die meisten teuren Fehler verhindert.

Die acht Bausteine und was jeder tut

Jeder Baustein hat eine klar abgegrenzte Aufgabe und eine definierte Schnittstelle zum nächsten. Wer die Grenzen sauber zieht, kann jeden Teil einzeln testen und einzeln ersetzen.

• Marktdaten-Anbindung: Holt Kurse, Kerzen und Orderbuchdaten von der Börse, per REST für Abfragen und per WebSocket für den Live-Strom. Sie normalisiert Formate, Zeitstempel und Symbolnamen, damit der Rest des Systems nie mit Rohdaten arbeitet.
• Datenhaltung: Speichert Historie und Live-Daten in einer eigenen Datenbank. Ohne sie ist jeder Backtest von der Laune des Anbieters abhängig und jeder Neustart ein Datenverlust.
• Signal- und Strategie-Modul: Rechnet aus den Daten Indikatoren und leitet daraus Signale ab. Es entscheidet nur, ob ein Setup vorliegt, nicht, wie viel gehandelt wird.
• Risk-Layer: Bestimmt Positionsgröße, Stop-Abstand, maximales Tagesrisiko und offene Gesamtexposition. Er hat das Recht, jedes Signal abzulehnen.
• Order-Ausführung: Übersetzt eine freigegebene Entscheidung in Börsenorders, verfolgt Fills und Teilausführungen und meldet den Status zurück.
• Zustand und Persistenz: Hält fest, welche Positionen offen sind, welche Orders laufen und welche Parameter gelten, so dass ein Neustart den Bot nicht in Unwissenheit versetzt.
• Logging und Monitoring: Schreibt jede Entscheidung mit Eingangsdaten und Ergebnis mit und meldet Abweichungen nach außen.
• Kill-Switch: Stoppt den Bot sofort und zuverlässig, unabhängig davon, in welchem Zustand die anderen Bausteine gerade sind.

Die häufigste Fehlkonstruktion bei Einsteigern ist ein einziges Skript, das alles gleichzeitig tut. Es funktioniert am ersten Tag und ist ab dem zweiten nicht mehr testbar. Was der Risk-Layer im Einzelnen entscheidet, steht in Risk-Layer erklärt.

Warum die Reihenfolge des Bauens entscheidet

Der Reiz liegt in der Strategie, also fangen die meisten dort an. Das Ergebnis ist ein Modul, das auf Daten rechnet, deren Qualität niemand geprüft hat, und das gegen eine Börse handelt, deren Fehlermeldungen niemand kennt. Die tragfähige Reihenfolge dreht das um.

1. Daten zuerst: Anbindung bauen, Historie laden, in die eigene Datenbank schreiben, Lücken und Duplikate prüfen. Erst wenn ein längerer Zeitraum Kerzen sauber und lückenlos vorliegt, geht es weiter.
2. Backtest-Rahmen: Eine Schleife, die die Historie Kerze für Kerze abspielt und dem Strategie-Modul zu jedem Zeitpunkt nur die Daten gibt, die es damals hätte haben können. Gebühren, Spread und Slippage werden von Anfang an als Kosten abgezogen.
3. Strategie und Risk-Layer: Jetzt erst die Regeln. Was im Backtest nach Kosten keinen positiven Erwartungswert zeigt, geht nicht weiter, egal wie die Kurve aussieht.
4. Dry-Run: Der Bot läuft gegen den Live-Datenstrom, rechnet Signale und schreibt Orders nur ins Log. Hier zeigen sich Zeitzonen, Rate Limits, Verbindungsabbrüche und alles, was der Backtest nicht kennt.
5. Winzig live: Der kleinste handelbare Betrag, über Wochen. Nicht um Geld zu verdienen, sondern um Fills, Rejects und Teilausführungen unter echten Bedingungen zu sehen.

Jede Stufe hat ein Ausstiegskriterium, das vorher festgelegt wird. Warum der Betrieb ohne Geld keine Formsache ist, steht in DRY-RUN, und was ein Backtest leisten kann und was nicht, in Backtesting verstehen.

Sprache, Stack und Testumgebung

Python ist der übliche Einstieg: Die Bibliotheken für Datenverarbeitung, Zeitreihen und HTTP sind ausgereift, und fast jede Börse bietet eine dokumentierte API mit Beispielen dafür. Geschwindigkeit ist auf Kerzenbasis kein Argument dagegen; wer im Sekundentakt oder darunter handeln will, hat ein anderes Problem als die Sprache. Für die Datenhaltung reicht anfangs eine lokale SQL-Datenbank, für die Ausführung eine Bibliothek, die die API-Aufrufe kapselt und Signaturen, Zeitstempel und Fehlercodes einheitlich behandelt.

Entscheidend ist die Testumgebung. Die meisten Börsen stellen ein Testnet oder eine Sandbox bereit, in der Orders ohne echtes Geld angenommen werden. Sie verhält sich nie exakt wie der Live-Markt, aber sie zeigt, ob Authentifizierung, Orderformat und Statusabfragen stimmen. Ein Bot, der dort nicht sauber läuft, hat live nichts verloren. Zugangsdaten gehören dabei von Anfang an in eine Konfiguration außerhalb des Codes und mit den geringsten nötigen Rechten, wie in API-Keys absichern beschrieben.

Fehlerklassen, die jeder Selbstbauer trifft

Die Fehler unterscheiden sich kaum zwischen Einsteigern und Erfahrenen; der Unterschied ist, ob sie im Dry-Run oder im Depot auffallen.

• Look-Ahead: Die Strategie sieht im Backtest Daten, die zum Entscheidungszeitpunkt noch nicht vorlagen, etwa den Schlusskurs der laufenden Kerze. Die Kurve sieht großartig aus und ist wertlos. Details in Backtest-Bias.
• Doppelte Orders: Ein Timeout nach dem Senden, der Bot wiederholt, die Börse hatte die erste Order längst angenommen. Ohne eindeutige Client-Order-IDs ist das nur eine Frage der Zeit; die Lösung heißt idempotente Orders.
• Fehlende Idempotenz im Zustand: Nach einem Neustart weiß der Bot nicht, ob die offene Position ihm gehört, und eröffnet eine zweite. Der Zustand muss beim Start gegen die Börse abgeglichen werden, nicht aus dem Gedächtnis übernommen.
• Zeitzonen: Kerzen in UTC, Logs in Lokalzeit, Börsentag nach Serverzeit. Jede Mischung erzeugt Signale, die um Stunden verschoben sind, und Backtests, die sich nicht reproduzieren lassen.
• Rate Limits: Eine Schleife, die zu oft abfragt, wird gedrosselt oder gesperrt, meist genau dann, wenn der Markt sich bewegt und die Abfragen wichtig wären.
• Stille Fehler: Eine Ausnahme wird gefangen und ignoriert, der Bot läuft weiter und handelt auf veralteten Daten. Jeder gefangene Fehler muss geloggt und gezählt werden.

Betrieb: Logging, Monitoring und Notaus

Ein Bot ohne Beobachtung ist kein automatisiertes System, sondern ein unbeaufsichtigtes. Das Logging schreibt jede Entscheidung mit ihren Eingangsdaten, so dass sich im Nachhinein rekonstruieren lässt, warum eine Order gesendet oder abgelehnt wurde. Das Monitoring prüft von außen, ob der Bot lebt, ob Daten frisch sind und ob die Ergebnisse zum erwarteten Verhalten passen; ein Prozess, der läuft, aber seit einer Stunde keine Kerze mehr bekommen hat, ist der gefährlichste Zustand von allen. Was dafür mindestens nötig ist, steht in Logging und Monitoring.

Der Kill-Switch ist der Baustein, der als Erstes gebaut und als Letztes vertraut werden sollte. Er muss unabhängig vom restlichen Code funktionieren, offene Orders stornieren und auf Wunsch Positionen glattstellen, und er muss getestet sein, bevor er gebraucht wird. Ein Notaus, der eine Flagge setzt, die niemand liest, ist keiner. Auslöser und Aufbau sind in Kill-Switch beschrieben.

Was ein Bot nicht löst

Ein Bot führt Regeln aus. Er findet keine, und er macht schlechte nicht besser. Er beseitigt Emotionen aus der Ausführung, verschiebt sie aber auf die Ebene darüber: Wer den Bot in einer Verlustphase abschaltet und in einer Gewinnphase hochdreht, handelt wieder aus dem Bauch, nur mit mehr Aufwand. Er schützt nicht vor Marktphasen, für die die Strategie nicht gebaut ist, nicht vor Börsenausfällen und nicht vor der Insolvenz des Verwahrers. Und er erzeugt keine Rendite, sondern setzt um, was die Regeln hergeben, im Guten wie im Schlechten, bis hin zum Totalverlust des eingesetzten Kapitals.

Wo Selbstbauen nicht sinnvoll ist

Es gibt drei Konstellationen, in denen der Aufwand nichts bringt, und sie sind vor der ersten Codezeile erkennbar.

• Keine Strategie mit Erwartungswert: Wer noch keine Regel hat, die im Backtest nach Kosten und über mehrere Marktphasen positiv bleibt, baut ein System ohne Zweck. Die Architektur wartet, bis die Regel existiert.
• Keine Zeit für den Betrieb: Ein Bot braucht tägliche Kontrolle, Reaktion auf API-Änderungen, Updates und gelegentliche Neustarts. Wer das nicht leisten kann, hat kein automatisiertes System, sondern ein unbeaufsichtigtes Risiko.
• Latenzstrategien: Arbitrage, Market-Making und alles, was auf Millisekunden beruht, konkurriert mit Teilnehmern, die Colocation und eigene Infrastruktur haben. Ein selbst gebauter Bot auf einem Heimrechner ist dort strukturell unterlegen.

In allen anderen Fällen ist Selbstbauen der einzige Weg, ein System wirklich zu verstehen, und dieses Verständnis ist am Ende der Teil, der den Betrieb überlebt.