Personal finance & budgeting assistant

Most households do not know where their money goes: spending is spread over several accounts, cards and subscriptions, and spreadsheets are abandoned after a few weeks. An AI assistant reads transactions (via bank connection or export), categorises them automatically, detects recurring payments and anomalies, and lets the user ask questions in plain language. The core is classic categorisation plus an LLM layer for explanation and dialogue; the sensitive part is the data, not the model.

Problem & value

• Today: manual spreadsheets, bank-app categories of mixed quality, or nothing. Subscriptions, annual fees and price increases go unnoticed; tax-relevant items are not collected during the year.
• AI value: automatic categorisation (merchant normalisation from messy booking texts), detection of recurring payments, plain-language Q&A over one's own data, forecasts of upcoming fixed costs, and reminders before cancellation deadlines.
• Evidence: no robust, independent figures on average savings are known to us; vendor claims of "X EUR saved per user" should be treated as marketing. Measure your own baseline instead.
• Regulatory enabler: PSD2 gives customers the right to share payment-account data with licensed account information service providers (AISPs); PSD3/PSR is its successor and the planned Financial Data Access framework (FiDA) would extend sharing to savings, investments, pensions and insurance. FiDA's final shape and timing were still being negotiated in 2026 [1][2].

Variants

• Pure tracker: categories, budgets, subscriptions, net worth over time.
• Conversational analyst: "How much did I spend on food delivery this year?" answered via text-to-SQL over the user's ledger.
• Receipt/contract capture: photos of receipts and insurance letters feed the ledger (see DOC-002).
• Household/couples: shared budgets and joint accounts (see PERS-009).
• Tax prep: tag deductible items during the year (see PERS-013).
• Developer/hobbyist: plain-text accounting (Beancount, hledger) or Actual Budget plus a local LLM.
• Not covered: regulated investment, credit or insurance advice (see Risks); lending decisions on consumers (DOC-017).

How it works

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)

• Categorisation: a rules table (IBAN, merchant string) first, then a small classifier or LLM with few-shot examples for the unknown rest; every user correction becomes a rule. This keeps cost and error low.
• Numbers by tools, not by the LLM: totals, averages and forecasts are computed with SQL/pandas; the LLM only formulates queries and explains results. This avoids arithmetic hallucinations.
• Human-in-the-loop: the assistant proposes, the user decides. It should never initiate payments, cancel contracts or move money autonomously without explicit confirmation per action.

Data preparation

Data comes from the user's own bank accounts (PSD2 connection or CSV/CAMT/MT940 export), credit-card statements, and receipts or contracts kept as photos, PDFs or paper in a folder. Typical gaps are cryptic purpose texts, split bookings, missing history, duplicate imports when several accounts overlap, receipts without a link to a booking, and scattered subscriptions across cards and PayPal. Preparation steps: export 12-24 months of history from every account into one format, normalise date, amount and counterparty, de-duplicate transfers between own accounts, start with a rules table (IBAN and merchant string) before any model, and scan receipts with a phone OCR app or Paperless-ngx. Correct the first 100-200 miscategorised bookings by hand, because every correction becomes a rule. Mind the access side: use read-only bank access and store credentials in a password manager. Effort is small, roughly 20-30 percent of the total, and mostly one-off. Where the data is messy tables, see PREP-011; for structured exports from banking tools see PREP-005; for paper receipts see PREP-006 and DOC-014; for pseudonymising data before sending it to a cloud model see PREP-022.

Implementation paths

Which path for whom

• Private: A - mature budgeting apps with bank connection exist at a few EUR per month, and the process is standard.
• Developer: C - a self-hosted ledger such as Firefly III with a small local model keeps bank data on own hardware (HW1) and can be extended freely.

Path A - Buy (recommended for private users)

• Consumer apps with bank connection (EU/DACH): Finanzguru (DE), Outbank (DE), Bunq's in-app finance assistant (NL), Revolut and N26 built-in insights, plus bank-native tools (e.g. Sparkasse, ING, DKB budgeting). Others: YNAB, Monarch (US-centric, limited EU bank coverage), Copilot (US).
• Check: licensed AISP or bank-grade connection, EU/German hosting, read-only access, data export, deletion on request, no resale of data, transparent business model (subscription beats "free").
• Choose A when: you want results in minutes and accept a vendor holding your transaction data.

Path B - Build on cloud APIs

• Bank data aggregation (licensed AISPs, EU): GoCardless Bank Account Data (formerly Nordigen; reportedly no longer accepting new sign-ups since mid-2025; existing accounts continue, check availability), Tink (Visa), Finapi (DE), Yapily, Plaid (EU coverage), or FinTS/HBCI directly for German banks. Using one of these means the aggregator is the regulated party; you handle consent screens and renewals (typically every 90-180 days under PSD2 SCA rules).
• LLM: a frontier model with tool calling and structured outputs (Claude, Gemini, GPT, Mistral as EU provider) for categorisation fallback and Q&A; choose EU-region endpoints and a no-training/zero-retention contract. Send aggregated or pseudonymised data where possible, not raw IBANs and names.
• Stack: Postgres/SQLite ledger, text-to-SQL tool with read-only role, n8n or a small service for sync.
• Choose B when: you build a product or want custom logic across data sources.

Path C - Self-host (open source)

