Wie aus einer zunächst überschaubaren Depotanalyse ein zunehmend komplexes System für Marktdaten, Portfoliobewertung, Handelsstrategien und Positionsverwaltung wurde. Ein technischer Erfahrungsbericht über Python, SQLite, Datenqualität, regelbasierte Entscheidungen und die Schwierigkeiten, eine persönliche Handelsmethodik in reproduzierbare Software zu übersetzen.
Stand: 8. Oktober 2026
1. Warum ein eigener Trading Agent?
Wer sich intensiver mit Aktien beschäftigt und sein Portfolio nicht ausschließlich aus langfristig gehaltenen ETFs zusammensetzt, stößt früher oder später auf ein Problem: Die verfügbaren Informationen sind reichlich vorhanden, aber sie ergeben noch lange kein konsistentes Bild. Der Broker kennt die ausgeführten Transaktionen, eine Depotverwaltung berechnet die Performance, verschiedene Finanzportale liefern Kennzahlen und Analysteneinschätzungen, während Chartwerkzeuge die technische Entwicklung eines Wertpapiers darstellen. Was meistens fehlt, ist die Verbindung dieser Informationen mit der eigenen Handelsstrategie.
Solange ein Portfolio aus einigen wenigen Positionen besteht, lässt sich diese Verbindung noch manuell herstellen. Man kennt die Einstandskurse, erinnert sich an die Gründe für einen Kauf und entscheidet anhand der aktuellen Kursentwicklung über mögliche Verkäufe. Mit zunehmender Anzahl an Positionen, mehreren Handelsstrategien und wiederholten Nachkäufen wird dieses Verfahren jedoch unübersichtlich. Besonders schwierig wird es, wenn ein Teil des Vermögens langfristig investiert bleibt, während andere Positionen über einen Zeitraum von wenigen Monaten aktiv gehandelt werden.
Aus dieser Situation entstand die Idee meines lokalen Trading Agenten. Ich wollte kein zweites Depotprogramm entwickeln und auch keinen automatisierten Börsenhändler, der eigenständig Kauf- und Verkaufsaufträge ausführt. Gesucht war vielmehr ein System, das Marktdaten beschafft, vorhandene Positionen analysiert, meine Handelsregeln berücksichtigt und daraus nachvollziehbare Handlungsempfehlungen ableitet.
Eine wesentliche Anforderung war dabei die Unabhängigkeit von der Anwendung, über die ich den Agenten verwende. Die eigentliche Datenverarbeitung, Berechnung und Entscheidungslogik sollte nicht Bestandteil einer bestimmten Benutzeroberfläche werden. Stattdessen sollte der Agent seine Funktionen über definierte Schnittstellen bereitstellen, sodass unterschiedliche Anwendungen auf denselben Datenbestand und dieselben Berechnungsverfahren zugreifen können.
Mit dem Model Context Protocol, kurz MCP, steht dafür eine geeignete Integrationsmöglichkeit zur Verfügung. MCP ist in diesem Zusammenhang allerdings lediglich die Schnittstelle nach außen. Der eigentliche Trading Agent besteht aus seiner Datenhaltung, seinen Analyseverfahren, den Strategieregeln und der Verarbeitung der daraus resultierenden Entscheidungen.
Die Entwicklung zeigte relativ schnell, dass nicht die Berechnung eines Indikators oder die Abfrage eines Aktienkurses die größte Schwierigkeit darstellt. Wesentlich aufwendiger ist es, die verwendeten Daten zuverlässig zuzuordnen, ihre Aktualität zu beurteilen, unterschiedliche Währungen korrekt zu behandeln und die tatsächliche Entwicklung einer Position mit den ursprünglich vorgesehenen Handelsregeln in Einklang zu bringen. Genau an dieser Stelle beginnt der Unterschied zwischen einer Sammlung von Börsenskripten und einem eigenständigen Trading-System.
Quellcode und Entwicklungsstand auf GitHub
Die Entwicklung des Trading Agenten wird über Git und GitHub versioniert. Das Repository enthält den Python-Quellcode, die Datenbankstrukturen, die verschiedenen Analyse- und Strategiekomponenten sowie die zugehörigen Tests. Damit lassen sich die technischen Umsetzungsschritte unabhängig von diesem Artikel nachvollziehen.
Der hier beschriebene Stand bildet die Entwicklung bis Oktober 2026 ab. Da der Agent fortlaufend erweitert wird, können sich Implementierung, Datenbankschema und verfügbare Schnittstellen gegenüber dem Artikel verändern. Insbesondere die frei konfigurierbare Strategie-Engine und das umfassende Backtesting gehören zu den weiteren Entwicklungszielen.
GitHub-Repository: Lokaler Trading Agent – Quellcode und Entwicklung
Ein wichtiger Hinweis: Das Repository dokumentiert die technische Umsetzung und ist keine Sammlung von Handlungsempfehlungen oder ein Versprechen bestimmter Handelsrenditen.
2. Mein Trading-Ansatz: Vermögensaufbau und aktives Swing-Trading
Bevor sich die Architektur eines solchen Systems sinnvoll beschreiben lässt, muss zunächst geklärt werden, welche Handelsmethodik es überhaupt unterstützen soll. Ein Agent, der ausschließlich kurzfristige Kursbewegungen betrachtet, wird zwangsläufig andere Entscheidungen treffen als ein System, das langfristige Unternehmensbewertungen und mehrjährige Anlagehorizonte berücksichtigt.
Mein Ansatz kombiniert deshalb zwei grundsätzlich unterschiedliche Formen der Kapitalanlage. Den langfristigen Kern bildet ein ETF-Portfolio, während ein weiterer Teil des Vermögens aktiv in Einzelaktien investiert wird. Dieses Prinzip wird häufig als Core-Satellite-Strategie bezeichnet.
Abbildung 1 – Core-Satellite-Anlagestrategie
Abbildung 1: Der langfristige ETF-Kern und die aktiv verwalteten Swing-Positionen verfolgen unterschiedliche Anlagehorizonte. Die Zielkorridore liegen bei 60–70 beziehungsweise 30–40 Prozent.
Perspektivisch sollen etwa 60 bis 70 Prozent des investierten Vermögens auf den langfristigen Kern entfallen. Hier stehen insbesondere breit gestreute Aktienmärkte wie der S&P 500, Märkte außerhalb der USA und ergänzend Schwellenländer im Mittelpunkt. Dieser Teil des Portfolios ist nicht für kurzfristige Umschichtungen vorgesehen. Er soll über einen längeren Zeitraum am allgemeinen Wachstum der Aktienmärkte partizipieren und die Abhängigkeit von einzelnen Unternehmensentwicklungen begrenzen.
Die übrigen 30 bis 40 Prozent können für aktives Swing-Trading eingesetzt werden. Dabei suche ich nach Unternehmen, deren Kursentwicklung innerhalb eines überschaubaren Zeitraums ein attraktives Gewinnpotenzial erkennen lässt. Typischerweise beträgt der vorgesehene Anlagehorizont drei bis sechs Monate. Es geht also weder um Daytrading noch um den Versuch, kleinste Kursbewegungen innerhalb weniger Minuten auszunutzen.
Im Mittelpunkt stehen Unternehmen mit einer nachvollziehbaren fundamentalen Entwicklung, positiven Geschäftsaussichten und einer technischen Konstellation, die für eine Fortsetzung oder Wiederaufnahme des Aufwärtstrends spricht. Ein mögliches Kurspotenzial von ungefähr 25 Prozent ist dabei ein wichtiger Orientierungspunkt. Es handelt sich allerdings nicht um eine garantierte Rendite und auch nicht um eine Voraussetzung, die sich allein aus einem technischen Indikator ableiten ließe.
Ein weiterer Bestandteil meiner Methodik ist die gestaffelte Gewinnmitnahme. Anstatt eine Position bei Erreichen eines bestimmten Kursziels vollständig aufzulösen, sollen Gewinne teilweise realisiert werden, während ein verbleibender Bestand weiterhin an einer positiven Entwicklung teilnehmen kann. Die bisher formulierte Grundregel sieht bei einem Kursgewinn von 20 Prozent den Verkauf von 25 Prozent der ursprünglichen Position vor. Bei 25 Prozent Gewinn sollen weitere 50 Prozent der Ausgangsposition verkauft werden. Die verbleibenden 25 Prozent können gehalten werden, solange die zugrunde liegende Handelsidee und das Momentum weiterhin tragen.
Diese Regeln sind zunächst ein persönliches Strategiemodell. Sie müssen nicht für jeden Markt, jede Aktie und jede Marktsituation optimal sein. Genau deshalb ist es wichtig, sie technisch nicht mit allgemeingültigen Handelsgesetzen zu verwechseln. Ähnlich verhält es sich mit Nachkäufen. Ein gefallener Kurs ist für mich allein noch kein ausreichender Grund, weiteres Kapital einzusetzen. Vielmehr muss die ursprüngliche Investmentthese weiterhin gültig sein, und die zusätzliche Position sollte auch unter Berücksichtigung des bestehenden Portfolios sinnvoll erscheinen.
Das verfügbare Kapital spielt dabei eine besondere Rolle. Der aktuelle Kontostand eines Verrechnungskontos beschreibt nicht zwangsläufig die gesamte Investitionsfähigkeit. Zusätzliches Kapital kann bei Bedarf bereitgestellt werden. Eine starre Beschränkung sämtlicher Empfehlungen auf den momentan erfassten Cash-Bestand würde deshalb ein unvollständiges Bild erzeugen. Umgekehrt bedeutet diese Möglichkeit selbstverständlich nicht, dass jederzeit unbegrenzt Kapital eingesetzt werden sollte.
Langfristig steht hinter der Strategie außerdem ein wirtschaftliches Ziel. Das Portfolio soll nicht nur wachsen, sondern perspektivisch eine monatliche Nettoentnahme von ungefähr 4.000 Euro ermöglichen. Eine solche Entnahme muss jedoch nach Steuern, unter Berücksichtigung von Marktschwankungen und ohne unrealistische Renditeannahmen tragfähig sein. Der Trading Agent soll helfen, die dafür eingesetzten Anlageentscheidungen systematischer und überprüfbarer zu machen. Er soll nicht die Verantwortung für diese Entscheidungen übernehmen.
3. Vom ersten Skript zum eigenständigen Trading Agenten
Am Anfang standen überschaubare Aufgaben: vorhandene Depotinformationen übernehmen, Marktdaten beschaffen, einzelne Positionen analysieren und die Ergebnisse in einer brauchbaren Form zusammenführen. Python bot sich für diese Aufgaben an, da sich damit sowohl die Verarbeitung strukturierter Dateien als auch SQL-Datenbanken, HTTP-Schnittstellen und numerische Berechnungen vergleichsweise unkompliziert umsetzen lassen. Allerdings zeigte sich früh, dass lose miteinander verbundene Skripte nur so lange gut funktionieren, wie die Datenstrukturen einfach bleiben.
Bereits bei der Verarbeitung von Depottransaktionen entstanden Anforderungen, die eine zentrale Datenhaltung erforderlich machten. Käufe und Verkäufe mussten eindeutig Wertpapieren zugeordnet werden. Wiederholte Importe durften keine zusätzlichen Transaktionen erzeugen. Einstandskurse mussten anhand der zeitlichen Reihenfolge der Buchungen rekonstruiert werden. Gleichzeitig sollten die Ergebnisse später für weitere Analysen verfügbar bleiben. Damit wurde SQLite zur zentralen Datenbasis des Projekts.
Aus dieser Grundlage entstanden schrittweise weitere Komponenten. Die erste Entwicklungsphase konzentrierte sich auf die Datenhaltung und die Abbildung von Portfolioinformationen. Danach folgten die Analyse-Engines und die eigentliche Strategieauswertung. Mit Phase 3A wurde die Verarbeitung von Handelsstrategien systematisiert. Phase 3A.5 ergänzte die Behandlung unterschiedlicher Handelswährungen und historischer Wechselkurse. In Phase 3B.1 rückte anschließend die Verwaltung laufender Swing-Positionen in den Mittelpunkt.
Dabei wurde deutlich, dass eine Handelsstrategie nicht ausschließlich aus Einstiegssignalen und Kurszielen besteht. Sie benötigt einen Zustand. Ein bereits erfolgter Teilverkauf muss bei späteren Bewertungen berücksichtigt werden. Ein Nachkauf verändert den Einstandskurs und unter Umständen die ursprüngliche Positionsgröße. Ein vollständiger Verkauf beendet eine Kampagne, darf aber ihre Historie nicht beseitigen.
Mit der Einführung solcher Zusammenhänge veränderte sich der Charakter des Projekts. Es ging zunehmend weniger darum, zusätzliche Kennzahlen zu berechnen, sondern darum, unterschiedliche fachliche Zustände konsistent zu verwalten. Das Projekt wird inzwischen in einem eigenständigen Git-Repository entwickelt. Zu den dokumentierten Meilensteinen gehört die Version v0.1.0 sowie der spätere Commit 4b6de7f vom 28. September 2026, mit dem die Verwendung von Datenbankpfaden über Kommandozeilenparameter vereinheitlicht wurde. Die vollständige Regressionstestsuite bestand zu diesem Zeitpunkt 240 Tests.
Diese Zahl ist vor allem als Indikator für den gewachsenen Umfang der automatisierten Prüfungen interessant. Sie sagt für sich genommen noch nichts darüber aus, ob die Handelsstrategie erfolgreich ist. Dafür sind andere Nachweise erforderlich. Die Trennung von technischer Korrektheit und wirtschaftlicher Wirksamkeit sollte für die weitere Entwicklung wesentlich bleiben.
4. Systemarchitektur: Komponenten, Schnittstellen und Datenflüsse
Der Trading Agent ist als lokal betriebenes System aufgebaut. Die eigentliche Fachlogik liegt in Python-Modulen, die über eine gemeinsame Datenbank und definierte Schnittstellen zusammenarbeiten. Die Architektur lässt sich in mehrere funktionale Ebenen unterteilen. Am Anfang stehen die externen Datenquellen. Dazu gehören Depottransaktionen aus Parqet, historische und aktuelle Marktdaten, Fundamentaldaten aus Unternehmensberichten sowie Wechselkursinformationen der Europäischen Zentralbank.
Die Datenadapter haben die Aufgabe, diese unterschiedlichen Informationen in ein einheitliches internes Format zu überführen. Erst danach sollten sie von den Analyse- und Strategiekomponenten verarbeitet werden.
Abbildung 2 – Logische Systemarchitektur
Abbildung 2: Datenquellen, Import, zentrale Datenbank, Analyse- und Strategiekomponenten sowie die MCP-Schnittstelle. Das Schaubild stellt die logische Architektur dar, nicht den bereits vollständig automatisierten Ablauf.
Diese Darstellung zeigt die logische Zielarchitektur. Sie bedeutet nicht, dass sämtliche Komponenten bereits vollständig unabhängig voneinander implementiert sind oder alle Verarbeitungsschritte heute über einen einzigen automatisierten Ablauf ausgeführt werden.
Eine der wesentlichen Architekturentscheidungen betrifft die Trennung zwischen lesenden und verändernden Funktionen. Eine Portfolioabfrage soll keine Daten verändern. Ein Transaktionsimport oder eine strategische Zustandsänderung muss dagegen kontrolliert und nachvollziehbar erfolgen. Dasselbe Prinzip gilt für Analysen. Ein Analysemodul darf Kursdaten und Fundamentaldaten bewerten, sollte aber nicht eigenständig historische Depottransaktionen korrigieren. Solche Änderungen gehören in ausdrücklich dafür vorgesehene Verarbeitungsschritte.
Der Vorteil dieser Trennung liegt weniger in einer besonders eleganten Softwarearchitektur als in der Möglichkeit, Fehler einzugrenzen. Wenn eine Positionsbewertung falsch ausfällt, muss nachvollziehbar bleiben, ob der Fehler aus den Eingangsdaten, einer Währungsumrechnung, der Kostenbasis oder der Strategieauswertung stammt.
Ein weiterer wichtiger Punkt ist die lokale Datenhaltung. Analysen können auf einem vorhandenen Datenbestand wiederholt werden, ohne für jeden einzelnen Verarbeitungsschritt dieselben externen Schnittstellen erneut abfragen zu müssen. Die lokal gespeicherten Informationen sind allerdings nur dann eine belastbare Grundlage, wenn Herkunft, Aktualität und Vollständigkeit ebenfalls verwaltet werden. Damit verschiebt sich die eigentliche Schwierigkeit von der Beschaffung einer Information zu ihrer kontrollierten Weiterverarbeitung.
5. Marktdaten und Fundamentals: Beschaffung, Qualität und Grenzen
Ein Börsenkurs sieht auf den ersten Blick wie eine einfache Zahl aus. Tatsächlich benötigt ein Trading-System dazu wesentlich mehr Informationen. Entscheidend sind unter anderem Handelsplatz, Handelswährung, Zeitstempel und die eindeutige Zuordnung zum richtigen Wertpapier. Gerade international gehandelte Aktien können unter verschiedenen Symbolen und an unterschiedlichen Handelsplätzen erscheinen. Eine ausschließlich auf Tickern basierende Zuordnung ist deshalb fehleranfällig. Ein Symbol ist nicht zwangsläufig weltweit eindeutig und kann sich im Laufe der Zeit ändern.
Der Trading Agent verwendet daher ein Datenmodell, das Wertpapieridentitäten von quellspezifischen Symbolen trennt. Die Tabellen security und source_symbols gehören zu den hierfür vorgesehenen Strukturen. Marktdaten werden anschließend über die interne Wertpapieridentität zugeordnet.
Bei Fundamentaldaten ist die Situation noch komplizierter. Für eine Bewertung werden beispielsweise Umsatz, Gewinn, operativer Cashflow, Investitionsausgaben oder Verschuldung benötigt. Diese Informationen stammen nicht notwendigerweise aus derselben Quelle und liegen häufig in unterschiedlichen Berichtsperioden vor.
Die Verarbeitung von SEC-Daten zeigte exemplarisch, wie problematisch scheinbar einfache Kennzahlen sein können. Für die Berechnung des freien Cashflows wird üblicherweise der operative Cashflow um Investitionsausgaben reduziert. In der Praxis verwenden Unternehmen jedoch unterschiedliche XBRL-Tags für einzelne Bestandteile ihrer Investitionstätigkeit. Im Projekt mussten deshalb zusätzliche Zuordnungen für Positionen wie PaymentsToAcquireOtherPropertyPlantAndEquipment und PaymentsToAcquireProductiveAssets berücksichtigt werden. Der technische Fehler bestand nicht darin, dass die mathematische Berechnung besonders schwierig gewesen wäre. Das Problem lag in der Interpretation der Quelldaten.
Fehlende Informationen dürfen nicht stillschweigend als Null interpretiert werden. Wenn operative Cashflow-Daten oder die erforderlichen Investitionsausgaben fehlen, ist die Berechnung des freien Cashflows unter Umständen nicht möglich. Wird trotzdem ein Zahlenwert erzeugt, kann dieser formal korrekt aussehen und dennoch fachlich falsch sein.
Abbildung 3 – Datenqualitätsprüfung
Abbildung 3: Der Weg von externen Quelldaten über Normalisierung und Qualitätsbewertung zur Analyse. Unvollständige Daten müssen erkennbar bleiben, statt durch scheinbar gültige Kennzahlen ersetzt zu werden.
Die Datenqualitätsprüfungen des Agenten unterscheiden deshalb Zustände wie MISSING, PARTIAL und vollständig verfügbare Daten. Frühere Auswertungen zeigten teilweise erhebliche Lücken. In einem dokumentierten Zustand waren von 32 betrachteten Titeln neun nur teilweise und 23 nicht ausreichend mit den benötigten Daten versorgt. Spätere Auditläufe konnten für bestimmte Datenbestände einen vollständigeren Zustand bestätigen.
Solche Ergebnisse widersprechen sich nicht zwangsläufig. Sie beschreiben unterschiedliche Zeitpunkte und Prüfumfänge. Gerade deshalb muss eine Datenqualitätsaussage immer mit dem geprüften Bestand und dem Zeitpunkt der Prüfung verbunden bleiben.
Für die weitere Entwicklung ist entscheidend, dass der Agent die Datenqualität nicht nur protokolliert, sondern auch bei seinen Empfehlungen berücksichtigt. Eine Aktie mit unvollständigen Fundamentaldaten darf nicht dieselbe Aussagekraft erhalten wie eine vollständig analysierte Position. Ein fehlender Wert ist ein Informationszustand und keine schlechte Unternehmenskennzahl.
6. SQLite als Fundament: Datenmodell und Persistenz
SQLite wurde zunächst aus pragmatischen Gründen gewählt. Die Datenbank benötigt keinen eigenständigen Serverprozess, lässt sich einfach sichern und kann unmittelbar aus Python angesprochen werden. Für einen lokalen Trading Agenten mit überschaubarer Zahl gleichzeitiger Schreibzugriffe ist das ein sinnvoller Ausgangspunkt. Im Laufe der Entwicklung ist die Datenbank jedoch deutlich über ihre ursprüngliche Aufgabe als Speicher für Transaktionen hinausgewachsen.
Das frühe Schema umfasste unter anderem Tabellen für Wertpapiere, Marktdaten, Fundamentaldaten, Analysteneinschätzungen, Kursziele, Nachrichten, Ereignisse, Watchlists, Positionen und Entscheidungen. Hinzu kamen Verwaltungsinformationen zu Importen und Datenquellen. Mit der Erweiterung um Strategien, Wechselkurse und Swing-Kampagnen wurde das Schema schrittweise ergänzt. In einem später dokumentierten Stand umfasste es 23 Tabellen, drei Views, 35 Indizes und sechs Trigger. Die genaue Struktur des aktuellen Schemas muss für eine abschließende technische Dokumentation mit der tatsächlich eingesetzten Datenbank abgeglichen werden.
Besonders wichtig ist die eindeutige Abgrenzung unterschiedlicher Arten von Informationen. Eine Transaktion beschreibt einen tatsächlich stattgefundenen Kauf oder Verkauf. Eine Position beschreibt einen aus Transaktionen abgeleiteten Bestand. Eine Strategiezuordnung legt fest, nach welchen Regeln dieser Bestand verwaltet wird. Ein Analyseergebnis beschreibt die Bewertung zu einem bestimmten Zeitpunkt. Eine Entscheidung dokumentiert schließlich eine daraus abgeleitete Handlungsoption. Diese Informationen sind miteinander verknüpft, dürfen aber nicht miteinander verwechselt werden.
Ein weiterer Schwerpunkt ist die Idempotenz. Wird dieselbe Parqet-Datei mehrfach importiert, dürfen daraus nicht mehrfach dieselben Buchungen entstehen. Für Importvorgänge wurden deshalb Verfahren zur Erkennung bereits verarbeiteter Daten vorgesehen, unter anderem anhand von Prüfsummen. Dasselbe Prinzip ist für spätere Verarbeitungsschritte erforderlich. Eine wiederholte Strategiebewertung darf nicht automatisch zwei identische Teilverkäufe erzeugen. Ein historischer FX-Backfill darf keine zusätzlichen Transaktionen anlegen.
Im Zusammenhang mit der Weiterentwicklung entstanden außerdem Probleme durch unterschiedliche Datenbankpfade. Wenn einzelne Skripte implizit eine Datenbank im Arbeitsverzeichnis erwarten, andere dagegen auf einen fest konfigurierten produktiven Pfad zugreifen, können Tests und operative Verarbeitung unbemerkt mit verschiedenen Datenbeständen arbeiten. Mit dem Commit 4b6de7f wurden deshalb Datenbankpfadparameter vereinheitlicht. Das ist eine vergleichsweise unspektakuläre Änderung, zeigt aber gut, worauf es bei einem wachsenden System ankommt: Die Verlässlichkeit hängt häufig an technischen Details, die mit der eigentlichen Börsenanalyse wenig zu tun haben.
Für die künftige Entwicklung bleibt SQLite zunächst ausreichend. Sollte das System später mehrere gleichzeitig schreibende Prozesse, deutlich umfangreichere historische Kursbestände oder verteilte Ausführungen unterstützen müssen, wäre die Datenbankarchitektur erneut zu bewerten. Ein Wechsel auf ein anderes Datenbanksystem ist derzeit aber kein Selbstzweck.
7. Portfolioverwaltung: Vom Depotbestand zur konsistenten Datenbasis
Parqet dient als wesentliche Quelle für die tatsächliche Zusammensetzung meines Portfolios. Die Anwendung liefert Bestände, Transaktionshistorien und Performanceinformationen. Für den Trading Agenten ist insbesondere die Transaktionshistorie interessant, weil sich daraus die Entwicklung einzelner Positionen rekonstruieren lässt.
Die Verarbeitung beginnt mit dem Import strukturierter Exportdaten. Die verwendeten CSV-Dateien enthalten unter anderem Buchungszeitpunkt, Kurs, Stückzahl, Betrag, Steuern, Gebühren, Transaktionstyp, Wertpapierkennung und Währung. Dabei sind bereits scheinbar einfache Formatdetails relevant. Die Parqet-Exporte verwenden beispielsweise Semikolons als Feldtrenner und können Dezimalkommas enthalten. Ohne eine passende Verarbeitung lassen sich Zahlen falsch interpretieren oder Spalten fehlerhaft zuordnen.
Anschließend müssen die importierten Transaktionen normalisiert und chronologisch verarbeitet werden. Aus Käufen, Verkäufen und gegebenenfalls weiteren Bestandsveränderungen entstehen die aktuellen Positionsgrößen und ihre Einstandswerte. Im Projekt wurde hierfür unter anderem eine fortgeschriebene durchschnittliche Kostenbasis verwendet. Ein Nachkauf verändert damit den durchschnittlichen Einstandskurs, während ein Teilverkauf den verbleibenden Bestand reduziert.
Diese Berechnung ist für eine Portfoliobetrachtung sinnvoll, reicht aber für die Verwaltung einzelner Swing-Kampagnen nicht immer aus. Dort kann entscheidend sein, welche Stückzahlen zur ursprünglichen Position gehören, wann eine Nachkauftranche eröffnet wurde und auf welche Referenz sich eine Gewinnmitnahme bezieht.
Ein weiteres Problem entsteht durch die unterschiedliche fachliche Bedeutung von Transaktionen. Ein Verkauf kann aus einer automatisierten Gewinnmitnahmeregel resultieren, aus einer manuellen Risikoreduzierung oder aus einer grundlegenden Neubewertung des Unternehmens. Im Depot erscheint zunächst lediglich eine Verkaufsbuchung. Der Agent kann aus dieser Buchung nicht zuverlässig ableiten, weshalb der Verkauf stattgefunden hat.
Deshalb müssen importierte Transaktionen und ihre strategische Interpretation getrennt werden. Die Transaktionshistorie ist die Quelle der tatsächlich ausgeführten Geschäfte. Die Strategiehistorie beschreibt, wie diese Geschäfte im Zusammenhang mit den Handelsregeln bewertet werden. Für den weiteren Ausbau ist ein sauberer Reconciliation-Prozess vorgesehen, der Transaktionen mit den verwalteten Swing-Kampagnen abgleicht. Dabei sollen eindeutige Transaktionsreferenzen helfen, doppelte Zuordnungen und nachträgliche Fehlinterpretationen zu vermeiden.
Auch der Cash-Bestand muss als eigenständige Information behandelt werden. Ein Portfolio kann Aktienpositionen vollständig und korrekt abbilden, während Einzahlungen, Auszahlungen oder frei verfügbare Mittel unvollständig erfasst sind. Eine daraus abgeleitete Kaufempfehlung muss diese Einschränkung berücksichtigen. Die fehlende Kenntnis über verfügbare Liquidität darf weder zu einer unbegründeten Kaufempfehlung noch zu einem pauschalen Ausschluss sinnvoller Kandidaten führen.
8. Währungen und Bewertungszeitpunkte: Die FX-Engine
Ein international ausgerichtetes Portfolio lässt sich nicht sinnvoll bewerten, ohne Wechselkurse systematisch zu berücksichtigen. Ein erheblicher Teil meiner Einzelaktien wird in US-Dollar gehandelt, während die Gesamtbetrachtung des Portfolios in Euro erfolgt. Die ursprüngliche Kursentwicklung und die tatsächliche Wertentwicklung in Euro sind deshalb nicht identisch.
Steigt eine Aktie beispielsweise um zehn Prozent in US-Dollar, während der Dollar gegenüber dem Euro an Wert verliert, kann die Rendite aus Sicht des Euro-Anlegers deutlich geringer ausfallen. Umgekehrt kann eine positive Währungsentwicklung den Gewinn verstärken.
Die FX-Engine wurde in Phase 3A.5 eingeführt, um diese Effekte nachvollziehbar zu verarbeiten. Die Implementierung verwendet unter anderem historische Referenzkurse der Europäischen Zentralbank und enthält mit fx_resolver.py eine eigene Komponente zur Wechselkursauflösung. Die Grundidee ist einfach: Originalkurse und Transaktionswerte bleiben in ihrer jeweiligen Handelswährung erhalten. Für die Portfoliobewertung werden sie zusätzlich zum passenden Bewertungszeitpunkt in Euro umgerechnet.
Bei einer historischen Transaktion ist dafür der damals relevante Wechselkurs erforderlich. Bei der aktuellen Bewertung einer noch gehaltenen Position kommt dagegen ein neuer Kurs zum Einsatz. Besonders wichtig ist die Richtung der Umrechnung. Wird ein Referenzkurs als USD je EUR angegeben, muss ein US-Dollar-Betrag durch diesen Kurs dividiert werden, um seinen Euro-Gegenwert zu erhalten. Eine Verwechslung dieser Richtung erzeugt erhebliche Bewertungsabweichungen.
Im Projekt wurden solche Berechnungen anhand realer Positionen überprüft. Ein dokumentierter HALO-Datensatz führte beispielsweise eine Bewertung von 111,865 US-Dollar und deren Umrechnung in rund 97,359 Euro. Dabei ging es nicht nur um das richtige Endergebnis, sondern darum, die verwendeten Kurse und Bewertungszeitpunkte reproduzierbar nachzuweisen.
Im weiteren Verlauf wurden außerdem historische Wechselkursdaten nachgetragen und kontrolliert. Solche Backfills sind technisch anspruchsvoller, als es zunächst erscheint. Die nachträgliche Ergänzung historischer Daten kann nämlich die Bewertung früherer Positionen verändern, ohne dass sich an den zugrunde liegenden Transaktionen etwas geändert hat. Der Agent muss deshalb zwischen unveränderlichen Transaktionsfakten, historischen Referenzdaten und neu berechneten Bewertungen unterscheiden.
Für die Zukunft ist eine transparente Zerlegung der Performance in Wertpapier- und Währungsbeiträge sinnvoll. Damit ließe sich beispielsweise feststellen, welcher Anteil eines realisierten Gewinns tatsächlich auf eine positive Aktienentwicklung und welcher auf den Wechselkurs zurückzuführen ist.
9. Analyse-Engines: Aus Marktdaten werden Bewertungen
Die Analyse eines Wertpapiers besteht nicht darin, möglichst viele Indikatoren zu berechnen. Entscheidend ist, ob die verwendeten Verfahren unterschiedliche, für eine Handelsentscheidung relevante Informationen liefern. Für mein Swing-Trading spielen die Kursentwicklung, bestehende Trends, Momentum und die fundamentale Situation eines Unternehmens eine wichtige Rolle. Technische Indikatoren können helfen, diese Eigenschaften zu quantifizieren.
Gleitende Durchschnitte zeigen beispielsweise, ob sich ein Wertpapier oberhalb oder unterhalb seines mittelfristigen Kursniveaus bewegt. RSI und MACD liefern zusätzliche Hinweise zur Stärke und Veränderung einer Kursbewegung. Handelsvolumen kann dabei helfen, die Bedeutung eines Ausbruchs oder einer Trendfortsetzung einzuschätzen. Keiner dieser Indikatoren ist jedoch für sich genommen ein zuverlässiger Kauf- oder Verkaufsmechanismus.
Ein hoher RSI kann auf eine überdehnte Kursbewegung hindeuten, aber ebenso Ausdruck eines besonders starken Aufwärtstrends sein. Ein Kurs oberhalb des gleitenden Durchschnitts bestätigt eine positive Entwicklung, sagt aber wenig darüber aus, ob die Aktie fundamental teuer oder günstig bewertet ist.
Aus diesem Grund verfolgt der Trading Agent einen mehrstufigen Analyseansatz. Marktdaten und technische Informationen werden mit weiteren Unternehmensdaten zusammengeführt. Die vorhandenen Analyse-Engines können daraus strukturierte Bewertungen und Entscheidungsgrundlagen erzeugen. Dabei muss zwischen verschiedenen Arten von Ergebnissen unterschieden werden. Ein technisches Signal beschreibt zunächst eine beobachtbare Marktsituation. Ein fundamentaler Befund beschreibt die wirtschaftliche Lage eines Unternehmens. Eine strategische Bewertung setzt diese Informationen schließlich in Beziehung zur eigenen Handelsmethodik.
Erst wenn zusätzlich die aktuelle Position, die Portfoliozusammensetzung und bestehende Risikogrenzen berücksichtigt werden, lässt sich daraus eine konkrete Handlungsempfehlung ableiten. Die dokumentierten Entwicklungsstände zeigen bereits eine regelbasierte Entscheidungslogik. Bei einer HALO-Position wurde beispielsweise trotz eines Kursgewinns von rund 36,8 Prozent zeitweise die Entscheidung HOLD ausgewiesen.
Das ist nicht zwangsläufig ein Widerspruch zu erreichten Gewinnschwellen. Entscheidend ist, welche Strategieereignisse bereits stattgefunden haben, welche Stückzahlen noch gehalten werden und ob die Bewertung eine neue Transaktion oder lediglich die Fortführung einer bestehenden Position betrifft. Ein System, das ausschließlich den aktuellen prozentualen Gewinn betrachtet, könnte solche Unterschiede nicht zuverlässig behandeln.
Die weitere Entwicklung soll deshalb insbesondere die Erklärbarkeit einzelner Entscheidungen verbessern. Für jede Empfehlung sollte nachvollziehbar sein, welche Daten verwendet wurden, welche Regeln gegriffen haben und welche Einschränkungen die Aussagekraft beeinflussen.
10. Watchlist, Kandidatenauswahl und Marktbeobachtung
Eine Watchlist ist zunächst lediglich eine Sammlung von Wertpapieren. Für aktives Swing-Trading genügt das nicht. Entscheidend ist, weshalb ein Wertpapier auf der Liste steht und unter welchen Bedingungen daraus ein konkreter Kaufkandidat wird.
Mein Ansatz beginnt mit der Suche nach Unternehmen, deren fundamentale Entwicklung und Kursverhalten ein attraktives Potenzial erkennen lassen. Dazu gehören beispielsweise Unternehmen mit positiven Gewinnrevisionen, starken Wachstumsperspektiven oder einer technischen Situation, die für eine Fortsetzung des Aufwärtstrends spricht. Die Watchlist soll diese Informationen nicht nur speichern, sondern ihre Veränderung über die Zeit nachvollziehbar machen.
Ein Kandidat kann fundamental interessant sein, obwohl die technische Einstiegssituation ungünstig erscheint. Ebenso kann eine Aktie kurzfristig starkes Momentum zeigen, ohne dass die wirtschaftliche Entwicklung des Unternehmens die Bewertung ausreichend stützt. Solche Unterschiede sollten in der Analyse erhalten bleiben. Eine bloße Gesamtnote würde wichtige Informationen verdecken.
Die Datenbank enthält für die Watchlist eine eigene Struktur, die mit den zentralen Wertpapieridentitäten verbunden ist. Für die Pflege wurde ein datenbankbasierter und wiederholbarer Verarbeitungspfad entwickelt, der keine unbekannten Stammdaten erfinden soll. Im bisherigen Projektverlauf wurden verschiedene Unternehmen als Swing-Kandidaten oder bereits laufende Positionen betrachtet, darunter TSMC, HALO, Eli Lilly, ASML, Lam Research und Rheinmetall.
Die Auswahl solcher Werte zeigt, dass die Watchlist nicht auf eine einzelne Branche beschränkt ist. Gleichwohl entstehen durch mehrere technologienahe Unternehmen und Halbleiterwerte Konzentrationsrisiken, die bei der Bewertung berücksichtigt werden müssen.
Das Ziel ist eine dynamische Kandidatenliste, bei der sich nicht nur der aktuelle Zustand, sondern auch die Veränderung der Bewertung nachvollziehen lässt. Ein Wertpapier sollte aufsteigen können, wenn sich seine technische Situation verbessert, und zurückgestuft werden, wenn die ursprüngliche Investmentthese an Substanz verliert. Dafür werden künftig stärker strukturierte Ereignisse, zeitbezogene Analysen und eine reproduzierbare Rangfolge benötigt.
Eine wichtige fachliche Grenze bleibt dabei bestehen: Ein rechnerisch hohes Kurspotenzial macht aus einer Aktie noch keinen geeigneten Kauf. Die Aussage muss immer mit dem Risiko, dem Anlagehorizont und der vorhandenen Portfoliozusammensetzung abgeglichen werden.
11. Vom persönlichen Trading-Ansatz zur konfigurierbaren Strategie-Engine
Die bisherige Entwicklung des Trading Agenten orientiert sich wesentlich an meiner eigenen Handelsmethodik. Das war für die ersten Implementierungen sinnvoll, weil konkrete Regeln deutlich leichter technisch umzusetzen sind als eine vollständig allgemeine Strategiearchitektur. Inzwischen stellt sich jedoch die Frage, ob der Agent dauerhaft an genau diese Regeln gebunden bleiben soll. Meine Antwort darauf ist eindeutig: Die persönliche Strategie soll erhalten bleiben, aber sie darf nicht die einzige Methode sein, die das System grundsätzlich unterstützt.
Der heutige dokumentierte Stand umfasst bereits Analyse- und Strategiekomponenten, die Zuordnung von Positionen zu Handelsstrategien sowie die Verwaltung von Swing-Kampagnen. In der Datenbank wurden beispielsweise sowohl Swing- als auch langfristige Strategiezuordnungen verwendet. Eine vollständig frei konfigurierbare Strategie-Engine, die beliebige Handelsmethoden ohne Anpassung des Programmcodes unterstützt, ist dagegen bislang nicht als abgeschlossen nachgewiesen.
Abbildung 4 – Konfigurierbare Strategie-Engine
Abbildung 4: Zielbild einer Strategie-Engine, die verschiedene regelbasierte Handelsansätze auf einer gemeinsamen technischen Grundlage verarbeitet. Die frei konfigurierbaren Profile und das umfassende Backtesting gehören zur geplanten Weiterentwicklung.
Das technische Ziel geht deshalb über eine Sammlung konfigurierbarer Prozentwerte hinaus. Eine Strategie soll künftig als eigenständiges, versioniertes Profil beschrieben werden können. Ein solches Profil definiert zunächst das zulässige Anlageuniversum und den vorgesehenen Anlagehorizont. Hinzu kommen Bedingungen für den Einstieg, mögliche Nachkäufe, Gewinnmitnahmen, Verlustbegrenzungen und den vollständigen Ausstieg.
Für eine Momentum-Strategie könnten beispielsweise Trendstärke, Kurslage relativ zu gleitenden Durchschnitten und Momentum-Indikatoren relevant sein. Eine Breakout-Strategie würde dagegen stärker auf den Ausbruch aus einer bestimmten Handelsspanne und dessen Bestätigung durch Volumen achten. Bei einer Pullback-Strategie stünde wiederum die Korrektur innerhalb eines bestehenden Aufwärtstrends im Mittelpunkt. Diese Ansätze unterscheiden sich nicht nur durch einzelne Zahlenwerte. Sie benötigen teilweise unterschiedliche Arten von Regeln.
Daraus folgt, dass eine universelle Strategie-Engine konfigurierbare Regelbausteine und deren logische Verknüpfung unterstützen muss. Die reine Speicherung von RSI-Grenzwerten oder Gewinnschwellen reicht dafür nicht aus. Meine eigene Momentum-orientierte Swing-Strategie kann als erstes Strategieprofil dienen. Sie umfasst den mehrmonatigen Anlagehorizont, die Auswahl von Unternehmen mit attraktivem Kurspotenzial und die gestaffelte Gewinnmitnahme bei 20 und 25 Prozent. Andere Strategieprofile könnten abweichende Einstiegskriterien, engere Stop-Regeln oder eine andere Form der Positionsgrößenbestimmung verwenden.
Besonders wichtig ist die Versionierung. Wird ein Strategieprofil verändert, darf sich dadurch nicht nachträglich die historische Bedeutung bereits ausgeführter Geschäfte ändern. Eine Swing-Kampagne muss deshalb mit derjenigen Strategieversion verbunden bleiben, unter der sie eröffnet wurde. Neue Regeln können für künftige Kampagnen gelten, während bestehende Positionen entweder nach ihren ursprünglichen Vorgaben weitergeführt oder durch eine ausdrücklich dokumentierte Umstellung migriert werden.
Dazu gehört später auch eine Strategievalidierung. Unterschiedliche Profile sollen mit historischen Daten untersucht und miteinander verglichen werden können. Dabei darf die Optimierung von Parametern nicht dazu führen, dass eine Strategie ausschließlich auf vergangene Kursverläufe zugeschnitten wird. Das Ziel ist also nicht, möglichst viele Handelsmodelle gleichzeitig auszuführen. Vielmehr soll eine technische Grundlage entstehen, auf der unterschiedliche Methoden nachvollziehbar beschrieben, geprüft und verglichen werden können. Damit wird aus einem Agenten für meine persönlichen Handelsregeln perspektivisch ein strategieunabhängiges Analysesystem.
12. Risikomanagement, Kapitalsteuerung und Entscheidungslogik
Eine gute Aktienanalyse genügt nicht, um eine sinnvolle Portfolioentscheidung zu treffen. Dieselbe Aktie kann für ein Depot geeignet sein und für ein anderes eine ungünstige zusätzliche Konzentration darstellen. Der Trading Agent muss deshalb zwischen der Attraktivität eines Wertpapiers und seiner Eignung für das bestehende Portfolio unterscheiden.
Ein wichtiger Bestandteil meiner Strategie ist die Aufteilung zwischen langfristigen Anlagen und aktivem Swing-Trading. Perspektivisch sollen ungefähr 60 bis 70 Prozent im langfristigen Kern und 30 bis 40 Prozent in aktiv verwalteten Positionen investiert sein. Diese Verteilung ist jedoch ein strategischer Zielkorridor und keine Garantie dafür, dass sie zu jedem Zeitpunkt bereits eingehalten wird. Frühere technische Auswertungen zeigten zeitweise einen deutlich höheren Swing-Anteil. Solche Abweichungen sind gerade deshalb relevant, weil zusätzliche Kaufempfehlungen nicht isoliert betrachtet werden dürfen.
Auch innerhalb des Swing-Anteils können Konzentrationsrisiken entstehen. Mehrere Unternehmen aus dem Halbleitersektor sind beispielsweise nicht voneinander unabhängig, selbst wenn sie unterschiedliche Produkte herstellen und an verschiedenen Börsen gehandelt werden. Die Risikobetrachtung muss daher über die Anzahl der Positionen hinausgehen. Branchen, wirtschaftliche Abhängigkeiten, Währungen und gemeinsame Marktfaktoren können eine Rolle spielen.
Ein weiterer Punkt betrifft die Positionsgröße. Ein attraktives Kaufsignal beantwortet zunächst nicht die Frage, welcher Kapitalbetrag eingesetzt werden sollte. Dafür werden Regeln zur maximalen Einzelposition, zum Risiko je Trade und zur verfügbaren Gesamtkapazität benötigt. Auch Verlustbegrenzungen gehören dazu. Die bereits formulierten Gewinnmitnahmeregeln sind vergleichsweise konkret. Eine allgemeingültige und vollständig parametrisierte Stop-Loss-Methodik ist dagegen noch nicht abschließend festgelegt. Hier wäre es fachlich falsch, beliebige Prozentgrenzen nachträglich als bestehende Handelsregeln auszugeben.
Eine künftige Strategie-Engine muss verschiedene Verfahren unterstützen können, darunter feste prozentuale Stops, volatilitätsabhängige Grenzen oder das Nachziehen einer Verlustbegrenzung bei steigenden Kursen.
Die Kapitalsteuerung benötigt darüber hinaus eine differenzierte Betrachtung vorhandener und zusätzlich verfügbarer Mittel. Der aktuelle Cash-Bestand beschreibt nur die momentan erfasste Liquidität. In meinem Fall kann zusätzliches Kapital bereitgestellt werden. Diese Möglichkeit soll der Agent künftig als explizite Information berücksichtigen können, beispielsweise durch die Eigenschaft external_funding_available.
Daraus ergibt sich allerdings keine automatische Kaufberechtigung. Der Agent muss weiterhin unterscheiden, ob eine Position strategisch attraktiv ist, welche Kapitalmenge erforderlich wäre und ob diese Mittel tatsächlich freigegeben wurden. Genau an dieser Stelle wird die Trennung zwischen Analyse, Empfehlung und Entscheidung besonders wichtig. Der Agent darf eine zusätzliche Investition empfehlen oder eine bestehende Position zur Reduzierung vorschlagen. Die tatsächliche Ausführung bleibt aber eine eigenständige Entscheidung.
Das Ziel ist kein System, das den Anleger möglichst vollständig ersetzt, sondern eines, das dessen Entscheidungen konsistenter und nachvollziehbarer macht.
13. Swing-Lifecycle: Von der Eröffnung bis zum Abschluss einer Position
Die Verwaltung laufender Swing-Positionen gehört zu den Bereichen, in denen sich die technische Komplexität des Projekts besonders deutlich gezeigt hat. Eine Aktie kann im Depot mit einer bestimmten Stückzahl und einem durchschnittlichen Einstandskurs erscheinen. Für die Handelsstrategie ist das jedoch nur ein Ausschnitt der relevanten Informationen. Entscheidend ist, wann die Position eröffnet wurde, welche ursprüngliche Stückzahl zur Kampagne gehört, ob später Nachkäufe stattgefunden haben und welche Gewinnmitnahmen bereits ausgeführt wurden.
Der Begriff Swing-Kampagne beschreibt deshalb nicht einfach den aktuellen Aktienbestand, sondern den zusammenhängenden Verlauf einer Handelsidee. Mit Phase 3B.1 wurde hierfür eine eigene Lifecycle-Verarbeitung entwickelt. Sie ergänzt die bisherigen Portfolioinformationen um strategische Zustände und ermöglicht es, laufende Positionen differenzierter zu bewerten.
Abbildung 5 – Swing-Lifecycle
Abbildung 5: Beispiel einer Swing-Kampagne mit 100 Aktien zu Beginn. Bei +20 Prozent werden 25 Stück verkauft, bei +25 Prozent weitere 50 Stück der ursprünglichen Position. Die restlichen 25 Aktien bleiben zunächst bestehen.
Die Grundstruktur lässt sich anhand einer einfachen Position erläutern. Angenommen, eine Kampagne beginnt mit 100 Aktien. Die Strategie sieht vor, bei 20 Prozent Gewinn 25 Stück zu verkaufen und bei 25 Prozent Gewinn weitere 50 Stück abzugeben. Anschließend verbleiben 25 Aktien als Restposition. Damit diese Regeln funktionieren, muss das System wissen, auf welche ursprüngliche Stückzahl sich die Prozentangaben beziehen. Würde der zweite Teilverkauf stattdessen auf den nach TP1 verbleibenden Bestand angewendet, entstünde ein anderes Ergebnis.
Nachkäufe erhöhen die Komplexität zusätzlich. Sie können die durchschnittliche Kostenbasis verändern und werfen die Frage auf, ob die hinzugekauften Aktien Bestandteil derselben Kampagne oder eine eigenständige Tranche mit anderen Zielmarken sind. Diese fachlichen Fragen müssen ausdrücklich definiert werden. Eine Datenbank kann zwar sämtliche Buchungen korrekt speichern, aber sie entscheidet nicht von selbst, welche strategische Bedeutung ein Nachkauf hat.
Ein weiteres Problem ergibt sich aus der nachträglichen Einführung des Lifecycle-Modells. Bereits vorhandene Positionen besitzen historische Käufe und Verkäufe, die zu einem Zeitpunkt durchgeführt wurden, als der Agent die zugehörigen Strategieereignisse noch nicht verwaltete. Daraus lässt sich nicht zuverlässig rekonstruieren, ob ein bestimmter Verkauf tatsächlich TP1, TP2 oder einer manuellen Entscheidung entsprach.
Die ursprüngliche Lösung bestand teilweise darin, für bestehende Positionen einen Ausgangszustand festzulegen. Dieser Ansatz erlaubt eine kontrollierte Fortführung, erzeugt aber neue Anforderungen an die spätere Abstimmung mit den tatsächlichen Transaktionen. Eine Baseline darf nicht bei jeder Neubewertung unbemerkt verändert werden. Ebenso dürfen bereits bekannte Verkäufe nicht nochmals als neue Reduzierungen verarbeitet werden.
Für den weiteren Ausbau ist deshalb eine transaktionsbezogene Reconciliation erforderlich. Eindeutige Buchungsreferenzen sollen mit den strategischen Ereignissen verknüpft werden können. Nicht zugeordnete Verkäufe müssen als solche erkennbar bleiben, statt automatisch einer Gewinnschwelle zugeordnet zu werden. Die Entwicklung anhand realer Positionen wie HALO, TSM und Eli Lilly zeigte, weshalb diese Unterscheidung notwendig ist.
Ein Swing-Agent muss nicht nur den aktuellen Zustand einer Position kennen. Er muss erklären können, wie dieser Zustand entstanden ist.
14. Erfolgsmessung, Backtesting und Strategievergleich
Ein Trading Agent kann technisch zuverlässig funktionieren und trotzdem eine wirtschaftlich ungeeignete Handelsstrategie abbilden. Diese Unterscheidung ist wichtig, weil gute Softwarequalität häufig mit der Qualität der daraus resultierenden Entscheidungen verwechselt wird. Die eigentliche Frage lautet deshalb nicht nur, ob eine Analyse korrekt berechnet wurde, sondern ob die verwendete Strategie über einen ausreichend langen Zeitraum einen nachvollziehbaren Mehrwert liefert.
Dafür reicht die Betrachtung einzelner erfolgreicher Positionen nicht aus. Ein hoher realisierter Gewinn bei einer Aktie sagt wenig darüber aus, wie viele andere Trades zuvor gescheitert sind, wie lange Kapital gebunden war oder welches zwischenzeitliche Verlustrisiko eingegangen wurde.
Eine belastbare Erfolgsmessung benötigt deshalb mehrere Kennzahlen. Dazu gehören die gesamte Rendite, realisierte und unrealisierte Ergebnisse, Trefferquote, durchschnittlicher Gewinn und Verlust je Trade sowie die durchschnittliche Haltedauer. Ergänzend sind der maximale Drawdown, die Kapitalbindung und risikobereinigte Kennzahlen wichtig. Bei international gehandelten Wertpapieren müssen außerdem Währungseffekte berücksichtigt werden.
Für meine Strategie bietet sich zusätzlich der Vergleich mit einer passiven Anlage an. Wenn ein wesentlicher Teil des Portfolios aktiv verwaltet wird, muss sich die Frage stellen, ob diese Aktivität gegenüber einem breit gestreuten ETF tatsächlich einen ausreichenden zusätzlichen Ertrag erwirtschaftet. Dabei dürfen Transaktionsgebühren, Steuern und der erforderliche Zeitaufwand nicht vollständig ausgeblendet werden.
Die bisherige Implementierung verfügt über Transaktionsdaten, Portfolioinformationen, historische Analysen und Strategiezuordnungen. Daraus lassen sich bereits verschiedene Auswertungen ableiten. Eine vollständig entwickelte Backtesting- und Simulationsumgebung ist dagegen Teil des weiteren Zielbilds. Sie soll ermöglichen, Strategieprofile anhand historischer Daten durchzuspielen und die daraus resultierenden Käufe und Verkäufe unter einheitlichen Bedingungen zu vergleichen.
Ein solches Verfahren benötigt allerdings besondere Sorgfalt. Werden historische Daten verwendet, die zum damaligen Entscheidungszeitpunkt noch gar nicht verfügbar waren, entstehen unrealistisch gute Ergebnisse. Dieses Problem wird als Look-ahead Bias bezeichnet. Ähnlich problematisch ist die Auswahl von Aktien anhand ihres heutigen Erfolgs. Werden nur Unternehmen betrachtet, die bis heute überlebt haben oder besonders gut gelaufen sind, fehlt ein wesentlicher Teil des historischen Anlageuniversums.
Hinzu kommt die Gefahr der Überoptimierung. Eine Strategie mit vielen einstellbaren Parametern lässt sich häufig so lange auf vergangene Kursdaten anpassen, bis sie dort hervorragende Ergebnisse produziert. Das bedeutet jedoch nicht, dass sie auch unter künftigen Marktbedingungen funktioniert. Für die weitere Entwicklung sind deshalb getrennte Trainings- und Testzeiträume sowie Walk-Forward-Analysen sinnvoll.
Die Erfolgsmessung soll damit nicht nachträglich die Richtigkeit einzelner Entscheidungen bestätigen. Sie soll vielmehr sichtbar machen, wo die Strategie tatsächlich funktioniert und unter welchen Bedingungen sie an ihre Grenzen stößt.
15. Orchestrierung: Wie der Agent tatsächlich arbeitet
Mit zunehmender Zahl spezialisierter Komponenten wird die Frage wichtiger, in welcher Reihenfolge die einzelnen Verarbeitungsschritte ausgeführt werden. Ein Analyseergebnis ist nur dann aussagekräftig, wenn die dafür benötigten Marktdaten vorhanden und ausreichend aktuell sind. Eine Strategiebewertung setzt wiederum voraus, dass die zugehörige Position korrekt rekonstruiert wurde und die benötigten Währungsdaten verfügbar sind.
Die Verarbeitung lässt sich deshalb als Abfolge voneinander abhängiger Schritte betrachten. Zunächst werden Depottransaktionen und externe Marktdaten importiert. Anschließend erfolgt ihre Normalisierung und Zuordnung zu den internen Wertpapieridentitäten. Bei Bedarf werden Fundamentaldaten und historische Wechselkurse ergänzt. Auf dieser Grundlage können aktuelle Positionen und Portfolioinformationen berechnet werden. Erst danach sollten technische und fundamentale Analysen erfolgen.
Die Strategie-Engine verarbeitet die entstandenen Signale im Zusammenhang mit den vorhandenen Positionen und den Regeln der jeweiligen Handelsstrategie. Abschließend werden mögliche Handlungsempfehlungen mit dem Portfoliokontext und den Risikovorgaben abgeglichen.
Die bisherigen Entwicklungsstände enthalten hierfür verschiedene eigenständige Module und Skripte. Dazu gehören der Parqet-Import, die Datenbankinitialisierung, die FX-Verarbeitung, Analyse-Engines und Komponenten für den Swing-Lifecycle. Im Projekt wurden unter anderem import_parqet.py, Initialize-TradingDatabase.py und fx_resolver.py dokumentiert. Ihre konkreten Aufrufparameter und die vollständige aktuelle Modulstruktur sollten aus dem Repository übernommen werden, statt aus älteren Entwicklungsständen rekonstruiert zu werden.
Mit einer späteren Orchestrierungsphase wurde außerdem ein lesender Ablauf zur Zusammenführung von Portfolio- und Analyseinformationen entwickelt. Dabei ist zwischen einer orchestrierten Analyse und einer vollständigen Automatisierung zu unterscheiden. Ein lesender Orchestrator kann Informationen aus verschiedenen Komponenten zusammenführen, ohne den Bestand zu verändern. Ein schreibender Ablauf muss dagegen zusätzliche Sicherheitsmechanismen berücksichtigen, etwa Datenbanktransaktionen, Wiederholbarkeit und den Umgang mit abgebrochenen Verarbeitungsschritten.
Für den weiteren Ausbau soll der Agent seine Verarbeitungsschritte stärker selbst koordinieren können. Dazu gehören definierte Abhängigkeiten, regelmäßige Aktualisierungen, erneute Versuche bei temporären Fehlern und eindeutige Statusinformationen. Besonders wichtig ist die Unterscheidung zwischen einem fehlgeschlagenen Verarbeitungsschritt und einem gültigen Ergebnis, das auf unvollständigen Daten beruht.
Wenn eine Kursquelle nicht erreichbar ist, sollte der Agent nicht stillschweigend einen alten Datenbestand als aktuell behandeln. Andererseits muss ein temporärer Fehler auch nicht zwangsläufig sämtliche anderen Analysen verhindern. Die Orchestrierung benötigt deshalb klar definierte Fehlerzustände und eine Verarbeitung, die möglichst unabhängig von einzelnen Datenquellen bleibt.
Das langfristige Ziel ist ein kontrollierter Agentenzyklus, in dem Datenerhebung, Qualitätssicherung, Analyse und Strategieprüfung nachvollziehbar miteinander verbunden sind.
16. MCP: Universelle Integration ohne Bindung an ein Frontend
Eine grundlegende Anforderung an den Trading Agenten war von Anfang an, dass seine Funktionen nicht an eine bestimmte Benutzeroberfläche gebunden sein sollen. Das Model Context Protocol bietet dafür eine standardisierte Möglichkeit. Es erlaubt externen Anwendungen, definierte Werkzeuge eines Dienstes aufzurufen und strukturierte Ergebnisse entgegenzunehmen.
Für den Trading Agenten bedeutet das, dass Funktionen wie Portfolioabfragen, Positionsanalysen, Watchlist-Auswertungen oder die Abfrage von Transaktionsinformationen als eigenständige Werkzeuge bereitgestellt werden können. Im bisherigen Architekturansatz wurden dafür unter anderem MCP-Werkzeuge wie portfolio_get, position_get, transactions_get, watchlist_get und decision_save vorgesehen beziehungsweise in früheren Entwicklungsständen dokumentiert. Die genaue Verfügbarkeit jedes Werkzeugs im aktuellen Laufzeitstand ist gesondert zu verifizieren.
Der technische Vorteil einer solchen Schnittstelle besteht darin, dass externe Anwendungen die internen Datenstrukturen nicht kennen müssen. Sie übergeben definierte Parameter und erhalten ein strukturiertes Ergebnis. Ein Werkzeug zur Positionsabfrage benötigt beispielsweise eine eindeutige Wertpapieridentität. Der Agent übernimmt anschließend die Datenbankabfrage und liefert die vorhandenen Positionsinformationen zurück.
Dabei sollte die Schnittstelle keine beliebigen SQL-Befehle entgegennehmen. Stattdessen werden fest definierte Operationen bereitgestellt, deren Parameter validiert werden können. Dasselbe gilt für schreibende Funktionen. Das Speichern einer Entscheidung ist etwas anderes als das Ändern einer Transaktion oder das Auslösen eines tatsächlichen Wertpapiergeschäfts. Die MCP-Schnittstelle muss solche Unterschiede ausdrücklich berücksichtigen.
Ein weiterer Vorteil liegt in der Wiederverwendbarkeit. Unterschiedliche MCP-fähige Anwendungen können dieselben Werkzeuge aufrufen. Die eigentliche Berechnung bleibt im Trading Agenten und muss nicht für jeden Client erneut implementiert werden. Das bedeutet allerdings nicht, dass MCP automatisch für die gesamte interne Kommunikation verwendet werden sollte. Zwischen lokalen Python-Modulen und einer SQLite-Datenbank kann ein direkter Funktions- oder Datenbankzugriff sinnvoller sein als ein zusätzlicher Protokoll- oder Netzwerkaufruf.
MCP bildet in dieser Architektur vor allem die Integrationsgrenze nach außen. Damit bleibt der Trading Agent ein eigenständiger Dienst mit klar definierter Fachlogik. Seine Fähigkeiten können von unterschiedlichen Systemen genutzt werden, ohne dass seine Handelsregeln, Datenbankstruktur oder Analyseverfahren von deren jeweiliger Oberfläche abhängen.
17. Qualitätssicherung, Tests und kontrollierte Weiterentwicklung
Bei einem Trading-System können Berechnungsfehler unmittelbare finanzielle Folgen haben, wenn ihre Ergebnisse für tatsächliche Anlageentscheidungen verwendet werden. Das macht eine systematische Qualitätssicherung notwendig. Im bisherigen Entwicklungsverlauf ist die automatisierte Testsuite schrittweise gewachsen. Frühere Ausbaustufen umfassten zunächst elf, später 36, 44 und 58 Tests. Mit zusätzlichen Komponenten und Regressionstests erhöhte sich der Umfang weiter. Am 28. September 2026 wurde ein Stand mit 240 erfolgreich durchlaufenen Tests dokumentiert.
Solche Regressionstests sind besonders wichtig, weil Änderungen an einer einzelnen Komponente unerwartete Auswirkungen auf andere Bereiche haben können. Eine Anpassung der Währungsumrechnung beeinflusst beispielsweise die Bewertung von Positionen. Eine Änderung der Transaktionsverarbeitung kann wiederum Auswirkungen auf Einstandskurse oder strategische Zustände haben.
Auch Datenbankschemaänderungen benötigen kontrollierte Verfahren. Eine Migration darf vorhandene Informationen nicht stillschweigend verlieren oder ihre Bedeutung verändern. Deshalb müssen Schema-Versionen erkannt, erwartete Tabellen und Spalten überprüft und Änderungen möglichst reproduzierbar ausgeführt werden. Für die Entwicklung sind isolierte Testdatenbanken sinnvoll, damit automatisierte Tests keine produktiven Depotinformationen verändern.
Ergänzend wurden Dry-Run-Verfahren verwendet. Dabei kann eine Verarbeitung zunächst geprüft werden, ohne ihre Änderungen dauerhaft in den produktiven Datenbestand zu übernehmen. Der Nutzen solcher Prüfungen liegt vor allem darin, mögliche Auswirkungen sichtbar zu machen. Ein Dry-Run ersetzt allerdings keine fachliche Validierung der verwendeten Regeln.
Ein fehlerfrei ausgeführtes Programm kann weiterhin eine wirtschaftlich unsinnige Empfehlung erzeugen. Umgekehrt kann eine fachlich plausible Empfehlung auf unvollständigen oder veralteten Eingangsdaten beruhen. Die Qualitätssicherung muss deshalb mehrere Ebenen umfassen: korrekte Programmausführung, konsistente Daten, fachlich richtige Berechnungen und nachvollziehbare Entscheidungsgrundlagen.
Git dient dabei zur Versionierung der Änderungen. Einzelne Entwicklungsstände lassen sich nachvollziehen, vergleichen und bei Bedarf wiederherstellen. Der dokumentierte Commit zur Vereinheitlichung der Datenbankpfade ist ein gutes Beispiel dafür, dass Qualitätssicherung nicht nur durch zusätzliche Tests entsteht. Sie erfordert auch eine Architektur, die Fehlerquellen möglichst früh beseitigt.
18. Probleme, Fehlentscheidungen und Erfahrungen aus der Entwicklung
Rückblickend lagen die größten Schwierigkeiten des Projekts nicht bei der Integration eines bestimmten Python-Pakets oder der Berechnung einzelner Kennzahlen. Die eigentlichen Probleme entstanden an den Grenzen zwischen Datenquellen, fachlichen Modellen und der Interpretation historischer Informationen.
Ein typisches Beispiel waren die Fundamentaldaten. Die ersten Auswertungen konnten fehlende oder unvollständige Unternehmensinformationen nicht in jedem Fall ausreichend unterscheiden. Dadurch bestand die Gefahr, dass aus unvollständigen Quelldaten scheinbar vollständige Bewertungen entstanden. Die Ursache lag weniger in der Berechnungslogik als in den Erwartungen an die Datenquellen. Unternehmensberichte sind nicht so einheitlich aufgebaut, wie es die spätere Verarbeitung wünschenswert erscheinen lässt. Die Erweiterung der SEC-XBRL-Zuordnungen und die systematischere Datenqualitätsprüfung waren deshalb notwendige Korrekturen.
Ein zweiter Problembereich betraf die Währungsumrechnung. Sobald Positionen in unterschiedlichen Währungen gehandelt und in Euro bewertet werden, können kleine Unterschiede bei Referenzkursen, Handelszeitpunkten oder Rundungsverfahren das Ergebnis beeinflussen. Die Einführung einer eigenständigen FX-Komponente und die nachträgliche Prüfung historischer Wechselkurse verbesserten hier die Nachvollziehbarkeit.
Ein dritter Bereich war die technische Verwaltung der Datenbankpfade. Unterschiedliche Annahmen darüber, wo sich die produktive Datenbank befindet, sind bei einzelnen Skripten zunächst leicht zu übersehen. Mit wachsendem Funktionsumfang wird daraus ein ernstes Problem. Ein Modul kann mit einer Testdatenbank arbeiten, während ein anderes die produktive Datenbank verwendet. Beide liefern möglicherweise plausible Ergebnisse, die sich aber nicht auf denselben Datenbestand beziehen. Die spätere Vereinheitlichung der Pfadparameter war deshalb eine notwendige strukturelle Änderung.
Besonders aufschlussreich waren die Schwierigkeiten mit historischen Swing-Positionen. Die ursprüngliche Depotverwaltung kannte Transaktionen und Bestände. Die später eingeführte Lifecycle-Verarbeitung benötigte zusätzlich Informationen darüber, welche strategischen Entscheidungen zu diesen Transaktionen geführt hatten. Diese Informationen waren historisch nicht immer vorhanden. Damit entstand ein grundsätzliches Problem: Ein technisches System kann fehlende historische Absichten nicht nachträglich zuverlässig rekonstruieren, nur weil die ausgeführten Transaktionen bekannt sind.
Die Konsequenz war eine stärkere Trennung zwischen belegten Transaktionsdaten und ihrer strategischen Zuordnung. Für bestehende Positionen wurden Ausgangszustände benötigt, die eine kontrollierte Weiterführung erlauben, ohne die Vergangenheit künstlich zu vervollständigen.
Ein weiterer Lernpunkt betraf die Berücksichtigung des Portfoliokontexts. Eine Aktie lässt sich isoliert analysieren. Ob sie zusätzlich gekauft werden sollte, hängt aber auch von bestehenden Positionen, Risikokonzentrationen und verfügbarem Kapital ab. Dabei wurde deutlich, dass der aktuelle Cash-Bestand nicht in jedem Fall die tatsächliche Kapitalverfügbarkeit vollständig beschreibt. Die Möglichkeit, externes Kapital zuzuführen, muss deshalb als eigene Information in das Entscheidungsmodell eingehen. Sie darf weder stillschweigend vorausgesetzt noch ignoriert werden.
Viele dieser Schwierigkeiten hätten sich durch eine umfassendere Modellierung zu Projektbeginn teilweise vermeiden lassen. Allerdings wäre es ebenso unrealistisch, sämtliche Anforderungen bereits in der ersten Entwicklungsphase vollständig vorherzusehen. Ein erheblicher Teil der fachlichen Komplexität wurde erst sichtbar, als reale Transaktionen, laufende Positionen und konkrete Handelsentscheidungen zusammengeführt wurden.
Die wichtigste technische Erfahrung lautet deshalb, dass ein belastbarer Trading Agent nicht allein aus Berechnungsfunktionen entsteht. Er benötigt eindeutige Datenmodelle, kontrollierte Zustandsübergänge und die Fähigkeit, Unsicherheit ausdrücklich darzustellen.
19. Aktueller Entwicklungsstand und technisches Zielbild
Der Trading Agent hat inzwischen mehrere wesentliche Entwicklungsphasen durchlaufen. Die dokumentierte Implementierung umfasst eine zentrale SQLite-Datenbank, die Verarbeitung von Depottransaktionen, Marktdaten und Fundamentaldaten, Analyse- und Strategiekomponenten sowie eine FX-Engine. Hinzu kommen Funktionen zur Verwaltung von Swing-Kampagnen und zur Zuordnung einzelner Positionen zu unterschiedlichen Anlageansätzen. Die vorhandenen Tests und die versionierte Entwicklung bilden eine Grundlage für die weitere technische Arbeit.
Gleichzeitig sind mehrere Teile des angestrebten Gesamtsystems noch nicht vollständig abgeschlossen oder anhand des zuletzt dokumentierten Repository-Stands nicht abschließend verifiziert. Dazu gehört insbesondere eine allgemein konfigurierbare Strategie-Engine. Die bisherige Implementierung orientiert sich an konkreten Handelsregeln und unterstützt bereits unterschiedliche strategische Zustände. Künftig sollen daraus unabhängige Strategieprofile entstehen, die ohne Programmänderungen angepasst und für verschiedene Swing-Trading-Methoden verwendet werden können.
Ein zweiter Schwerpunkt ist die vollständige Abstimmung zwischen tatsächlichen Depottransaktionen und der strategischen Verwaltung laufender Positionen. Historische Buchungen, manuelle Teilverkäufe, Nachkäufe und bestehende Baselines müssen eindeutig miteinander verbunden werden können. Dabei darf die Verarbeitung weder historische Ereignisse erfinden noch bereits bekannte Transaktionen mehrfach berücksichtigen.
Ein dritter Bereich betrifft das Risikomanagement. Die bestehende Analyse soll stärker mit Portfolioquoten, Konzentrationsrisiken, Positionsgrößen und der tatsächlichen Kapitalverfügbarkeit verbunden werden. Ergänzend soll die Erfolgsmessung ausgebaut werden. Die spätere Backtesting-Umgebung wird eine wichtige Voraussetzung sein, um verschiedene Strategieprofile unter vergleichbaren Bedingungen zu bewerten.
Auch die Orchestrierung soll weiterentwickelt werden. Das Ziel ist eine kontrollierte Verarbeitungskette, die Datenimporte, Qualitätssicherung, Analyse und Strategieauswertung zuverlässig miteinander verbindet. MCP bleibt dabei die externe Integrationsschnittstelle. Die eigentliche Handelslogik, Datenhaltung und Verarbeitung bleiben unabhängig vom verwendeten Client. Langfristig soll daraus ein System entstehen, das nicht nur meine persönliche Swing-Strategie verwaltet, sondern unterschiedliche regelbasierte Handelsmethoden analysieren und vergleichen kann.
Der Weg dorthin besteht allerdings nicht einfach darin, zusätzliche Indikatoren oder Funktionen einzubauen. Entscheidend ist die weitere Konsolidierung der vorhandenen Architektur. Eine allgemeine Strategie-Engine setzt beispielsweise voraus, dass Handelsregeln eindeutig beschrieben und versioniert werden können. Ein belastbares Backtesting benötigt vollständige historische Daten und klar definierte Transaktionsmodelle. Eine automatisierte Orchestrierung benötigt wiederum zuverlässige Fehlerzustände und wiederholbare Verarbeitungsschritte. Die einzelnen Erweiterungen hängen deshalb stärker miteinander zusammen, als es eine reine Funktionsliste zunächst vermuten lässt.
20. Fazit: Zwischen persönlichem Werkzeug und universeller Trading-Plattform
Die Entwicklung meines lokalen Trading Agenten begann mit einer vergleichsweise einfachen Überlegung: Wenn alle relevanten Informationen über mein Portfolio, die Unternehmen und meine Handelsregeln zusammengeführt werden, müssten sich Anlageentscheidungen systematischer vorbereiten lassen. Diese Überlegung hat sich grundsätzlich bestätigt. Allerdings zeigte sich, dass der technische Aufwand weniger in den eigentlichen Berechnungen liegt als in der korrekten Abbildung der Zusammenhänge.
Ein Börsenkurs ist schnell abgefragt, eine Kennzahl meist ebenso schnell berechnet. Wesentlich schwieriger ist es, die Daten auf ihren fachlichen Zusammenhang zu prüfen, historische Veränderungen korrekt einzuordnen und daraus eine Entscheidung abzuleiten, die auch Wochen später noch nachvollziehbar bleibt. Besonders die Verwaltung von Swing-Positionen hat gezeigt, wie eng Handelsmethodik und Softwarearchitektur miteinander verbunden sind. Sobald Teilverkäufe, Nachkäufe und unterschiedliche Strategieversionen berücksichtigt werden, genügt eine einfache Tabelle mit Stückzahl und Einstandskurs nicht mehr.
Die zusätzliche Komplexität ist dabei nicht zwangsläufig ein Nachteil. Sie bildet vielmehr Sachverhalte ab, die beim manuellen Trading ebenfalls existieren, dort aber häufig nur im Gedächtnis oder in informellen Notizen verwaltet werden. Der Agent zwingt mich dazu, meine eigenen Handelsregeln eindeutiger zu formulieren. Wann ist ein Einstieg gerechtfertigt? Unter welchen Bedingungen wird nachgekauft? Wann ist eine Gewinnmitnahme vorgesehen? Welche Rolle spielt die verbleibende Position? Und wie verändert sich eine Entscheidung, wenn das Portfolio bereits stark in einem bestimmten Sektor investiert ist?
Solche Fragen lassen sich nicht allein durch zusätzliche Marktdaten beantworten. Sie erfordern eine klar beschriebene Strategie und eine technische Umsetzung, die diese Strategie konsistent anwendet. Gleichzeitig hat die Entwicklung gezeigt, dass eine einzelne persönliche Handelsmethodik nicht dauerhaft die Grenzen des gesamten Systems bestimmen sollte.
Mit einer künftig frei konfigurierbaren Strategie-Engine sollen unterschiedliche Ansätze abgebildet und unter vergleichbaren Bedingungen untersucht werden können. Meine bisherige Momentum-orientierte Swing-Strategie bleibt dabei der Ausgangspunkt, wird aber zu einem von mehreren möglichen Strategieprofilen. Ob diese Erweiterung später zu besseren Anlageergebnissen führt, ist eine offene Frage. Sie muss anhand nachvollziehbarer historischer und zukünftiger Ergebnisse beantwortet werden, nicht anhand der Zahl implementierter Funktionen oder der Komplexität des Programmcodes.
Der technische Wert des Trading Agenten liegt bereits heute darin, Daten, Analysen, Handelsregeln und Positionszustände in einem gemeinsamen System zusammenzuführen. Das eigentliche Ziel reicht jedoch weiter: Entscheidungen sollen nicht nur vorbereitet, sondern auch in ihrem Zustandekommen nachvollziehbar und über längere Zeiträume überprüfbar werden.
Dabei bleibt eine Grenze bewusst bestehen. Der Agent kann Informationen strukturieren, Regeln auswerten und auf Risiken hinweisen. Er kann aber weder zukünftige Kursbewegungen zuverlässig vorhersagen noch die Verantwortung für die eingesetzten Mittel übernehmen. Ein erfolgreicher Trading Agent ist deshalb nicht derjenige, der möglichst viele Kaufempfehlungen erzeugt. Entscheidend ist vielmehr, ob seine Daten belastbar, seine Regeln eindeutig, seine Berechnungen reproduzierbar und seine Grenzen erkennbar sind.
Aus einem Werkzeug zur Unterstützung meiner eigenen Handelsentscheidungen ist damit schrittweise eine eigenständige technische Plattform geworden. Noch ist nicht jede angestrebte Funktion umgesetzt. Aber die bisherige Entwicklung hat gezeigt, wo die eigentlichen Herausforderungen liegen und welche Voraussetzungen für den weiteren Ausbau geschaffen werden müssen.
Gerade diese Erfahrungen sind für mich der interessanteste Teil des Projekts. Nicht die Vorstellung, dass Software den Aktienmarkt irgendwann vollständig verstehen könnte, sondern die wesentlich konkretere Aufgabe, aus einer persönlichen Handelsmethodik ein technisch sauberes, überprüfbares und dauerhaft erweiterbares System zu machen.
Quellen und technische Referenzen
Die Architektur und die geschilderten Entwicklungserfahrungen beziehen sich auf mein eigenes Trading-Agent-Projekt. Ergänzend sind folgende Dokumentationen relevant:
Model Context Protocol (MCP)
Offizielle Spezifikation des Protokolls, einschließlich der Bereitstellung von Tools, Parameterdefinitionen und der Kommunikation zwischen Clients und Servern.
https://modelcontextprotocol.io/specification/2026-07-28/server/tools
SQLite – Dokumentation
Technische Referenz zur verwendeten relationalen Datenbank, einschließlich Transaktionen, Indizes, Constraints und konkurrierender Zugriffe.
https://www.sqlite.org/docs.html
SQLite – Transaktionen
Beschreibung der Transaktionsverarbeitung und des Verhaltens bei Commit und Rollback.
https://www.sqlite.org/lang_transaction.html
U.S. Securities and Exchange Commission (SEC)
Offizielle Dokumentation der EDGAR-Schnittstellen und der über XBRL bereitgestellten Unternehmensinformationen.
https://www.sec.gov/search-filings/edgar-application-programming-interfaces
Europäische Zentralbank (EZB)
Offizielle Euro-Referenzwechselkurse als Grundlage für die historische Umrechnung und Bewertung international gehandelter Wertpapiere.
https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html
Parqet – CSV-Export
Beschreibung der Exportmöglichkeiten für Transaktionen und Portfoliodaten.
https://parqet.com/de/blog/export
Python – Dokumentation
Referenz der eingesetzten Programmiersprache und ihrer Standardbibliothek, einschließlich SQLite-Anbindung.
https://docs.python.org/3/
Git – Dokumentation
Technische Referenz zur Versionierung, Commit-Verwaltung und Nachvollziehbarkeit von Änderungen.
https://git-scm.com/doc
GitHub – Trading Agent
Quellcode, Entwicklungsstände und Regressionstests des beschriebenen Projekts.
GitHub – robertbackhaus-a11y/KI-Trading-Agent: Local trading agent
Technischer Stand: Der Artikel beschreibt die bis zum 8. Oktober 2026 dokumentierten Entwicklungsstände. Der zuletzt bestätigte vollständige Regressionstest mit 240 erfolgreichen Tests stammt vom 28. September 2026. Die frei konfigurierbare Strategie-Engine, ein umfassendes Backtesting und die vollständige Automatisierung sämtlicher Agentenzyklen werden als Zielbild behandelt und nicht als bereits abgeschlossene Implementierung dargestellt.