Assistent für Privatfinanzen und Haushaltsbudget

Die meisten Haushalte wissen nicht, wohin ihr Geld fließt: Die Ausgaben verteilen sich auf mehrere Konten, Karten und Abonnements, und Tabellenkalkulationen werden nach wenigen Wochen aufgegeben. Ein KI-Assistent liest Transaktionen (per Bankanbindung oder Export), kategorisiert sie automatisch, erkennt wiederkehrende Zahlungen und Auffälligkeiten und lässt die Nutzerin oder den Nutzer Fragen in einfacher Sprache stellen. Den Kern bilden klassische Kategorisierung und eine LLM-Schicht für Erklärung und Dialog; heikel sind die Daten, nicht das Modell.

Problem & Nutzen

• Heute: manuelle Tabellen, Kategorien der Banking-App von wechselnder Qualität oder gar nichts. Abonnements, Jahresgebühren und Preiserhöhungen bleiben unbemerkt; steuerlich relevante Posten werden während des Jahres nicht gesammelt.
• KI-Nutzen: automatische Kategorisierung (Normalisierung von Händlernamen aus unübersichtlichen Buchungstexten), Erkennung wiederkehrender Zahlungen, Fragen und Antworten in einfacher Sprache zu den eigenen Daten, Prognosen kommender Fixkosten und Erinnerungen vor Kündigungsfristen.
• Belege: Uns sind keine belastbaren, unabhängigen Zahlen zur durchschnittlichen Ersparnis bekannt; Herstellerangaben wie „X EUR gespart pro Nutzer“ sind als Marketing zu behandeln. Messen Sie stattdessen Ihre eigene Ausgangslage.
• Regulatorischer Wegbereiter: PSD2 gibt Kundinnen und Kunden das Recht, Zahlungskontodaten mit zugelassenen Kontoinformationsdienstleistern (AISPs) zu teilen; PSD3/PSR ist der Nachfolger, und der geplante Rahmen für den Zugang zu Finanzdaten (Financial Data Access, FiDA) würde das Teilen auf Sparanlagen, Investments, Altersvorsorge und Versicherungen ausweiten. Die endgültige Form und der Zeitplan von FiDA wurden 2026 noch verhandelt [1][2].

Varianten

• Reiner Tracker: Kategorien, Budgets, Abonnements, Vermögensentwicklung über die Zeit.
• Dialogfähiger Analyst: „Wie viel habe ich dieses Jahr für Essenslieferungen ausgegeben?“, beantwortet per Text-to-SQL über das Haushaltsbuch der Nutzerin oder des Nutzers.
• Erfassung von Belegen und Verträgen: Fotos von Belegen und Versicherungsschreiben speisen das Haushaltsbuch (siehe DOC-002).
• Haushalt/Paare: gemeinsame Budgets und Gemeinschaftskonten (siehe PERS-009).
• Steuervorbereitung: absetzbare Posten während des Jahres markieren (siehe PERS-013).
• Entwickler/Hobbyanwender: Plain-Text-Buchhaltung (Beancount, hledger) oder Actual Budget plus lokales LLM.
• Nicht abgedeckt: regulierte Anlage-, Kredit- oder Versicherungsberatung (siehe Risiken); Kreditentscheidungen über Verbraucher (DOC-017).

So funktioniert es

data intake (bank API/AISP | CSV, CAMT.053, MT940 | receipt photo)
  -> normalise (dates, amounts, currency, counterparty, purpose text)
  -> merchant & category classification (rules -> ML/LLM fallback, user corrections win)
  -> recurring-payment & anomaly detection (period detection, price-change flags)
  -> ledger / database (local or EU-hosted)
  -> LLM layer: summaries, Q&A via text-to-SQL or tool calls, savings ideas
  -> user review & confirmation (categories, cancellations, transfers)

