# JARVIS Finance System – Spezifikation v0.3

**Version:** 0.3  
**Datum:** 2026-05-14  
**Status:** Fachlich-technische Spezifikation / kein Code  
**Topic:** Finance System – Architektur & Scripts  
**Basiswährung:** CHF  
**Leitlinie:** Saubere Finanzbuchhaltung, Crypto-Inventory, Risiko- und Entscheidungsunterstützung – keine automatische Orderausführung.

---

## 1. Zweck und Einordnung von MVP

### 1.1 Was MVP in diesem Projekt bedeutet

**MVP** bedeutet **Minimum Viable Product**: die kleinste sinnvolle erste Version des JARVIS Finance Systems, die bereits echten Nutzen liefert und korrekt erweitert werden kann.

Für dieses Projekt heisst MVP nicht: hübscher Portfolio-Viewer mit Tabellen und ein bisschen Kursgrün. Das wäre Spielzeug mit Datenbankanschluss. Für uns heisst MVP:

1. saubere Datenbasis;
2. transaktionsbasierter Ledger;
3. CHF-Basiswährung mit historischer FX-Logik;
4. Plattform-/Depotübersicht;
5. Portfolioübersicht für Aktien/ETFs;
6. Crypto-Bestandsverwaltung mit Wallet-Struktur;
7. Watchlist;
8. einfache Reports inklusive Crypto-Bestands-PDF;
9. Kern-Workflows für manuelle Eingabe, CSV-Import und spätere Telegram-Erfassung;
10. History-/Audit-Log;
11. einfache Alerts für Datenqualität und grosse Bewegungen.

Komplexe Scores, Newsanalyse, Analystenratings, Opportunity Scanner, vollständige Broker-Integrationen und LLM-Analysen kommen später. Erst Buchhaltung, dann Meinung. Die Reihenfolge ist nicht verhandelbar, wenn das System vertrauenswürdig werden soll.

---

## 2. Korrigierte Prioritäten gegenüber v0.2

### 2.1 Steuerunterlagen Aktien/ETFs zurückgestuft

Für Aktien, ETFs und Broker-Portfolios müssen Steuerunterlagen nicht primär durch das JARVIS Finance System erstellt werden, weil sie zukünftig direkt von Brokern/Banken bezogen werden können.

Das Steuer-/Income-Modul für Aktien/ETFs wird daher in v0.3 zurückgestuft auf:

- optionales Referenz- und Kontrollmodul;
- Dividenden-/Ausschüttungsübersicht zur eigenen Transparenz;
- Jahresübersicht als Zusatznutzen;
- keine Priorität für MVP 1;
- kein vollständiger Steuerdossier-Ersatz.

Weiterhin wichtig, aber nicht MVP-kritisch als Steuerdossier:

- Bruttodividende;
- Nettodividende;
- Schweizer Verrechnungssteuer;
- ausländische Quellensteuer;
- Währung;
- Zahlungsdatum;
- Depot/Konto;
- ISIN/Ticker, falls vorhanden.

### 2.2 Crypto-Bestandsreport priorisiert

Crypto erhält in v0.3 eine höhere Priorität als das vollständige Aktien-/ETF-Steuermodul.

Grund: Coins können über mehrere Wallets, Plattformen und Börsen verteilt sein. Broker liefern hierfür meist kein vollständiges, einheitliches Dossier. Deshalb braucht das System zwingend eine eigene, saubere Crypto-Bestandsübersicht.

### 2.3 MVP-Fokus v0.3

MVP 1 fokussiert auf:

- Initial-Snapshot aus vorhandenen Auszügen;
- manuelle Eingabe im Dashboard;
- CSV-Import/Export;
- CHF- und FX-Ledger;
- Aktien-/ETF-Portfolioübersicht;
- Crypto-Inventory mit Wallet-Struktur;
- Crypto-Bestands-PDF;
- Watchlist;
- Audit-/History-Log;
- einfache Reports;
- einfache Alerts.

Nicht MVP 1:

- vollständiger Steuerreport für Aktien/ETFs;
- komplexe Analysten-/News-Auswertung;
- Opportunity Scanner;
- automatische Broker-Anbindungen;
- automatische Orderausführung;
- komplexe LLM-Analysen.

---

## 3. Systementscheidungen v0.3

### 3.1 Basiswährung bleibt CHF

Die Systembasiswährung bleibt **CHF**.

Alle Bewertungen, Gesamtansichten, Reports und Portfolio-Kennzahlen werden primär in CHF geführt. Für Crypto-Bestände kann zusätzlich eine optionale USD/EUR-Ansicht angezeigt werden.

### 3.2 Keine automatische Orderausführung

Das System darf:

- Transaktionen dokumentieren;
- Transaktionen vorbereiten;
- Orderdaten lesbar zusammenfassen;
- Rebalancing-Vorschläge machen;
- Alerts erzeugen;
- Reports erstellen.

Das System darf nicht:

- Orders automatisch ausführen;
- Broker-/Exchange-Trading-APIs für Orderausführung verwenden;
- ohne explizite Bestätigung Finanzdaten verändern;
- Telegram-Nachrichten ohne Bestätigung direkt final buchen.

### 3.3 Datenhoheit und Geheimhaltung

Finanzdaten bleiben privat. Git darf nur Code, Schemata, synthetische Testdaten und Dokumentation enthalten.

Nie in Git:

- echte Portfolio-Daten;
- Wallet-Bestände;
- Broker-/Bank-Auszüge;
- PDF-/DOCX-/XLSX-Finanzunterlagen;
- Reports mit echten Zahlen;
- Datenbanken;
- API Keys;
- Tokens;
- Credentials.

---

## 4. Crypto-Inventory-Modul

### 4.1 Ziel

Das Crypto-Inventory-Modul verwaltet reale Coin-Bestände über verschiedene Wallets, Börsen, Broker und Plattformen hinweg.

Es beantwortet:

- Welche Coins halte ich?
- Auf welchen Wallets/Plattformen liegen sie?
- Wie viel liegt pro Wallet?
- Wie viel halte ich insgesamt pro Coin?
- Was ist der aktuelle Wert in CHF?
- Welche Preise sind aktuell, veraltet oder fehlen?
- Wann wurde ein Bestand zuletzt verifiziert?

### 4.2 Grundlogik

Ein Coin kann auf mehreren Wallets/Plattformen liegen.

Beispiel:

- Bitcoin / BTC
  - Wallet A: 0.10 BTC
  - Wallet B: 0.05 BTC
  - Börse C: 0.02 BTC
  - Gesamt: 0.17 BTC
  - aktueller Wert: Menge gesamt × CoinGecko-Preis × FX in CHF

### 4.3 Anforderungen

Das Modul muss unterstützen:

- Coins nach Wallet/Plattform sortieren;
- gleicher Coin auf mehreren Wallets;
- pro Wallet: Coin, Symbol, Menge, Netzwerk/Chain optional, Notiz;
- Gesamtposition pro Coin über alle Wallets;
- aktuellen Wert über CoinGecko berechnen;
- alte Werte aus PostFinance-/Snapshot-Auszügen nicht als aktuelle Bewertung verwenden;
- PDF-Export für Crypto-Bestand;
- Gesamtwert in CHF;
- optionale Ansicht in USD/EUR;
- Report-Zeitstempel;
- Datenquelle für Preise;
- Warnung bei fehlendem oder veraltetem Preis;
- manuelle Bestandsverifikation mit Zeitstempel.

### 4.4 Abgrenzung

MVP 1 benötigt keine automatische On-chain-Wallet-Abfrage. Wallet-Bestände werden manuell, per CSV oder später per Telegram-Workflow gepflegt.

Später möglich:

- Read-only Exchange-API;
- On-chain Address Monitoring;
- DeFi/TVL via DefiLlama;
- Staking Rewards;
- Tax-Lot-Analyse für Crypto.

---

## 5. Wallet-Datenmodell

### 5.1 Tabelle `crypto_wallets`

