Stand: 24. Oktober 2026 · Aktualisierte Fassung des Beitrags „Lokaler Trading Agent: Vom persönlichen Trading-Ansatz zur eigenständigen Analyseplattform“
Hinweis: Dieser Beitrag beschreibt eine privat betriebene Analyseplattform und die technischen Überlegungen hinter ihr. Er ist keine Anlageberatung, keine Aufforderung zum Kauf oder Verkauf und kein Nachweis einer Handelsrendite. VIPER-AI analysiert und simuliert; es führt keine Börsenorders aus.
Aus einer zunächst überschaubaren Depotanalyse ist über mehrere Ausbaustufen VIPER-AI entstanden: eine lokal betriebene Plattform, die Portfolio- und Transaktionsdaten, Markt- und Fundamentaldaten, feste Risikoregeln sowie eine KI-gestützte Analyseoberfläche verbindet. Ihr Ziel ist nicht, Anlageentscheidungen zu automatisieren, sondern sie nachvollziehbar vorzubereiten.
Das ist ein wichtiger Unterschied. Ein Kurs, ein Kennzahlen-Score oder die Antwort eines Sprachmodells sind für sich genommen keine belastbare Entscheidung. Erst der Abgleich mit Datenqualität, bestehender Position, Portfolio-Risiko, Investmentthese und klaren Grenzen macht aus einzelnen Informationen eine brauchbare Entscheidungsgrundlage.
Vom Trading-Skript zur lokalen Analyseplattform
Der Ausgangspunkt war ein persönliches Problem: Transaktionen liegen beim Broker, Bewertungen und Kennzahlen an verschiedenen Stellen, und eine einzelne Kursbewegung erklärt noch nicht, ob eine Position gehalten, reduziert oder neu bewertet werden sollte. Besonders bei einer Core-Satellite-Strategie treffen zwei unterschiedliche Anlagehorizonte aufeinander: langfristige, breit gestreute ETF-Anteile und aktiv verwaltete Einzelaktienpositionen.
Die zugrunde liegenden Regeln sind bewusst als persönliche Konfiguration zu verstehen, nicht als allgemeingültige Empfehlung. Dazu gehören Zielkorridore für langfristige und aktiv verwaltete Anteile, Positionsgrößen, Gewinnmitnahmen und der Umgang mit Nachkäufen. VIPER-AI soll diese Regeln nicht verstecken, sondern sie in der Portfoliobetrachtung sichtbar machen.
Die erste Version bestand im Wesentlichen aus Python-Skripten und einer SQLite-Datenbank. Mit zunehmender Zahl an Datenquellen und Zuständen reichte das nicht mehr aus. Transaktionsimporte mussten idempotent werden, historische Wechselkurse korrekt auf Bewertungszeitpunkte bezogen werden und eine Teilgewinnmitnahme durfte nicht bei jeder erneuten Analyse als neuer Verkaufsvorschlag erscheinen.
Heute ist VIPER-AI ein eigenständiges Python-Paket für den lokalen Einzelnutzerbetrieb unter Windows und Linux. Die Python-Engine bleibt die fachliche Quelle für Berechnungen und Regeln. Das lokale Webfrontend macht diese Ergebnisse zugänglich; MCP und ein lokales Sprachmodell ergänzen sie um Schnittstellen und nachvollziehbare Einordnung.
Abbildung 1: Das lokale Dashboard fasst Depotwert, Entwicklung, Allokation und Positionen zusammen. Der Screenshot zeigt ausschließlich fiktive Demodaten aus dem Repository.
Eine Architektur mit klaren Zuständigkeiten
VIPER-AI ist absichtlich keine Sammlung autonomer Teilagenten. Die Architektur trennt drei Aufgabenbereiche:
- Die deterministische Trading-Engine verarbeitet Transaktionen, Preise, Wechselkurse, Datenqualität, Strategie- und Risikoregeln.
- Die Reasoning-Schicht ordnet Ergebnisse ein, formuliert These und Gegenthese und macht Unsicherheit sichtbar.
- Die lokale Webplattform führt Portfolio, Analysen, Aufgaben und Einstellungen in einer Benutzeroberfläche zusammen.
Die Engine arbeitet mit einer lokalen SQLite-Datenbank. Sie verwaltet unter anderem Wertpapiere, Transaktionen, Positionen, tägliche Marktdaten, Fundamentaldaten, Wechselkurse, Strategiezustände und ETF-Durchschau. Die Web-API basiert auf FastAPI und berechnet keine eigenen Kennzahlen: Sie stellt die Ergebnisse der Engine dar. Dadurch bleibt die fachliche Wahrheit an einer Stelle.
Lokaler Browser
│
▼
Web-Frontend ────── FastAPI / API ────── Python-Trading-Engine
│ │
│ Kurse · FX · Portfolio · Risiko
│ │
└──── Intelligence / Reasoning ◄──────────┤
│ │
lokales LLM SQLite-DatenbestandDie frühere Qt-Oberfläche wurde im Code vollständig durch das Webfrontend ersetzt. Das ist kein zweites Produkt neben der vorhandenen Engine: Wiederverwendbare View-Modelle und Dienste wurden übernommen, während Darstellung und API neu strukturiert wurden. VIPER startet lokal im Browser; die Daten bleiben auf dem eigenen System.
Daten sind nur so gut wie ihre Herkunft und ihr Zeitpunkt
Die schwerste Arbeit in einem solchen System ist selten die Formel eines Indikators. Schwieriger sind eindeutige Wertpapieridentitäten, der richtige Handelsplatz, historische Wechselkurse, Berichtsperioden und die Frage, ob eine Kennzahl zum betrachteten Zeitpunkt überhaupt verfügbar war.
VIPER-AI trennt deshalb Wertpapieridentitäten von quellspezifischen Symbolen. Ein Ticker allein ist nicht zuverlässig genug: Er kann sich ändern, an mehreren Börsen vorkommen oder unterschiedliche Währungen repräsentieren. Transaktionen bleiben historische Fakten; Positionen werden daraus abgeleitet. Eine Strategiezuordnung und ein Analysefall sind wiederum eigene Zustände, nicht bloß Eigenschaften einer Buchung.
Bei Fundamentals ist der Kontext ebenso wichtig. Freier Cashflow entsteht beispielsweise nicht dadurch, dass irgendein Zahlenfeld so heißt, sondern aus operativem Cashflow minus tatsächlich passenden Investitionsausgaben. Unterschiedliche XBRL-Tags und unvollständige Daten können diese Berechnung verfälschen. Fehlt eine Eingabe, behandelt VIPER sie nicht stillschweigend als Null, sondern als Datenlücke.
Auch bei historischen Aussagen gilt ein strenger Zeitbezug. Ein Kurs oder Fundamentaldatum darf eine Entscheidung von früher nicht nachträglich besser aussehen lassen. Für Fundamentals ohne bestätigtes Veröffentlichungsdatum ist die Aussagekraft begrenzt; sie werden nur unter dokumentierten Bedingungen sichtbar und höchstens als teilweise vollständig bewertet.
Diese Vorsicht ist keine Nebensache. Sie verhindert, dass ein technisch sauber aussehender Wert mit einer Scheingenauigkeit verwechselt wird.
Portfolio, Risikogrenzen und die ETF-Durchschau
Der Portfolio-Blick reicht weiter als die Frage, ob eine einzelne Aktie attraktiv wirkt. Eine neue oder vergrößerte Position muss auch zu Kapitalbindung, Sektorverteilung und bereits vorhandenem wirtschaftlichem Einzelwertrisiko passen.
Die Engine enthält dafür konkrete Guardrails. Im dokumentierten Standard gehören dazu:
| Konfiguration | Dokumentierter Rahmen |
|---|---|
| Langfristiger Portfolioanteil | 60–70 % |
| Aktiv verwalteter Swing-Anteil | 30–40 % |
| Maximalgewicht eines Einzelwerts | 20 % |
| Maximale anfängliche Swing-Position | 10 % |
| Maximaler Nachkauf relativ zur Originalposition | 25 % |
| Maximale Zahl von Nachkäufen | 1 |
Solche Werte sind programmierte Vorgaben für dieses private System, keine Anlageempfehlung. Ihre Stärke liegt darin, dass sie bei einer Analyse überprüfbar werden. Eine gute Einzelidee kann trotzdem ungeeignet sein, wenn sie ein bestehendes Risiko weiter konzentriert.
Besonders relevant ist die ETF-Durchschau. Ein Depot kann eine Aktie direkt halten und zugleich über einen ETF wirtschaftlich an demselben Unternehmen beteiligt sein. Die Sektorenansicht verbindet deshalb ETF-Bestände mit direkten Aktienpositionen und weist das effektive Einzelwertrisiko getrennt aus.
Abbildung 2: Die Sektorenansicht ergänzt direkte Positionen um ETF-Anteile. Der Screenshot enthält fiktive Demodaten.
Der Portfolio Action Planner verbindet diese Grenzen mit konkreten Vorschlägen: Welche Positionen erfordern Aufmerksamkeit? Wie viel Kaufkapazität bleibt nach Risikoregeln? Passt ein potenzieller Einstieg zum bestehenden Depot oder wird er zurückgestellt? Damit bleibt eine Handlungsempfehlung an ihren Portfolio-Kontext gebunden.
Abbildung 3: Der Planner fasst mögliche Aktionen und begrenzende Faktoren zusammen; er führt keine Transaktionen aus. Fiktive Demodaten.
Der KI-Teil: Interpretation statt Entscheidungsmacht
Ein Sprachmodell darf in einem Trading-System nicht zur versteckten Regel- oder Ausführungsinstanz werden. In VIPER-AI bleiben Berechnungen, strategische Entscheidungen und Schreibvorgänge Aufgabe der Python-Komponenten. Das lokale Modell interpretiert Daten, bildet Hypothesen, formuliert Gegenargumente und begründet einen Vorschlag. Eine Börsenorder wird weder vom Modell noch von VIPER-AI ausgelöst.
Der implementierte Workflow wird mit LangGraph gesteuert und ist auf einen einzelnen Analysefall je Wertpapier ausgelegt:
Beobachten
→ Datenlage prüfen
→ quantitative und qualitative Analyse
→ These und Gegenthese
→ Belege und Datenlücken prüfen
→ Risiko- und Portfolio-Kontext
→ überprüfter Handlungsvorschlag
→ Analyse speichern / bei neuen Informationen neu bewertenAnalysefälle, Protokolle und Checkpoints werden gespeichert. Bricht ein Modelllauf ab, kann der Workflow an einem Checkpoint wieder aufgenommen werden. Ein Fingerabdruck der Eingangsdaten erlaubt eine gezielte Neubewertung, wenn sich Preise, Nachrichten oder die Position verändern.
Das ist ein wesentlicher Fortschritt gegenüber einer Chat-Antwort ohne Kontext: Eine Aussage bleibt mit ihrem Datenstand, ihren Belegen, ihren Annahmen und ihren Gegenargumenten verknüpft. Sie wird dadurch nicht automatisch richtig, aber überprüfbar.
Wichtig ist die Grenze des aktuellen Nachweises. Die Reasoning-Orchestrierung wurde technisch getestet, einschließlich Abbruch und Wiederaufnahme auf einer Kopie der Produktionsdatenbank. Ein dokumentierter Lauf mit dem tatsächlichen lokalen Ollama-Modell stand bei der ursprünglichen Abnahme noch aus, weil Ollama während der Umsetzung nicht erreichbar war. Daraus folgt: Der Workflow ist implementiert; eine belastbare Aussage über die Qualität realer Modellanalysen wäre verfrüht.
Abbildung 4: Das Intelligence-Cockpit zeigt Analysefälle, Belege, Annahmen und Vorschläge. Fiktive Demodaten.
Von der Watchlist zur Opportunity View
Eine Watchlist ist nur eine Ausgangsliste. VIPER-AI erweitert sie um Candidate Discovery, Market Intelligence und eine einheitliche Opportunity View. Das Ziel ist nicht ein weiterer undurchsichtiger Gesamtscore. Vielmehr werden die vorhandenen Ergebnisse sichtbar zusammengeführt:
- Fundamentale und technische Befunde eines Unternehmens,
- relevante Ereignisse und Nachrichten,
- der aktuelle Status als Kandidat,
- Vorschläge des Portfolio Planners und
- der Fit zum vorhandenen Depot.
So lässt sich eine konkrete Frage besser beantworten: Warum ist ein Wert interessant? Welche Daten sprechen dafür, was spricht dagegen, und würde eine zusätzliche Position das Portfolio sinnvoll ergänzen? Die fachliche Auswertung bleibt dabei in ihren jeweiligen Komponenten; die Opportunity View dient als gemeinsame Entscheidungssicht.
Eine nutzbare Oberfläche braucht auch vollständige Historie
Das Webfrontend bietet Depotwert- und Renditeverläufe für 1 Monat, 3 Monate, 6 Monate, 1 Jahr, 3 Jahre, 5 Jahre und MAX. Die Rendite wird, soweit die Daten es erlauben, zeitgewichtet berechnet. Nettozuflüsse, Verkäufe und Dividenden werden von der täglichen Wertentwicklung getrennt, bevor Tagesrenditen verkettet werden.
Das ist sorgfältiger als eine einfache Gegenüberstellung von Einstand und aktuellem Wert, hat aber eine notwendige Einschränkung: Jeder Tag benötigt eine vollständige Bewertung aller gehaltenen Positionen, inklusive gültiger historischer Kurse und Wechselkurse. Fehlt ein Wert, ist die Rendite für den betroffenen Zeitraum nicht berechenbar. MAX beginnt deshalb erst am ersten vollständig bewertbaren Tag.
Der Code und die Weboberfläche für diese Historie sind umgesetzt. In der Produktion war zum dokumentierten Stand ein einmaliger EZB-Backfill für ältere Wechselkurse noch offen. Eine sichtbare Zeitachse darf daher nicht als Beleg für eine lückenlose historische Datenbasis verstanden werden.
Aufgabenverwaltung: VIPER definiert, das Betriebssystem plant
Marktdaten, Wechselkurse und Fundamentaldaten bleiben nicht von selbst aktuell. VIPER-AI dokumentiert sieben Aufgaben für die Datenversorgung und Verarbeitung:
| Aufgabe | Zweck | Standardzeitplan |
|---|---|---|
| MarketData-Backfill | Marktpreise aktualisieren | täglich 17:15 |
| FXRates-Backfill | EZB-Wechselkurse aktualisieren | täglich 17:20 |
| EventsNews-Backfill | SEC-Ereignisse und Nachrichten | täglich 17:25 |
| Fundamentals-SEC | Unternehmens-Fundamentaldaten | sonntags 10:00 |
| Candidate-Discovery | Kandidaten erkennen | täglich 17:35 |
| Market-Intelligence | Marktsignale und Einordnung | täglich 08:15 und 17:45 |
| ETF-Refresh | ETF-Bestände und Sektorinformationen | sonntags 11:00 |
VIPER hält die Definitionen dieser Aufgaben und kann sie anzeigen, bearbeiten, aktivieren, löschen, wiederherstellen oder manuell anstoßen. Die zeitgesteuerte Ausführung übernimmt bewusst nicht die Webanwendung selbst: Unter Windows werden die Definitionen in die Aufgabenplanung übertragen, unter Linux in systemd-Benutzer-Timer. So gibt es keine zweite, konkurrierende Scheduler-Wahrheit in einer zusätzlichen Anwendungsschicht.
Der Zeitpunkt ist hier wichtig: Auf main ist die OS-basierte Aufgabenverwaltung implementiert; der zuvor eingeführte APScheduler wurde wieder entfernt. Die dokumentierte Produktion lief am 24. Oktober nach dem Web-Cutover noch mit der zwischenzeitlichen integrierten Scheduler-Version. Der nächste Produktionsupdate soll die sieben OS-Aufgaben mit viper-ai tasks deploy wieder aktivieren. Das ist kein Funktionsdefizit des Quellstands, aber ein offener produktiver Cutover.
Abbildung 5: Die Aufgabenansicht verbindet VIPER-Definitionen mit dem Zustand des Betriebssystem-Schedulers. Fiktive Demodaten.
MCP, lokale Modelle und Installation
Neben der Weboberfläche stellt VIPER-AI Funktionen über einen MCP-Server bereit. Dabei ist die Werkzeugauswahl serverseitig abgesichert: Das Standardprofil stellt 17 reine Lese-Werkzeuge bereit; das GUI-Profil ergänzt gezielte Aktionen, während das bewusste Admin-Profil sämtliche 27 Werkzeuge einschließlich administrativer Funktionen sichtbar machen kann. Ein Client kann diese Grenze nicht eigenmächtig erweitern.
Auch der lokale Chat im Web arbeitet nur mit dem Leseprofil. Er kann Ergebnisse abfragen und einordnen, aber nicht stillschweigend eine Transaktion importieren, eine Strategie ändern oder Datenbankbefehle ausführen.
Die Installation erfolgt als Python-Paket mit einer gemeinsamen lokalen Laufzeitumgebung. Startpunkte wie viper-ai start, viper-ai-web, viper-ai-mcp und viper-ai tasks machen Weboberfläche, MCP und Aufgabenverwaltung bedienbar. Laufzeitdaten wie Datenbank, Logs und private ETF-Dateien liegen bewusst außerhalb des Pakets: Ein Update oder eine Deinstallation darf sie nicht verändern.
Was weiterhin offen ist
Ein technischer Entwicklungsstand ist kein Gütesiegel für die Anlagestrategie. Die offenen Punkte werden daher nicht als fehlende Marketing-Funktionen, sondern als Grenzen des Systems behandelt:
| Bereich | Heutiger Stand | Für einen vollständigen Nachweis fehlt noch |
|---|---|---|
| Strategiekonfiguration | Persönliche Regeln und Guardrails sind implementiert | Mehrere frei versionierbare Strategien ohne Codeanpassung |
| Backtesting | Kein umfassender Abschlussnachweis | Historische Simulation, Bias-Kontrolle und Strategievergleich |
| Reconciliation | Als fachliches Problem dokumentiert | Durchgängige Zuordnung von Buchungen zu Strategieereignissen |
| KI-Reasoning | Workflow implementiert und technisch geprüft | Dokumentierte Qualität mit echten lokalen Modellläufen |
| Historische Performance | Webansicht und TWR implementiert | Vollständige historische Kurs- und FX-Daten |
| Aufgaben-Cutover | OS-Backends im Repository implementiert | Produktive Umstellung vom integrierten Scheduler |
| Strategieerfolg | Auswertungsgrundlagen vorhanden | Belastbarer Vergleich mit geeigneter Benchmark |
Darüber hinaus sind manche Datenarten bewusst noch unvollständig. Beispielsweise gibt es für Analystenschätzungen, Ratings und Kursziele im derzeitigen Setup keine kostenlos verfügbare, verlässlich integrierte Quelle. Die Engine behandelt das als fehlende Informationsbasis, nicht als verstecktes negatives Signal.
Was sich aus der Entwicklung lernen lässt
Der Wechsel von einer Skriptsammlung zu einer Analyseplattform war weniger eine Folge eines einzelnen KI-Modells als eine Folge klarer Grenzen. Datenimporte müssen wiederholbar sein. Historische Fakten dürfen nicht nachträglich umgedeutet werden. Portfolio-Risiken müssen auch dann sichtbar werden, wenn sie über ETFs entstehen. Und ein LLM darf seine sprachliche Plausibilität nicht in Entscheidungsmacht verwandeln.
Die heutige Stärke von VIPER-AI liegt daher nicht in einer angeblich autonomen Handelsintelligenz, sondern in der Verbindung dreier Ebenen:
- einer deterministischen Engine für Daten, Portfolio und Regeln,
- einer Reasoning-Schicht für begründete, überprüfbare Analysefälle und
- einer lokalen Webplattform, über die sich Depot, Datenversorgung, Risiken und Empfehlungen gemeinsam betrachten lassen.
Genau diese Verbindung macht aus einem persönlichen Trading-Skript ein nachvollziehbares technisches System. Sie entbindet nicht von eigener Verantwortung – sie schafft die Voraussetzungen, diese Verantwortung mit besseren Informationen wahrzunehmen.
Quellen und technischer Stand
- VIPER-AI auf GitHub – geprüft auf Commit
708515b5d2e175351fcac0a54eed4ba0510245f8vom 24. Oktober 2026 - README
- Roadmap
- Architektur
- Webfrontend-Dokumentation
- Technische Architekturreferenz