• Kategorisierung: zuerst eine Regeltabelle (IBAN, Händlerbezeichnung), dann ein kleiner Klassifikator oder ein LLM mit Few-Shot- Beispielen für den unbekannten Rest; jede Korrektur der Nutzerin oder des Nutzers wird zur Regel. So bleiben Kosten und Fehlerquote niedrig.
• Zahlen von Werkzeugen, nicht vom LLM: Summen, Durchschnitte und Prognosen werden mit SQL/pandas berechnet; das LLM formuliert nur Abfragen und erklärt Ergebnisse. So vermeiden Sie Rechenfehler durch Halluzinationen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Assistent schlägt vor, die Nutzerin oder der Nutzer entscheidet. Er darf niemals ohne ausdrückliche Bestätigung je Aktion Zahlungen auslösen, Verträge kündigen oder Geld bewegen.

Datenaufbereitung

Die Daten stammen aus den eigenen Bankkonten der Nutzerin oder des Nutzers (PSD2-Anbindung oder CSV-/CAMT-/MT940-Export), aus Kreditkartenabrechnungen sowie aus Belegen oder Verträgen, die als Fotos, PDFs oder Papier in einem Ordner liegen. Typische Lücken sind kryptische Verwendungszwecke, gesplittete Buchungen, fehlende Historie, doppelte Importe bei überlappenden Konten, Belege ohne Bezug zu einer Buchung und über Karten und PayPal verstreute Abonnements. Vorbereitungsschritte: 12-24 Monate Historie aus jedem Konto in ein einheitliches Format exportieren, Datum, Betrag und Gegenpartei normalisieren, Überweisungen zwischen eigenen Konten entdoppeln, vor jedem Modell mit einer Regeltabelle (IBAN und Händlerbezeichnung) beginnen und Belege mit einer OCR-App auf dem Smartphone oder mit Paperless-ngx scannen. Korrigieren Sie die ersten 100-200 falsch kategorisierten Buchungen von Hand, denn jede Korrektur wird zur Regel. Beachten Sie die Zugriffsseite: Nutzen Sie einen reinen Lesezugriff auf die Bank und speichern Sie Zugangsdaten in einem Passwortmanager. Der Aufwand ist gering, etwa 20-30 Prozent des Gesamtaufwands, und fällt überwiegend einmalig an. Zu unaufgeräumten Tabellen siehe PREP-011; zu strukturierten Exporten aus Banking-Werkzeugen siehe PREP-005; zu Papierbelegen siehe PREP-006 und DOC-014; zur Pseudonymisierung von Daten vor dem Versand an ein Cloud-Modell siehe PREP-022.

Umsetzungswege

Welcher Weg für wen

• Privat: A - ausgereifte Budget-Apps mit Bankanbindung gibt es für wenige EUR im Monat, und der Ablauf ist Standard.
• Entwickler: C - ein selbst betriebenes Haushaltsbuch wie Firefly III mit einem kleinen lokalen Modell hält die Bankdaten auf eigener Hardware (HW1) und lässt sich frei erweitern.

Weg A - Kaufen (Standardsoftware) (empfohlen für Privatnutzer)

• Verbraucher-Apps mit Bankanbindung (EU/DACH): Finanzguru (DE), Outbank (DE), der Finanzassistent in der Bunq-App (NL), die integrierten Auswertungen von Revolut und N26 sowie bankeigene Werkzeuge (z. B. Budgetfunktionen von Sparkasse, ING, DKB). Weitere: YNAB, Monarch (US-zentriert, begrenzte Abdeckung europäischer Banken), Copilot (USA).
• Prüfen: zugelassener AISP bzw. Anbindung auf Bankniveau, Hosting in der EU/Deutschland, reiner Lesezugriff, Datenexport, Löschung auf Anfrage, kein Weiterverkauf von Daten, transparentes Geschäftsmodell (Abo schlägt „kostenlos“).
• A wählen, wenn: Sie Ergebnisse in Minuten wollen und akzeptieren, dass ein Anbieter Ihre Transaktionsdaten hält.

Weg B - Auf Cloud-KI-Diensten aufbauen