Felder:

- `wallet_id`: eindeutige ID;
- `wallet_name`: z.B. Ledger Main, MetaMask ETH, Kraken, PostFinance Crypto;
- `wallet_type`: Hardware Wallet, Software Wallet, Exchange, Bank/Broker, DeFi, Sonstiges;
- `platform_provider`: z.B. Ledger, MetaMask, Binance, PostFinance, Kraken;
- `network_chain`: optional, z.B. Bitcoin, Ethereum, Solana;
- `owner`: optional;
- `is_active`: active/inactive;
- `notes`;
- `created_at`;
- `updated_at`;
- `last_verified_at`.

### 5.2 Tabelle `crypto_assets`

Felder:

- `asset_id`;
- `coin_name`;
- `symbol`;
- `coingecko_id`;
- `asset_class`: crypto;
- `network_chain_default`: optional;
- `is_stablecoin`: boolean;
- `price_provider_primary`: CoinGecko;
- `price_provider_fallback`: optional;
- `notes`;
- `is_active`.

### 5.3 Tabelle `crypto_holdings`

Felder:

- `crypto_holding_id`;
- `asset_id`;
- `coin_name`;
- `symbol`;
- `coingecko_id`;
- `wallet_id`;
- `quantity`;
- `acquisition_source`: optional, z.B. manual, csv, snapshot, telegram, exchange_export;
- `last_verified_at`;
- `verification_status`: verified, stale, unverified, estimated;
- `legacy_snapshot_value_original`: optional;
- `legacy_snapshot_value_chf`: optional;
- `legacy_snapshot_date`: optional;
- `notes`;
- `created_at`;
- `updated_at`.

Wichtig: `crypto_holdings` ist die aktuelle Bestandsableitung. Änderungen sollen aus Transaktionen oder bestätigten manuellen Korrekturen kommen und im Audit-Log landen.

### 5.4 Tabelle `crypto_transactions`

Felder:

- `crypto_transaction_id`;
- `transaction_id`: Link zum allgemeinen Ledger, falls vorhanden;
- `transaction_type`: crypto_buy, crypto_sell, crypto_transfer, crypto_fee, staking_reward_later, manual_adjustment, initial_snapshot;
- `asset_id`;
- `symbol`;
- `quantity`;
- `price_original`: bei Kauf/Verkauf;
- `currency_original`: z.B. USD, EUR, CHF;
- `gross_amount_original`;
- `fee_quantity`: falls Fee in Coin gezahlt wird;
- `fee_original`: falls Fee in Fiat gezahlt wird;
- `fee_currency`;
- `fx_rate_to_chf`;
- `fx_source`;
- `amount_chf`;
- `from_wallet_id`: für Verkauf/Transfer;
- `to_wallet_id`: für Kauf/Transfer;
- `transaction_datetime`;
- `tx_hash`: optional;
- `source`: dashboard, csv, telegram, manual_correction, snapshot;
- `parse_confidence`: falls aus Telegram geparst;
- `confirmation_status`: draft, pending_confirmation, confirmed, rejected;
- `notes`;
- `created_at`.

### 5.5 Tabelle `crypto_prices`

Felder:

- `crypto_price_id`;
- `asset_id`;
- `coingecko_id`;
- `price_currency`: CHF, USD, EUR;
- `price`;
- `provider`: CoinGecko;
- `provider_timestamp`;
- `fetched_at`;
- `quality_status`: fresh, stale, missing, error;
- `error_message`: optional.

---

## 6. Crypto-Transfers zwischen Wallets

### 6.1 Definition

Ein Crypto-Transfer ist kein Kauf und kein Verkauf. Er verschiebt Bestand zwischen Wallets/Plattformen.

Beispiel:

> Transfer 0.1 BTC von Kraken zu Ledger, Gebühr 0.0001 BTC.

### 6.2 Transaktionstyp

`crypto_transfer`

### 6.3 Pflichtfelder

