Kann eine Claude-Code-Routine über meine Finanzen wachen?
(driggsby.com)- Durch die Verbindung von Finanzkontodaten und einem MCP-Connector lassen sich wiederkehrende Finanzprüfungen auf Basis von Kontoständen, Transaktionen, Investments und Darlehen allein per Prompt automatisieren
- Der bisherige Ansatz mit Codex-CLI-Cron-Jobs brach häufig wegen Web-Logins, Browser-Rendering-Problemen, 2FA und Passkey-Beschränkungen zusammen, sodass sich Prüfungen je Konto nur schwer stabil fortführen ließen
- Die neu aufgebaute tägliche E-Mail-Automatisierung kombiniert einen Morgenzeitplan, einen Custom Connector und das Tool
email_me(), um alle Konten und das Nettovermögen strukturiert zu versenden; auch der Inhalt lässt sich nur durch Anpassen des Prompts ändern - Die Automatisierung zur Transaktionsüberwachung erkennt ungewöhnliche Transaktionen und große Abflüsse, indem sie sie mit jüngsten Mustern vergleicht, und sendet E-Mails nur dann, wenn Bedingungen erfüllt sind, wodurch unnötige Benachrichtigungen reduziert werden
- Dieser Ansatz macht es möglich, personalisiertes operatives Automatisieren sehr kostengünstig schnell zu testen und auszubauen, und erlaubt es auch Nichtentwicklern, Finanzprüfungen mit angebundenen Echtzeitdaten direkt selbst zu nutzen
Aufbau der Automatisierung
- Driggsby verbindet sich per Plaid mit Finanzkonten und stellt dann über MCP Tools für Kontostände, Transaktionen, Investmentdaten und Darlehensdaten bereit
- Anfangs stand vor allem die interaktive Nutzung im Mittelpunkt, bei der in Claude bei Bedarf Fragen gestellt wurden, doch dabei zeigten sich wiederkehrende Muster wie Nettovermögensprüfung, Kontostandskontrolle und Transaktionsüberwachung
- Claude Code routines erleichtern es, solche wiederkehrenden Aufgaben allein per Prompt zu automatisieren
- Ohne separaten Agent-Loop-Code oder vorbereitete Deployment-Umgebung funktioniert es, wenn nur Prompt und MCP-Connector verbunden werden
- Wenn sich Daten und Tools sauber über MCP-Connectoren anbinden lassen, wird eine Automatisierungskonfiguration möglich
Grenzen des bisherigen Ansatzes und der Wechsel
- Zuvor war eine nicht interaktive Codex-CLI-Cron-Job-Lösung eingerichtet, die sich bei Bank-, Kreditkarten-, Depot- und Rentenkonten einloggte, Kontostände und aktuelle Transaktionen abrief und per E-Mail eine tägliche Finanzübersicht verschickte
- Dafür wurde Chrome DevTools MCP verwendet, um sich bei den jeweiligen Websites einzuloggen und Informationen zu extrahieren
- Es war nur die einfache Aufgabe, einem Ehepaar eine tägliche Finanzübersicht per E-Mail zu senden, in der Praxis brach sie jedoch oft zusammen
- Immer wieder scheiterte der Ablauf schon am nächsten Tag, und wegen Browser-Rendering-Problemen oder unerwarteten 2FA-Abfragen stoppte die Ausführung häufig auf Kontoebene
- Manchmal änderte GPT das E-Mail-Format komplett oder geriet während der Ausführung durcheinander und holte nur Informationen zu einem einzigen Konto
- Bei einigen neu hinzuzufügenden Konten war außerdem nur Passkey-Login erlaubt
- Wegen dieser wiederkehrenden Störungen musste jedes Mal manuell eingegriffen werden, wenn die erwartete E-Mail ausblieb, und um diesen Prozess weniger stressig zu machen, wurde Driggsby aufgebaut
Tägliche E-Mail-Automatisierung
- Als Erstes wurde die tägliche E-Mail neu aufgebaut; das Ziel war, jeden Morgen eine sauber formatierte Zusammenfassung aller Konten und des Nettovermögens zu erhalten
- Diese Informationen lagen ursprünglich in einer alten Tabelle irgendwo auf Google Drive
- Die Aktualisierung dauerte nur etwa 15 Minuten, aber schon diese kleine Reibung führte dazu, dass sie oft nicht gepflegt wurde und höchstens etwa alle sechs Monate aktualisiert wurde
- In routines war die Ersteinrichtung sehr einfach: Prompt eingeben, Zeitplan für den Morgen festlegen und den Driggsby Custom Connector verbinden
- Zunächst gab es allerdings keine Möglichkeit, E-Mails zu versenden, und nach dem Anschluss des Gmail-Connectors wurden nur gut formatierte Entwürfe erzeugt
- Der Gmail-Connector konnte nicht tatsächlich versenden, sondern nur Drafts erstellen
- Um das zu lösen, wurde Driggsby um das MCP-Tool
email_me()erweitert; das funktionierte recht komfortabel- Der Versand wurde auf verifizierte E-Mail-Adressen der Kontoinhaber beschränkt und Links sowie Bilder wurden blockiert, um das Sicherheitsniveau akzeptabel zu halten
- Der Inhalt wurde auf Markdown festgelegt, und durch zusätzliches CSS bei Markdown-gerenderten E-Mails wurden Formatabweichungen zwischen einzelnen Ausführungen reduziert
- Einige kleinere Bugs ließen sich dank der Inspectability von routines vergleichsweise leicht beheben
- Die UI sieht aus wie eine normale Claude-Code-Session in Claude Desktop oder der Web-App, wodurch sich der Status während der Ausführung leicht direkt prüfen lässt
- Nach den Tests traf die tägliche E-Mail tatsächlich ein, und danach konnten Änderungen am Inhalt auch ohne Codeanpassungen direkt in der routines-UI nur durch Anpassung des Prompts vorgenommen werden
- Da das Ehepaar unterschiedliche Punkte sehen möchte, konnten für beide unterschiedliche tägliche E-Mails mit getrennten Prompts eingerichtet werden
Überwachung ungewöhnlicher Transaktionen und Ausgaben
- Nachdem die tägliche E-Mail etabliert war, wurden weitere Automatisierungen ergänzt, weil sich Agenten ohne separate Infrastrukturbelastung starten lassen
- Zuerst wurde mit den Transaktionsdaten eine Überwachung ungewöhnlicher Transaktionen aufgebaut; in einer wöchentlich laufenden Routine wurden ein Jahr Amex-Kreditkartentransaktionen geladen, wobei der Fokus auf den letzten sieben Tagen lag
- Wenn Transaktionen der letzten sieben Tage im Vergleich zu früheren Mustern unerwartet wirkten, etwa durch Doppelabbuchungen, geänderte Abo-Gebühren oder unbekannte Händlernamen bzw. Beschreibungen, sollte eine E-Mail gesendet werden
- Wenn die Transaktionen der letzten sieben Tage normal und konsistent waren, wurde keine Benachrichtigung gesendet
- Solche einfachen Prompts können zwar False Positives erzeugen, doch die Kosten für Nachschärfung und Prüfung scheinen im Zeitverlauf gering zu sein
- Danach wurde für das Girokonto eine Routine gebaut, die unerwartet große Abflüsse überwacht
- Sie prüft nur die Transaktionen des letzten Tages und sucht im Vergleich zu Mustern der vergangenen 12 Monate nach großen oder ungewöhnlichen Abflüssen bei Transaktionen über 500 $
- Da die Automatisierung täglich läuft, wurde der Prüfbereich bewusst stark auf den letzten Tag begrenzt
- Wenn passende Posten gefunden werden, wird eine E-Mail mit dem Betreff "Checking account outflow alert" gesendet; andernfalls erfolgt keine Benachrichtigung
- Später wurde dieser Ansatz auch auf Investment-Monitoring, Abo-Analysen und die Überwachung verschiedener Ausgabenkategorien ausgeweitet
- Da sich das mit routines sehr leicht einrichten lässt, wächst mit der Zeit der Bedarf, mehrere Bedingungen zusammenzufassen oder Prompts feiner auszuarbeiten
Warum das wichtig ist
- Die zentrale Stärke von routines liegt darin, dass sie sich mit nahezu keinem Aufwand ausprobieren lassen
- Sobald ein Prompt formuliert ist, kann die Automatisierung sofort ausgeführt werden
- Besonders auffällig ist, dass auch Nichtentwickler cloudbasierte Automatisierungen mit angebundenen Live-Daten direkt selbst nutzen können
- Auch die Ehepartnerin, eine CPA, zieht Echtzeitdaten aus Driggsby und führt eigene Automatisierungen selbst aus
- Diese Art der Nutzung ermöglicht es, allein mit Prompts und Connectoren personalisierte operative Automatisierung schnell zu erstellen
1 Kommentare
Hacker-News-Kommentare
Ich habe mir kürzlich selbst etwas in dieser Art gebaut. Mit https://tiller.com/ synchronisiere ich Girokonto-/Kreditkartentransaktionen nach Google Sheets und spiegele dieses Spreadsheet dann per GitHub Actions in eine kostenlose Supabase-DB
Über Supabase MCP oder psql konnten Claude/Codex dann per englischer Abfrage auf Transaktionsverlauf und Salden zugreifen, und die Fähigkeit, Abo-Muster oder Anomalien zu finden, war ziemlich beeindruckend. Auch bei Cashflow-Prognosen, die Online-Tools oft nicht gut hinbekommen, war es ordentlich; zum Beispiel konnte ich fragen, wie viel ich in Ersparnisse verschieben kann, basierend auf monatlichen Ausgabemustern und verfügbarem Bargeld
Bei der automatischen Kategorisierung kam Claude mit einem Custom-DSL ziemlich gut zurecht. Ich habe es einen Regelsatz als Markdown-Tabelle zur Normalisierung von Empfängern/Kategorien erstellen lassen, und diese Regeln laufen ebenfalls in GitHub Actions mit
Ob es dafür so etwas wie Plaid nutzt, ob man immer noch Webbanking-Zugangsdaten übergeben muss und wie 2FA dabei gehandhabt wird
Bei Finanzinstituten ohne offizielle API frage ich mich, ob man immer noch auf Screen Scraping angewiesen ist und was passiert, wenn ein Bug zu unbeabsichtigten Klicks, Zustimmungen oder sogar Fehlüberweisungen führt. Es heißt zwar schreibgeschützt, aber bei Privatbanking habe ich kaum je gesehen, dass Banken echte schreibgeschützte Hilfskonten unterstützen
Mich würde auch interessieren, ob es Versicherungen oder Garantien gibt, damit man bei großen finanziellen Schäden entschädigt wird, und ich mache mir Sorgen über die Datenschutzfolgen davon, zwei Anbietern meine kompletten Bankdaten zu zeigen. Ich habe auch von Sammelklagen gehört, weil Daten unangemessen verkauft oder geteilt worden seien, weiß aber nicht, was dort tatsächlich passiert ist
Problematisch finde ich auch, dass in den Bankbedingungen oft steht, dass man zusichert, sein Passwort nicht mit Dritten zu teilen. Es ist mir generell unangenehm, meine Finanzen einem Web-/Cloud-Dienst anzuvertrauen; Client-Software, die lokal läuft und mit Bank-APIs spricht, wäre mir deutlich lieber. Ich frage mich, ob es so etwas in Kanada gibt
Von Open Banking ist zwar die Rede, aber es ist unklar, ob man damit auch über selbst entwickelte Software zugreifen kann. Wenn das wirklich vertrauenswürdig wäre und sogar eine Richtlinie erzwungen würde, die die interne Aufbewahrung nach dem Download minimiert, würde ich selbst Bank-APIs gerne nutzen
Ich nutze Tiller seit Mint von Intuit übernommen wurde und habe eine ähnliche Konfiguration. Ich habe allerdings lokalen qwen-Modellen und einem per OAuth erzeugten API-Schlüssel den Zugriff auf Sheets gegeben; der Claude-Routine-Ansatz wäre wahrscheinlich deutlich einfacher gewesen
Ich würde gerne das gesamte Setup sehen, besonders welche Prompts du verwendest
Vielleicht liegt es daran, dass mein Nettovermögen klein ist, aber ehrlich gesagt verstehe ich nicht so recht, warum das wertvoll sein soll
Ich möchte nicht, dass mir ein LLM täglich E-Mails schickt, und wenn ich mein Investment-Portfolio öfter als vierteljährlich anschauen muss, sollte ich vermutlich eher in sicherere Anlagen gehen. Ein wenig Interesse hätte ich an Budgeting-Tools, aber die sollen bitte vollständig deterministisch sein
Meine Finanzplanung ist im Großen und Ganzen ziemlich ruhig; statt noch mehr Zeit auf Ausgabenoptimierung zu verwenden, halte ich es für sinnvoller, mir einen besser bezahlten Job zu suchen
Ich finde grundsätzlich, dass alles rund um Zahlen vollständig deterministisch sein sollte
Ich habe einem LLM meine SQLite-DB gezeigt und es gebeten zu sagen, was ihm in den Transaktionen der letzten fünf Jahre auffällt; was es erkannt oder mir wieder ins Gedächtnis gerufen hat, war beeindruckend. Aber ob daraus ein praktischer Nutzen entstand, der tatsächlich mein Verhalten ändert, weiß ich nicht so recht
Ich lasse es vielleicht eine Zeit lang monatlich prüfen, aber allein durch die Budget-Updates kenne ich meinen Finanzstatus meist ohnehin schon, daher ist fraglich, wie sehr es hilft
Ich nutze das, um Kreditkarten und Girokonten zu verfolgen, und wenn man will, kann man dort MCP anschließen und so die Daten an einem Ort analysieren
Ich lebe in Kanada und nutze https://lunchmoney.app/ zur Nachverfolgung zusammen mit einer Plaid-Integration
Es gibt eine API, also habe ich mir per LLM eine CLI bauen lassen, wodurch ein Agent die benötigten Daten praktisch beliebig abrufen kann
Eine weitere Aufgabe war das Aufbauen von Tagging-Regeln; das läuft einmal täglich per cron. Gelegentlich lasse ich die Regeln durchsehen, damit neue Regeln für unkategorisierte Transaktionen entstehen
Ich halte dieses Muster, das LLM die Arbeit in einer Rule Engine oder in Code festhalten zu lassen, für ziemlich gut. Sobald man eine abfragbare CLI hat, kann man Agenten fast alles machen lassen
Für Interessierte möchte ich das große Bild unserer Infrastruktur-/Sicherheitsarchitektur teilen
Backend und CLI sind streng gelintetes Rust, die Web-App läuft auf Axum und verbindet sich mit Postgres über sqlx
Die Finanzfunktionen sind schreibgeschützt. Es gibt keine Tools für Überweisungen, Zahlungen oder Geldtransfers, und auch über die AI-Oberfläche kann kein Geld bewegt werden
Bei Plaid fragen wir nur Transaktionen, Investments und Verbindlichkeiten ab; auth/transfer/payment initiation fordern wir nicht an, daher erhalten wir keine vollständigen Kontonummern oder Routing-Nummern, sondern nur die grundlegende last-4-Maskierung
Bank-Benutzernamen und -Passwörter laufen über Plaid Link und nicht über uns; wir halten nur institutionsspezifische Access Tokens
Die Plaid-Access-Tokens liegen in einer separaten DB hinter einem einzelnen Custody-Cloud-Run-Dienst. Beim Speichern werden sie mit Cloud KMS verschlüsselt, und der Broker ruft die KMS-Endpunkte zum Ver- und Entschlüsseln auf; das Root-Key-Material verlässt nie die Google-HSM-Grenze. Nur das Broker-Servicekonto hat Rechte zum Ver- und Entschlüsseln, und die Web-App darf diese DB nicht lesen
Bei jedem Ver-/Entschlüsselungsaufruf übergeben wir die Plaid-Item-ID als AAD, damit Ciphertext eines Items nicht gegen das Token eines anderen Items ausgetauscht und entschlüsselt werden kann
Jeder Cloud-Run-Dienst läuft mit eigener Cloud-ID und eigener DB-Rolle, und interne Aufrufe zwischen Diensten werden ebenfalls mit kurzlebigen Identity Tokens authentifiziert
Die produktive DB hat keine öffentliche IP, und Geheimnisse liegen in einem verwalteten Secret Storage statt im Quellcode oder in Container-Images
Der AI-Connector nutzt OAuth 2.1 + PKCE und hat benutzerspezifische Scopes; Widerruf ist über die UI möglich. Jeder Tool Call protokolliert Tool-Name, bereinigte Argumente, aufrufenden Client und die vom Agenten angegebene Begründung, sodass man sehen kann, was das LLM im Namen des Nutzers angefordert hat
Die AI-Oberfläche hat keine fetch-URL-, Shell- oder generischen I/O-Tools und gibt nur strukturierte Finanzdaten zurück. Networking, IAM und DB-Grants werden vollständig mit Terraform verwaltet, und Infrastrukturänderungen laufen nur über diesen Weg
Der Zugriff auf die Infrastruktur wird mit 2FA und Sicherheitsschlüsseln kontrolliert
Man merkt, dass du die Leserschaft dieser Seite verstehst, und die sorgfältige Sicherheitsarchitektur auf jeder Ebene erhöht mein Vertrauen in das gesamte Tool
Ich hatte selbst überlegt, etwas Ähnliches zu bauen; mein frühes MVP bestand darin, Kontoauszugs-PDFs manuell herunterzuladen und Claude ein Ledger für Buchführung in Plain Text aufsetzen zu lassen, mit dem Plan, später Plaid anzubinden
Besonders bei Plaid interessiert mich, wie Leute es konkret nutzen. Braucht man zum Einstieg eine gewisse Nutzerzahl, oder kann man einfach für den Eigenbedarf ein Plaid-Konto anlegen, um private und geschäftliche Konten an eine saubere API anzubinden?
Bei Routine sollte man vorsichtig sein
Es gibt einen fast unsichtbaren kleinen Hinweis, dass im Routine-Modus MCP-Tools einschließlich Schreibrechten immer erlaubt sind. Ein Agent könnte technisch also durchaus eigenmächtig Ressourcen verändern
Das wirkt wie eine Lösung auf der Suche nach einem Problem. https://tiller.com/ allein funktioniert schon gut genug, und im Spreadsheet kann man jede gewünschte Berechnung machen, mit dem Bonus, dass es keine Halluzinationen gibt
Ich verstehe auch nicht, warum ich unbedingt lange LLM-Zusammenfassungen lesen wollen sollte. Wenn man seine Ausgaben ab und zu selbst kategorisiert, springen einem Ausreißer ohnehin schnell ins Auge, und mit Tiller ist auch das einfach
In diesem Bereich wird es sicher viele unterschiedliche Produkte geben, und unseres ist nur ein möglicher Ansatz darunter. Ich finde es gut, wenn es mehr solcher Versuche gibt
Wichtiger ist, dass LLMs verschiedene Datenquellen leicht aufnehmen und zusammenführen können
Unser Era Finance baut genau dafür eine Lösung. Era Context ist ein MCP, das jeden kompatiblen Agenten mit persönlichen Finanzdaten verbindet, mehr dazu auf https://era.app
Derzeit konzentrieren wir uns auf Lese-Tools, aber Schreib-Tools wie Geldüberweisungen oder Schuldentilgung sind ebenfalls in Vorbereitung
Wenn es Funktionen gibt, die ihr euch wünscht, schreibt gerne an alex auf der obigen Domain. Zur Einordnung: Ich bin CEO Alex, dies ist fast mein erster HN-Beitrag, und früher war ich für die Web-Präsenz von stripe.com verantwortlich, davor bei Square/CashApp
Vielleicht ist der Kampf ohnehin schon verloren, aber ich verstehe nicht, warum man seinen kompletten Finanztransaktionsverlauf einem LLM anvertrauen möchte
Ich glaube nicht, dass LLM-Anbieter beim Umgang mit solchen Daten stärkere Schutzmechanismen haben als die Finanzbranche. Und schon die Finanzbranche selbst ist ein ziemlich harsches Geschäft, was das Sammeln, Auswerten und Verkaufen unserer Daten angeht
Wenn man sich für Ausgabenmuster oder Investments interessiert, kann man schon mit sehr einfachen Prompts Dinge entdecken, die einem zuvor entgangen sind
Natürlich ist es extrem schwierig, das sicher zu machen, und genau darüber denke ich deshalb schon sehr lange nach
Ich verstehe also nicht genau, worin das Problem bestehen soll
Meine Hauptbank, die britische Monzo, bietet eine vollständige API samt Trigger-Webhooks für Events
Dadurch konnte ich einen WhatsApp-Bot bauen, der mich bei ungewöhnlichen Transaktionen nach einer Begründung fragt; das LLM nutze ich nur für die Schlussfolgerung. Außerdem habe ich eine Automatisierung eingerichtet, die täglich kurz vor Mitternacht den Kontostand auf ein Sparkonto überträgt, um die täglichen Zinsen zu maximieren
Auf dem Alltagskonto halte ich nur einen kleinen Betrag, und wenn ich tagsüber Geld ausgebe, wird es vom Sparkonto wieder aufgefüllt, damit dieser niedrige Kontostand erhalten bleibt. Für größere Ausgaben übertrage ich dann manuell
Als ich Claude zum Analysieren historischer Transaktionen verwendet habe, hat es ständig halluziniert: nicht existierende Abbuchungen erfunden, neue Positionen hinzugefügt und Dinge doppelt gezählt
Wenn es um Finanzen geht, reichen 95 % Korrektheit bei Claude einfach nicht aus. Ich muss ständig auf der Hut sein und die Ergebnisse prüfen, und damit ist es für mich faktisch wertlos
Ich habe ebenfalls den Eindruck, dass Claude besonders bei unvollständigen oder begrenzten Datensätzen recht stark halluziniert