• Ledger/budgeting: Actual Budget, Firefly III (with its data importer for CSV and bank APIs), Beancount/ hledger for plain text. All run on a Raspberry Pi or home server [3][4].
• LLM: small open-weight models (Qwen3, Llama, Mistral Small, Gemma, Phi) via Ollama or llama.cpp for categorisation and Q&A; 7-14B quantised is enough for merchant categorisation and SQL generation.
• Ingest: CAMT/MT940/CSV exports or FinTS via open libraries; receipts via Docling or PaddleOCR (see DOC-002). Everything stays on the home network, ideal for the most privacy-sensitive data (see PERS-005).
• Hardware: HW1 (mini-PC or laptop NPU, 16 GB RAM) suffices; HW2 improves speed of larger models.

Path D - Custom training

Rarely worthwhile for one household. For a vendor, fine-tune a small text classifier (BERT-class) on labelled booking texts to cut inference cost and improve German/EU merchant normalisation; the labelled data come from user corrections (with consent).

State of the art (2026)

• Categorisation of booking texts is a solved-enough problem: rules plus small ML reach good accuracy on common merchants; the long tail (local shops, PayPal/Amazon pass-through, transfers between own accounts) still needs user correction.
• Conversational finance Q&A via text-to-SQL or tool calling works reliably when schema is simple and the model is asked to show the query. Agentic assistants with MCP-style connectors to ledgers (e.g. for Actual Budget or Firefly III) are emerging in the hobbyist community.
• Receipts and contracts are read well by VLM-based OCR; subscription terms in contracts are a good extraction target (cancellation period, price clause).
• Limits and failure modes: LLM arithmetic errors if numbers are not tool-computed; wrong categories for ambiguous merchants; double counting of transfers and credit-card settlements; stale data when bank consent expires; "advice" that sounds authoritative on investments, taxes or debt without being qualified; prompt injection through counterparty or purpose fields of incoming transfers (untrusted text inside the ledger).

Shared resources & combinations

• Same capabilities as LANG-033 (bank transaction enrichment), DOC-002 (receipt capture) and DOC-017 (bank statement analysis, lending side); the categorisation model and VLM server can be shared.
• Combines with PERS-013 (tax return: tag deductibles), PERS-008 (letters and invoices), PERS-011 (price comparison and deals), PERS-009 (household organisation), PERS-005 (local assistant on home server).
• Hardware: a home server hosting Ollama can serve PERS-001, PERS-004, PERS-006 and PERS-008 together.

Effort, cost & KPIs

• Path A: minutes to days; subscriptions are often in the range of a few EUR per month (check current prices).
• Path B: a weekend for a prototype, 1-3 months for a product incl. consent management, security review and aggregator contract; LLM cost per user is small if rules handle most categorisation.
• Path C: a weekend to set up; ongoing maintenance of updates, backups and import jobs.
• KPIs: share of transactions correctly auto-categorised, number of manual corrections per month, detected recurring payments confirmed by user, subscriptions cancelled, share of months with budget kept, time spent per month on bookkeeping.

People & change

For private use there is no organisation to involve, but the household matters: agree with partners which shared accounts are included, and who sees what. Developers building a product need a DPO early, because bank transactions reveal health, religion, politics and relationships; a DPIA (Art. 35 GDPR) is likely for any service at scale, plus an AVV (Art. 28 GDPR) with every cloud processor. No works council is involved unless the tool is offered to employees, in which case §87(1) no. 6 BetrVG may apply if usage is logged. AI literacy: the Art. 4 AI Act duty to support staff literacy only concerns organisations; for individuals, a short read of the provider's privacy terms and training-data policy is the equivalent. Typical concerns are "who sees my bank data" and "will it move money". Address them with read-only access, local or EU storage, and a hard rule that the assistant proposes and the user confirms every transfer or cancellation. Pilot with one account and one month of data before connecting everything, and compare its totals against your own bank statement. See GUIDE-005 for data protection, GUIDE-006 for literacy and GUIDE-010 when choosing a provider.

Risks, regulation & compliance

• EU AI Act: minimal risk for budgeting and categorisation (AI literacy Art. 4 applies to providers/deployers in a business context). Becomes high-risk (Annex III 5(b)) if the same data is used to evaluate the creditworthiness or credit score of natural persons; do not repurpose a budgeting product for credit scoring without that analysis. Chatbot transparency (Art. 50) applies to the conversational layer.
• GDPR: transaction data reveals health, religion, politics and relationships (special-category inference through payees); explicit consent, data minimisation, purpose limitation, deletion and export rights, EU hosting, DPA with LLM providers. Private individuals using tools purely personally fall under the household exemption; vendors do not [5].
• Financial regulation: account access requires a licensed AISP or bank interface under PSD2; do not scrape bank logins or ask users for their online-banking PIN. Personalised investment advice is regulated (MiFID II); present insights as information, not advice.
• Security: read-only tokens, encrypted storage, secrets outside prompts, no payment initiation by the LLM, logging of tool calls.
• Mitigations: show source transactions for every claim, compute numbers with code, require confirmation for any action, treat counterparty text as untrusted.

Getting started

1. Export 12 months of transactions (CSV/CAMT) from your main account; import into Actual Budget or Firefly III.
2. Define 10-15 categories and let rules plus an LLM categorise; correct the first 100 errors to build rules.
3. Add a recurring-payment report and review every subscription once.
4. Add a read-only Q&A layer (text-to-SQL with query shown) and test against numbers you already know.
5. Decide on bank connection: licensed aggregator or manual monthly export; set a reminder for consent renewal.

Sources

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