- Coin;
- Symbol;
- Menge;
- von Wallet;
- zu Wallet;
- Gebühr;
- Gebührwährung bzw. Fee Coin;
- Datum/Uhrzeit;
- TxHash optional;
- Notiz optional.

### 6.4 Buchungslogik

- Menge wird von `from_wallet_id` abgezogen.
- Menge wird zu `to_wallet_id` hinzugefügt.
- Fee reduziert entweder:
  - denselben Coin-Bestand, wenn Fee in Coin gezahlt wurde;
  - Fiat-/Cash-Ledger, wenn Fee in Fiat gezahlt wurde;
  - separates Fee-Feld, falls nur dokumentarisch erfasst.
- Transfer erzeugt Audit-Log-Eintrag.
- Transfer verändert nicht automatisch Gewinn/Verlust, ausser Gebühren werden als Kosten berücksichtigt.

---

## 7. Telegram-Workflows für Crypto

### 7.1 Ziel

Später sollen Crypto-Käufe, Verkäufe und Transfers direkt per Telegram gemeldet werden können. Das System soll daraus eine strukturierte Transaktion vorbereiten und nach Bestätigung speichern.

Wichtig: Telegram ist Eingabekanal, nicht finaler autonomer Buchhalter. Vor finaler Speicherung braucht es eine Bestätigung.

### 7.2 Workflow A: Crypto-Kauf per Telegram

Beispiel:

> Kauf 0.25 ETH auf Wallet Ledger zum Preis 3200 USD, Gebühren 5 USD.

Ablauf:

1. User sendet Telegram-Nachricht.
2. System erkennt Intent: `crypto_buy`.
3. System extrahiert:
   - Coin;
   - Symbol;
   - Menge;
   - Kauf/Verkauf;
   - Preis;
   - Währung;
   - Gebühren;
   - Wallet/Plattform;
   - Datum/Uhrzeit;
   - optionale Notiz.
4. System prüft Pflichtfelder.
5. Bei fehlenden Angaben fragt das System nach:
   - „Welche Wallet/Plattform?“
   - „In welcher Währung war der Preis?“
   - „Soll ich den historischen FX-Kurs automatisch holen?“
6. System erzeugt Transaktionsentwurf.
7. System zeigt Zusammenfassung zur Bestätigung.
8. Nach Bestätigung wird gespeichert:
   - Ledger-Transaktion;
   - Crypto-Transaktion;
   - Wallet-Bestand;
   - Audit-Log;
   - optional Decision-/History-Notiz.

### 7.3 Workflow B: Crypto-Verkauf per Telegram

Beispiel:

> Verkauf 100 SOL von Kraken zu 145 USD, Gebühren 2 USD.

Ablauf analog Kauf, aber:

- Intent: `crypto_sell`;
- `from_wallet_id` ist Pflicht;
- Bestand darf nicht negativ werden, ausser bewusst als Datenqualitätsproblem markiert;
- realisierter P&L wird für MVP optional vorbereitet, aber nicht zwingend final steuerlich korrekt berechnet;
- Audit-Log zwingend.

### 7.4 Workflow C: Crypto-Transfer per Telegram

Beispiel:

> Transfer 0.1 BTC von Kraken zu Ledger, Gebühr 0.0001 BTC.

System erkennt:

- Intent: `crypto_transfer`;
- Coin/Symbol;
- Menge;
- von Wallet;
- zu Wallet;
- Gebühr;
- Datum/Uhrzeit;
- TxHash optional;
- Notiz optional.

Bei fehlenden Angaben:

- „Von welcher Wallet/Plattform?“
- „Zu welcher Wallet/Plattform?“
- „Ist die Gebühr in BTC oder Fiat bezahlt worden?“
- „Soll ich den Transfer jetzt als bestätigt speichern?“

Nach Bestätigung:

- Bestand Quelle reduzieren;
- Bestand Ziel erhöhen;
- Fee verbuchen;
- History/Audit erzeugen.

### 7.5 Parsing- und Sicherheitsregeln

