Dieser Beitrag behandelt die technische Seite: welche Daten anfallen, wie sie verloren gehen und wie ein Bot sie so festhält, dass sie später auswertbar bleiben. Was daraus steuerlich folgt, ist eine Frage an eine steuerberatende Person — sie hängt von Rechtsform, Land und Einzelfall ab und lässt sich nicht allgemein beantworten.
Warum Börsen-Exporte allein nicht reichen
Die naheliegende Annahme lautet: Die Börse hat alle Daten, man kann sie jederzeit herunterladen. In der Praxis bricht diese Annahme regelmäßig.
- Begrenzte Historie: Viele APIs geben Handelsdaten nur für einen begrenzten Zeitraum zurück oder nur in kleinen Zeitfenstern pro Anfrage.
- Formatwechsel: Exportformate ändern sich, ältere Exporte lassen sich nicht mehr mit neuen zusammenführen.
- Kontoschließung: Wird ein Börsenkonto geschlossen oder der Anbieter zahlungsunfähig, ist der Zugriff sofort weg.
- Unvollständige Nebenposten: Gebühren, Funding-Zahlungen, Einzahlungen und interne Umbuchungen liegen oft in getrennten Berichten, die leicht übersehen werden.
Die belastbare Regel für den Betrieb: Die eigene Datenbank ist die Quelle, der Börsen-Export ist die Gegenprobe. Wer es umgekehrt handhabt, ist von einem Dienstleister abhängig, der keine Verpflichtung hat, Daten dauerhaft vorzuhalten.
Welche Felder je Vorgang festgehalten werden
Nachvollziehbar wird eine Transaktion nur, wenn sie sich später ohne Zusatzwissen lesen lässt. Dafür braucht jede Ausführung mindestens: Zeitstempel in UTC mit Millisekunden, Börse und Handelspaar, Richtung, ausgeführte Menge, tatsächlicher Ausführungspreis, Gebühr mit Währung, die Kennungen von Order und Ausführung, sowie eine Zuordnung zur auslösenden Strategie und deren Parameterstand.
Der letzte Punkt wird meist vergessen und ist der wertvollste: Ohne die Angabe, welche Strategieversion die Order ausgelöst hat, lässt sich später weder die steuerliche noch die betriebswirtschaftliche Frage beantworten, wo das Ergebnis herkam. Wie Parameterstände sauber versioniert werden, beschreibt der Beitrag zur Parameter-Versionierung.
Teilausführungen und Stornos
Eine Order ist kein Vorgang, sondern manchmal fünf. Wird sie in Teilen ausgeführt, entstehen mehrere Ausführungen mit unterschiedlichen Preisen und eigenen Gebühren. Wer nur die Order speichert und einen Durchschnittspreis bildet, verliert Information, die sich nicht rekonstruieren lässt.
Deshalb werden Ausführungen gespeichert, nicht Orders — und die Order als übergeordneter Datensatz mit Verweis. Stornierte und abgelehnte Orders gehören ebenfalls ins Protokoll, weil sie erklären, warum eine erwartete Position nicht existiert.
Was neben den Trades anfällt
Reine Handelsdaten sind nur ein Teil. Vollständig wird das Bild erst mit Ein- und Auszahlungen, Transfers zwischen eigenen Konten und Wallets, Netzwerkgebühren bei Transfers, Funding-Zahlungen bei Derivaten sowie sonstigen Gutschriften der Plattform.
Besonders fehleranfällig sind Transfers zwischen eigenen Konten: Sie sehen in getrennten Exporten wie eine Auszahlung und eine unabhängige Einzahlung aus. Wer sie nicht als zusammengehörig markiert, erzeugt beim Zusammenführen zwei Vorgänge aus einem — mit entsprechend falscher Bilanz.
Speicherung, die einen Anbieterwechsel übersteht
Sinnvoll ist eine eigene Datenbank mit einem festen, dokumentierten Schema plus regelmäßigem Export in ein neutrales Format wie CSV oder JSON. Die Datenbank dient der Auswertung, der Export der Haltbarkeit — er lässt sich in zehn Jahren noch öffnen, auch wenn die eingesetzte Software längst ersetzt wurde.
Dazu gehören Sicherungen an einem zweiten Ort und eine schriftliche Beschreibung des Schemas. Ein Datensatz mit einer Spalte namens „fee2", deren Bedeutung niemand mehr kennt, ist praktisch wertlos.
Zeitstempel: die stille Fehlerquelle
Zeitstempel entscheiden über Zuordnung und Reihenfolge. Sie gehören durchgehend in UTC gespeichert, mit dem Zeitstempel der Börse als führendem Wert und dem lokalen Empfangszeitstempel als zusätzlichem Feld. Lokalzeit mit Sommerzeitumstellung erzeugt jedes Jahr zweimal Vorgänge, deren Reihenfolge nicht mehr eindeutig ist.
Laufende Kontrolle statt Jahresendlauf
Der praktikable Ansatz ist ein monatlicher Abgleich: Bestände laut eigener Datenbank gegen die tatsächlichen Bestände auf den Konten. Weicht etwas ab, ist die Ursache innerhalb eines Monats noch auffindbar. Nach zwölf Monaten ist sie es meist nicht mehr — und der Aufwand für die Klärung übersteigt den Aufwand für den regelmäßigen Abgleich um ein Vielfaches.