• Aggregation von Bankdaten (zugelassene AISPs, EU): GoCardless Bank Account Data (früher Nordigen; nimmt Berichten zufolge seit Mitte 2025 keine Neuanmeldungen mehr an; bestehende Konten laufen weiter, Verfügbarkeit prüfen), Tink (Visa), Finapi (DE), Yapily, Plaid (Abdeckung in der EU) oder FinTS/HBCI direkt für deutsche Banken. Wer einen davon nutzt, hat den Aggregator als regulierte Partei; Sie kümmern sich um Einwilligungsdialoge und Verlängerungen (nach den PSD2-SCA-Regeln typischerweise alle 90-180 Tage).
• LLM: ein Spitzenmodell mit Tool-Aufrufen und strukturierten Ausgaben (Claude, Gemini, GPT, Mistral als EU- Anbieter) für den Kategorisierungs-Fallback und für Fragen und Antworten; wählen Sie Endpunkte in EU-Regionen und einen Vertrag ohne Training und mit Zero-Retention. Senden Sie nach Möglichkeit aggregierte oder pseudonymisierte Daten, nicht rohe IBANs und Namen.
• Stack: Postgres-/SQLite-Haushaltsbuch, Text-to-SQL-Werkzeug mit Nur-Lese-Rolle, n8n oder ein kleiner Dienst für die Synchronisierung.
• B wählen, wenn: Sie ein Produkt bauen oder eigene Logik über mehrere Datenquellen brauchen.

Weg C - Selbst betreiben (Open Source)

• Haushaltsbuch/Budgetierung: Actual Budget, Firefly III (mit Data Importer für CSV und Bank-APIs), Beancount/ hledger für Klartext. Alle laufen auf einem Raspberry Pi oder Heimserver [3][4].
• LLM: kleine Open-Weight-Modelle (Qwen3, Llama, Mistral Small, Gemma, Phi) über Ollama oder llama.cpp für Kategorisierung und Fragen und Antworten; 7-14B quantisiert genügt für die Kategorisierung von Händlern und die SQL-Erzeugung.
• Import: CAMT-/MT940-/CSV-Exporte oder FinTS über offene Bibliotheken; Belege über Docling oder PaddleOCR (siehe DOC-002). Alles bleibt im Heimnetz, ideal für die datenschutzsensibelsten Daten (siehe PERS-005).
• Hardware: HW1 (Mini-PC oder Laptop-NPU, 16 GB RAM) genügt; HW2 beschleunigt größere Modelle.

Weg D - Eigenes Training

Für einen einzelnen Haushalt selten lohnend. Ein Anbieter kann einen kleinen Textklassifikator (BERT-Klasse) auf gelabelten Buchungstexten feintunen, um Inferenzkosten zu senken und die Normalisierung deutscher/europäischer Händler zu verbessern; die gelabelten Daten stammen aus Korrekturen der Nutzerinnen und Nutzer (mit Einwilligung).

Stand der Technik (2026)

• Kategorisierung von Buchungstexten ist ein hinreichend gelöstes Problem: Regeln plus kleines ML erreichen bei gängigen Händlern eine gute Genauigkeit; der lange Schwanz (lokale Geschäfte, Durchreichung über PayPal/Amazon, Überweisungen zwischen eigenen Konten) braucht weiterhin Korrekturen der Nutzerin oder des Nutzers.
• Dialogfähige Fragen und Antworten zu Finanzen per Text-to-SQL oder Tool-Aufrufen funktionieren zuverlässig, wenn das Schema einfach ist und das Modell die Abfrage zeigen soll. Agentische Assistenten mit MCP-artigen Anbindungen an Haushaltsbücher (z. B. für Actual Budget oder Firefly III) entstehen in der Hobby-Community.
• Belege und Verträge werden von VLM-basierter OCR gut gelesen; Abonnementbedingungen in Verträgen sind ein gutes Extraktionsziel (Kündigungsfrist, Preisklausel).
• Grenzen und Fehlerbilder: Rechenfehler des LLM, wenn Zahlen nicht von Werkzeugen berechnet werden; falsche Kategorien bei mehrdeutigen Händlern; Doppelzählung von Überweisungen und Kreditkartenabrechnungen; veraltete Daten, wenn die Bankeinwilligung abläuft; „Ratschläge“ zu Geldanlage, Steuern oder Schulden, die autoritativ klingen, ohne eingeordnet zu sein; Prompt Injection über Gegenpartei- oder Verwendungszweckfelder eingehender Überweisungen (nicht vertrauenswürdiger Text im Haushaltsbuch).