- Automatisch geparste Telegram-Transaktionen starten immer als `pending_confirmation`.
- Bei Unsicherheit wird nachgefragt.
- Kein Speichern ohne Bestätigung.
- Parser speichert `parse_confidence` und Originaltext.
- Originaltext wird intern als Audit-Evidence gespeichert, aber nicht in Git oder externe Logs geschrieben.
- Finanzdaten werden nicht in fremde Dienste geschickt, ausser der Nutzer genehmigt einen konkreten lokalen/privaten Verarbeitungsweg.

---

## 8. History- und Audit-Log

### 8.1 Ziel

Jede Änderung am Portfolio, Crypto-Bestand, Watchlist, Ledger oder Reportstatus muss nachvollziehbar sein.

Das System soll später beantworten können:

- Was wurde geändert?
- Wann wurde es geändert?
- Von welcher Quelle kam die Änderung?
- War es manuell, CSV, Dashboard, Telegram oder Korrektur?
- Wurde es bestätigt?
- Welche Werte waren vorher/nachher relevant?
- Warum wurde es geändert?

### 8.2 Tabelle `audit_log`

Felder:

- `audit_id`;
- `timestamp`;
- `source`: dashboard, csv_import, telegram, manual_correction, system_job, snapshot_import;
- `action`: buy, sell, transfer, correction, dividend, snapshot, import, delete, verify, report_generated, alert_acknowledged;
- `entity_type`: transaction, crypto_holding, wallet, instrument, account, watchlist_item, report, alert;
- `entity_id`;
- `affected_asset_id`;
- `affected_instrument_id`;
- `affected_wallet_id`;
- `old_values_json`;
- `new_values_json`;
- `user_text_note`;
- `original_input_text`: z.B. Telegram-Text, optional und vertraulich;
- `confirmed`: boolean;
- `confirmation_timestamp`;
- `auto_parsed`: boolean;
- `parse_confidence`: optional;
- `created_by`: user/system;
- `quality_status`;
- `related_decision_id`: optional.

### 8.3 Regeln

- Jede Buchung erzeugt Audit-Eintrag.
- Jede Korrektur erzeugt Audit-Eintrag mit alten und neuen Werten.
- Löschungen werden möglichst als Storno/Korrektur modelliert, nicht als unsichtbares Löschen.
- CSV-Import erzeugt Import-Session und Einzel-Audit-Events.
- Telegram-Parsing erzeugt Draft-Audit vor Bestätigung und finalen Audit nach Bestätigung.

---

## 9. Crypto-PDF-Report

### 9.1 Ziel

Der Crypto-PDF-Report dient der Übersicht und Dokumentation des Crypto-Bestands. Er ist nicht zwingend eine vollständige Steuererklärung.

### 9.2 Inhalte

Der Report enthält:

- Datum und Uhrzeit der Erstellung;
- Gesamtwert Crypto in CHF;
- optionale Gesamtwerte in USD/EUR;
- Aufteilung nach Coin;
- Aufteilung nach Wallet/Plattform;
- Menge pro Coin;
- Menge pro Wallet;
- aktueller Kurs;
- Wert pro Wallet;
- Gesamtwert pro Coin;
- Datenquelle der Kurse;
- Preis-Zeitstempel;
- Hinweis bei fehlendem/veraltetem Kurs;
- optional Notizen pro Wallet/Coin;
- letzte Verifikation pro Wallet/Bestand;
- Datenqualitätsabschnitt.

### 9.3 Reportstruktur

1. Titelblatt / Kopfbereich
   - Reportname;
   - Erstellungszeitpunkt;
   - Basiswährung CHF;
   - Datenstand.
2. Executive Summary
   - Gesamtwert CHF;
   - Anzahl Coins;
   - Anzahl Wallets/Plattformen;
   - Datenqualitätsstatus.
3. Coin-Übersicht
   - Coin;
   - Symbol;
   - Gesamtmenge;
   - aktueller Kurs;
   - Gesamtwert CHF;
   - Anteil am Crypto-Portfolio.
4. Wallet-Übersicht
   - Wallet/Plattform;
   - Wallet-Typ;
   - Anzahl Coins;
   - Gesamtwert CHF;
   - letzte Verifikation.
5. Detail je Coin
   - Wallet-Aufteilung;
   - Mengen;
   - Werte;
   - Notizen;
   - Warnungen.
6. Datenqualität
   - fehlende CoinGecko-IDs;
   - veraltete Preise;
   - nicht verifizierte Wallets;
   - Import-/Snapshot-Hinweise.

### 9.4 Exportformate

MVP 1:

- PDF;
- Markdown;
- optional HTML.

PDF-Erstellung über Streamlit-Button, intern per Report-Template und PDF-Renderer.

---

## 10. Aktualisierte Dashboard-Seiten

### 10.1 Command Center

Startseite mit:

- Gesamtwert CHF;
- Tagesbewegung;
- kritische Alerts;
- Datenqualitätswarnungen;
- neue/veraltete Preise;
- wichtige Portfolioänderungen;
- Schnellzugriff auf Reports;
- Schnellzugriff auf Crypto-Seite.

### 10.2 Gesamtportfolio

- Plattformübersicht;
- Assetklassen;
- Aktien/ETFs;
- Crypto aggregiert;
- Cash;
- Total Return CHF, soweit Datenbasis vorhanden;
- FX-Effekte.

### 10.3 Plattform-/Depotansichten

Tabs:

- Gesamt;
- Raiffeisen;
- PostFinance;
- True Wealth;
- Crypto.

### 10.4 Aktien-/ETF-Portfolio

- Positionen;
- Einstand, Marktwert, P&L;
- FX-Effekt;
- Kategorie Core/Opportunity;
- einfache Trend-/Risk-/Fit-Scores später oder minimal MVP;
- Dividendenübersicht optional.

### 10.5 Neue Seite: Crypto

Pflichtinhalte:

- Gesamtwert Crypto in CHF;
- optionale USD/EUR Umschaltung;
- Coins nach Gesamtwert;
- Coins nach Wallet;
- Wallet-Übersicht;
- letzte Änderungen;
- Kauf-/Verkaufs-/Transfer-History;
- Button: Crypto-PDF erstellen;
- Button: Bestand manuell verifizieren;
- Warnungen bei fehlenden CoinGecko-IDs;
- Warnungen bei veralteten Preisen;
- CSV Import/Export für Crypto-Bestände;
- manuelle Erfassung von Kauf/Verkauf/Transfer.

### 10.6 Transactions / Ledger

- alle Transaktionen;
- Filter nach Assetklasse, Plattform, Konto, Wallet, Transaktionstyp;
- manuelle Korrekturen;
- Audit-Link je Transaktion.

### 10.7 Watchlist

- Investment Pipeline;
- Zielpreise;
- gewünschte Positionsgrösse;
- Trigger;
- Quellen;
- Übernahme ins Portfolio.

### 10.8 Reports

- Sofortreport Gesamt;
- Portfolio-Report;
- Crypto-Bestands-PDF;
- Watchlist-Report;
- einfache Monatsübersicht.

### 10.9 Alerts

- Info/Wichtig/Kritisch;
- Datenqualität;
- grosse Bewegungen;
- fehlende FX-/Preis-Daten;
- veraltete Wallet-Verifikation.

### 10.10 History / Audit

- Timeline aller Änderungen;
- Filter nach Quelle;
- Filter nach Aktion;
- Details alter/neuer Werte;
- Bestätigungsstatus;
- Telegram-Parsing-Historie.

---

## 11. Aktualisierte MVP-1-Priorisierung

### 11.1 MVP 1 Muss-Funktionen

1. Plattform-/Depotübersicht:
   - Raiffeisen;
   - PostFinance;
   - True Wealth;
   - Crypto.
2. Initial-Snapshot aus vorhandenen Auszügen.
3. Manuelle Eingabe im Dashboard.
4. CSV-Import/Export.
5. CHF-Basiswährung mit historischer FX-Logik.
6. Portfolioübersicht Aktien/ETFs.
7. Crypto-Inventory mit Wallet-Struktur.
8. Crypto-Bestands-PDF.
9. Watchlist.
10. History-/Audit-Log.
11. Einfache Reports.
12. Einfache Alerts für Datenqualität und grosse Bewegungen.