Gemeinsame Bausteine & Kombinationen

• Gleiche Fähigkeiten wie LANG-033 (Anreicherung von Banktransaktionen), DOC-002 (Belegerfassung) und DOC-017 (Analyse von Kontoauszügen, Kreditseite); das Kategorisierungsmodell und der VLM-Server können gemeinsam genutzt werden.
• Kombinierbar mit PERS-013 (Steuererklärung: absetzbare Posten markieren), PERS-008 (Briefe und Rechnungen), PERS-011 (Preisvergleich und Angebote), PERS-009 (Haushaltsorganisation), PERS-005 (lokaler Assistent auf dem Heimserver).
• Hardware: Ein Heimserver mit Ollama kann PERS-001, PERS-004, PERS-006 und PERS-008 gemeinsam bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Minuten bis Tage; Abonnements liegen oft im Bereich weniger EUR pro Monat (aktuelle Preise prüfen).
• Weg B: ein Wochenende für einen Prototyp, 1-3 Monate für ein Produkt inkl. Einwilligungsverwaltung, Sicherheitsprüfung und Aggregator-Vertrag; die LLM-Kosten pro Nutzer sind gering, wenn Regeln den Großteil der Kategorisierung übernehmen.
• Weg C: ein Wochenende zur Einrichtung; laufender Aufwand für Updates, Backups und Importaufträge.
• Kennzahlen: Anteil der korrekt automatisch kategorisierten Transaktionen, Zahl der manuellen Korrekturen pro Monat, von der Nutzerin oder dem Nutzer bestätigte erkannte wiederkehrende Zahlungen, gekündigte Abonnements, Anteil der Monate mit eingehaltenem Budget, monatlicher Zeitaufwand für die Buchführung.

Menschen & Veränderung

Bei privater Nutzung ist keine Organisation einzubeziehen, aber der Haushalt zählt: Vereinbaren Sie mit Partnerinnen und Partnern, welche gemeinsamen Konten einbezogen werden und wer was sieht. Entwickler, die ein Produkt bauen, brauchen früh eine(n) Datenschutzbeauftragte(n), weil Banktransaktionen Gesundheit, Religion, Politik und Beziehungen offenlegen; für jeden Dienst in größerem Umfang ist wahrscheinlich eine Datenschutz-Folgenabschätzung (DSFA, Art. 35 DSGVO) nötig, dazu ein Auftragsverarbeitungsvertrag (AVV, Art. 28 DSGVO) mit jedem Cloud-Auftragsverarbeiter. Ein Betriebsrat ist nicht beteiligt, es sei denn, das Werkzeug wird Beschäftigten angeboten; dann kann § 87 Abs. 1 Nr. 6 BetrVG greifen, wenn die Nutzung protokolliert wird. KI-Kompetenz: Die Pflicht nach Art. 4 KI-Verordnung (AI Act), die KI-Kompetenz der Beschäftigten zu fördern, betrifft nur Organisationen; für Privatpersonen ist das Äquivalent ein kurzes Lesen der Datenschutzbedingungen und der Richtlinie zu Trainingsdaten des Anbieters. Typische Sorgen sind „Wer sieht meine Bankdaten?“ und „Bewegt es Geld?“. Begegnen Sie ihnen mit reinem Lesezugriff, lokaler oder EU-Speicherung und einer harten Regel, dass der Assistent vorschlägt und die Nutzerin oder der Nutzer jede Überweisung und Kündigung bestätigt. Starten Sie mit einem Konto und einem Monat Daten, bevor Sie alles anbinden, und vergleichen Sie die Summen mit Ihrem eigenen Kontoauszug. Siehe GUIDE-005 zum Datenschutz, GUIDE-006 zur KI-Kompetenz und GUIDE-010 bei der Anbieterauswahl.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für Budgetierung und Kategorisierung (die KI-Kompetenz nach Art. 4 gilt für Anbieter/Betreiber im geschäftlichen Kontext). Wird hochriskant (Anhang III 5(b)), wenn dieselben Daten zur Bewertung der Kreditwürdigkeit oder zum Kredit-Scoring natürlicher Personen genutzt werden; zweckentfremden Sie ein Budgetierungsprodukt nicht für Kredit-Scoring, ohne diese Analyse. Die Transparenz für Chatbots (Art. 50) gilt für die Dialogschicht.
• DSGVO: Transaktionsdaten offenbaren Gesundheit, Religion, Politik und Beziehungen (Rückschluss auf besondere Kategorien über Zahlungsempfänger); ausdrückliche Einwilligung, Datenminimierung, Zweckbindung, Lösch- und Exportrechte, Hosting in der EU, AVV mit LLM-Anbietern. Privatpersonen, die Werkzeuge rein persönlich nutzen, fallen unter die Haushaltsausnahme; Anbieter nicht [5].
• Finanzregulierung: Der Kontozugriff erfordert einen zugelassenen AISP oder eine Bankschnittstelle nach PSD2; greifen Sie nicht per Scraping auf Bank-Logins zu und fragen Sie Nutzer nicht nach ihrer Online-Banking-PIN. Personalisierte Anlageberatung ist reguliert (MiFID II); stellen Sie Erkenntnisse als Information dar, nicht als Beratung.
• Sicherheit: Nur-Lese-Tokens, verschlüsselte Speicherung, Geheimnisse außerhalb von Prompts, keine Zahlungsauslösung durch das LLM, Protokollierung von Tool-Aufrufen.
• Gegenmaßnahmen: Quelltransaktionen zu jeder Aussage anzeigen, Zahlen mit Code berechnen, für jede Aktion eine Bestätigung verlangen, Text der Gegenpartei als nicht vertrauenswürdig behandeln.

Erste Schritte

1. Exportieren Sie 12 Monate Transaktionen (CSV/CAMT) aus Ihrem Hauptkonto; importieren Sie sie in Actual Budget oder Firefly III.
2. Definieren Sie 10-15 Kategorien und lassen Sie Regeln plus LLM kategorisieren; korrigieren Sie die ersten 100 Fehler, um Regeln aufzubauen.
3. Fügen Sie einen Bericht über wiederkehrende Zahlungen hinzu und prüfen Sie jedes Abonnement einmal.
4. Ergänzen Sie eine Nur-Lese-Schicht für Fragen und Antworten (Text-to-SQL mit angezeigter Abfrage) und testen Sie sie an Zahlen, die Sie bereits kennen.
5. Entscheiden Sie über die Bankanbindung: zugelassener Aggregator oder manueller Monatsexport; setzen Sie eine Erinnerung für die Verlängerung der Einwilligung.

Quellen

1. Directive (EU) 2015/2366 (PSD2) - https://eur-lex.europa.eu/eli/dir/2015/2366/oj
2. European Commission - Framework for Financial Data Access (FiDA proposal) - https://finance.ec.europa.eu/digital-finance/framework-financial-data-access_en
3. Actual Budget documentation - https://actualbudget.org/docs/
4. Firefly III documentation - https://docs.firefly-iii.org/
5. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. Regulation (EU) 2024/1689 (AI Act), Annex III and Art. 50 - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. GoCardless Bank Account Data documentation - https://developer.gocardless.com/bank-account-data/overview
8. Ollama - https://github.com/ollama/ollama