### 11.2 MVP 1 Soll-Funktionen

- manuelle Wallet-Verifikation;
- CoinGecko-Preisupdate;
- fehlende CoinGecko-ID Warnung;
- Markdown/HTML zusätzlich zu PDF;
- Telegram-Workflow als spezifizierter, aber eventuell noch nicht implementierter nächster Schritt;
- einfache Trend-/Risk-/Fit-Anzeige, falls ohne Verzögerung möglich.

### 11.3 Nicht MVP 1

- vollständiger Steuerreport für Aktien/ETFs;
- komplexe Analysten-/News-Auswertung;
- Opportunity Scanner;
- automatische Broker-Anbindungen;
- automatische Orderausführung;
- komplexe LLM-Analysen;
- vollständige Crypto-Steuerlogik;
- automatische On-chain-Abfragen;
- automatische Exchange-API-Anbindungen.

---

## 12. CSV-Formate v0.3 Ergänzung Crypto

### 12.1 `crypto_wallets.csv`

```text
wallet_id,wallet_name,wallet_type,platform_provider,network_chain,owner,is_active,last_verified_at,notes
```

### 12.2 `crypto_holdings_initial.csv`

```text
snapshot_date,wallet_name,wallet_type,platform_provider,network_chain,coin_name,symbol,coingecko_id,quantity,legacy_snapshot_value_original,legacy_snapshot_value_chf,legacy_snapshot_currency,last_verified_at,notes
```

Regeln:

- `quantity` ist Pflicht.
- `symbol` ist Pflicht.
- `coingecko_id` ist stark empfohlen.
- Legacy-Werte dürfen nicht als aktuelle Bewertung verwendet werden.
- Fehlende CoinGecko-ID erzeugt Datenqualitätswarnung.

### 12.3 `crypto_transactions.csv`

```text
transaction_type,datetime,coin_name,symbol,coingecko_id,quantity,price_original,currency_original,fee_quantity,fee_original,fee_currency,from_wallet,to_wallet,fx_rate_to_chf,fx_source,tx_hash,notes
```

Transaktionstypen:

- crypto_buy;
- crypto_sell;
- crypto_transfer;
- crypto_fee;
- staking_reward_later;
- manual_adjustment;
- initial_snapshot.

---

## 13. Datenqualitätsregeln v0.3

### 13.1 Crypto-spezifische Warnungen

Info:

- Wallet-Bestand manuell verifiziert;
- Crypto-PDF generiert;
- CoinGecko-Preis erfolgreich aktualisiert;
- neuer Wallet-Eintrag erstellt.

Wichtig:

- CoinGecko-ID fehlt;
- Preis älter als 24h;
- Wallet seit >30 Tagen nicht verifiziert;
- Bestand durch Telegram geparst, aber noch nicht bestätigt;
- Crypto-Transfer unvollständig dokumentiert.

Kritisch:

- Preis für relevante Coin-Position nicht verfügbar;
- negativer Wallet-Bestand nach Transaktion;
- Transfer ohne Ziel- oder Quellwallet;
- widersprüchliche Menge zwischen Snapshot und Ledger;
- Transaktion ohne Pflicht-FX bei Fiat-Wert;
- Audit-Log konnte nicht geschrieben werden.

### 13.2 Aktien/ETF Datenqualität

Weiterhin relevant:

- fehlender historischer FX-Kurs;
- fehlende Gebühren;
- fehlendes Transaktionsdatum;
- Snapshot statt vollständiger Historie;
- fehlende ISIN/Ticker-Zuordnung.

---

## 14. Reduzierte Rolle des Steuer-Moduls

### 14.1 Aktien/ETFs

Das System speichert Dividenden-/Ausschüttungsdaten, um Transparenz und Plausibilitätskontrolle zu ermöglichen.

MVP 1 muss aber keinen vollständigen Steuerexport für Aktien/ETFs liefern.

Anzeigen:

- Dividenden/Ausschüttungen pro Instrument;
- Brutto/Nettodividende;
- Schweizer Verrechnungssteuer;
- ausländische Quellensteuer;
- Zahlungsdatum;
- Konto/Depot;
- Währung;
- optional CHF-Gegenwert.

Nicht MVP 1:

- vollständiges Schweizer Steuerdossier;
- ESTV/ICTax-Abgleich;
- automatische Steuerformular-Erstellung;
- rechtlich belastbare Steuerberechnung.

### 14.2 Crypto

Crypto-Bestandsreport ist priorisiert, aber nicht als vollständige Steuererklärung zu deklarieren.

Später möglich:

- Jahresendwert pro Coin;
- Transaktionshistorie;
- realisierte Gewinne/Verluste;
- Gebühren;
- Staking Rewards;
- Export für Steuerberater/Unterlagen.

---

## 15. Offene Fragen für v0.4

1. Welche Wallets/Plattformen sollen im Crypto-Modul initial angelegt werden?
2. Welche Wallet-Namen sollen als kanonisch gelten, z.B. Ledger, Kraken, PostFinance, MetaMask?
3. Sollen Wallet-Adressen gespeichert werden oder aus Sicherheitsgründen zunächst nicht?
4. Soll der Crypto-PDF-Report echte Wallet-Namen zeigen oder optional anonymisierte Labels?
5. Welche Fiat-Währungen sollen für Crypto-Ansicht neben CHF zuerst unterstützt werden: USD, EUR oder beide?
6. Welche CoinGecko-ID-Mapping-Regeln sollen gelten, wenn Symbol nicht eindeutig ist?
7. Wie streng soll das System negative Wallet-Bestände blockieren?
8. Soll Telegram-Erfassung in MVP 1 bereits umgesetzt werden oder als MVP 1.1?
9. Welche Bestätigungssyntax soll Telegram verwenden: „Ja speichern“, Buttons oder Dashboard-Freigabe?
10. Soll Audit-Log unveränderlich append-only sein oder mit Admin-Korrektur möglich?
11. Welche Aufbewahrungsfrist gilt für Audit-Originaltexte aus Telegram?
12. Soll das System Staking Rewards in v0.4 vorbereiten oder weiter zurückstellen?
13. Welche erste Report-Vorlage ist wichtiger: Gesamtportfolio oder Crypto-Bestand?
14. Soll der Initial-Snapshot pro Plattform manuell geprüft werden, bevor er als Startbestand übernommen wird?
15. Welche Daten dürfen in lokalen Logs stehen, und welche müssen maskiert werden?
16. Soll später eine verschlüsselte lokale Datenbank oder verschlüsseltes Backup eingeplant werden?
17. Soll die Git-Sicherung auf GitHub privat oder zusätzlich lokal/verschlüsselt erfolgen?

---

## 16. Abschluss v0.3

v0.3 korrigiert die Prioritäten: Das System bleibt ein Finanzmanagement- und Entscheidungsunterstützungssystem, aber MVP 1 wird pragmatischer und schärfer.

Die wichtigsten Änderungen:

- Steuerunterlagen für Aktien/ETFs werden zurückgestuft.
- Crypto-Inventory wird priorisiert.
- Wallet-Struktur wird Teil des Datenmodells.
- Crypto-Bestands-PDF wird MVP-relevant.
- Telegram-Workflows für Kauf, Verkauf und Transfer werden fachlich spezifiziert.
- Jede Änderung erhält ein History-/Audit-Log.
- Dashboard bekommt eine eigene Crypto-Seite.

Damit ist die nächste Version bereit für v0.4: konkrete Feldvalidierungen, UI-Flows, technische Modulgrenzen und Implementierungsplan – weiterhin erst nach Freigabe und ohne Finanzdaten in Git. Genau so vermeidet man, dass aus einem Finanzsystem versehentlich eine Excel-Tabelle mit besserer Beleuchtung wird.