Du öffnest deine Banking-App, willst schnell sehen, wo dein Geld landet – und landest in drei verschiedenen Menüs, ohne echte Übersicht zu haben. Apps wie Finanzguru versprechen Rettung, aber dafür sollen deine Finanzdaten irgendwohin hochgeladen werden, wo du nicht siehst, was damit passiert. Das war für mich der Moment, eine Entscheidung zu treffen: Entweder ich akzeptiere diese Kompromisse, oder ich baue mir das selbst.
Also habe ich angefangen zubauen. Ein Dashboard mit vollständiger Datenhoheit, automatischer Kategorisierung und einem Desktop-First-Ansatz, der nicht auf Mobile-Kompromisse setzt. Was als Projekt für mein erstes größeres Laravel-System anfing, wurde zur Auseinandersetzung mit echten FinTech-Problemen: chaotische Bankdaten, Datensicherheit und Automatisierung ohne externe APIs.
Das Problem mit fremden Lösungen
Jede Banking-App zeigt Umsätze, aber keine von ihnen bietet das, was ich brauchte: eine Gesamtübersicht über mehrere Konten (Giro, Kreditkarte, Sparkonten) an einer Stelle. Und das mit dem Detail-Level, den nur ein größerer Bildschirm ermöglicht. Desktop-Analysen zu Finanzzielen sind einfach anders als auf 5 Zoll zu schwenken und zu scrollen.
Hinzu kam der Datenschutz-Aspekt. Wer meine Transaktionen bekommt, was damit gemacht wird, welche Analysen laufen – keine dieser Apps macht das transparent. Also habe ich die radikalere Frage gestellt: Was brauche ich technisch, um das selbst zu kontrollieren?
Die Architektur-Entscheidungen
Tech-Stack:
- Laravel (Backend, Geschäftslogik, Verschlüsselung)
- React (Frontend, interaktive Analysen)
- SQL-Datenbank (strukturierte Transaktionsdaten)
Die Kombination war bewusst gewählt: Laravel bringt built-in Sicherheitsfeatures mit (Verschlüsselung, Validierung, Middleware), React ermöglicht die komplexen Visualisierungen ohne Seitenneuladen. Externe Tools wie n8n für Workflow-Automatisierung habe ich bewusst nicht gewählt – nicht aus Purismus, sondern aus praktischem Grund: Sobald sensible Finanzdaten die App verlassen, wird Datenschutz zum Problem. Eine API dafür zu bauen wäre ein zusätzliches Sicherheitsrisiko gewesen.
Die CSV-Import-Hölle
Der erste echte Problemfall: Die Daten. Jede Bank exportiert ihr CSV-Format selbst. Sparkasse nutzt anderes Format als Tomorrow Bank. Dezimaltrennzeichen: manchmal Komma, manchmal Punkt. Datumsformat: DD.MM.YYYY oder YYYY-MM-DD? Und wie wird eine Ausgabe gekennzeichnet – mit Minuszeichen oder in einer separaten „Soll“-Spalte?
Manuell jede Bank mappen wäre möglich, aber nicht skalierbar. Also entstand eine intelligente Importstrecke.
Automatische Schema-Erkennung statt manuelles Chaos
Das System analysiert die hochgeladene CSV und vergleicht sie mit hinterlegten Bank-Schemata. Für Sparkasse und Tomorrow sind Templates definiert – erkennt das System eines davon, lädt es die richtige Konfiguration.
Falls keine Übereinstimmung existiert, greift der manuelle Modus: Nutzer mappen Spalten zu Datenfeldern (Datum, Empfänger, Betrag, Beschreibung). Eine Vorschau zeigt, wie die Daten später aussehen. Erst dann werden sie in die Datenbank geschrieben. Das bedeutet: Nach dem ersten Import einer neuen Bank speichert das System deren Schema, künftige Importe laufen vollautomatisch.
Datensicherheit als fundamentales Feature
Wir sprechen hier über Kontostände, IBAN, Transaktionspartner – Informationen, die extremen Schutz benötigen. Meine Lösung: AES-256-CBC Verschlüsselung für alle sensiblen Felder.
Das ist nicht optional und nicht nur auf die Datenbank angewendet – die Verschlüsselung läuft transparent über Laravels Encryption Facade. Der Vorteil: Entwickler müssen nicht selbst Kryptographie implementieren (Fehlerquelle!), stattdessen wird Verschlüsselung und Fehlerbehandlung vom Framework übernommen.
Verschlüsselte Felder:
- IBANs und Kontoinformationen
- Beträge (ja, auch die)
- Empfänger und Absender
- Transaktionsbeschreibungen
Ein direkter Datenbankzugriff zeigt nur Cipher-Text. Entschlüsselt werden Daten erst in der App, unmittelbar vor der Anzeige. Das bedeutet: Selbst wenn jemand die Datenbank kopiert, hat er nur verschlüsselte Strings.
Automatische Kategorisierung – oder: Warum ich 250 Transaktionen nicht manuell mappen wollte
Nach dem Import liegt eine große Tabelle vor: Transaktionen, aber ohne Kategorien. Wäre jede der 250 Transaktionen manuell zuzuordnen (Lebensmittel, Wohnen, Shopping, Medien, Transport), wäre das zeitlich nicht skalierbar.
Also nächste Baustelle aufmachen.
Die Automations-Engine
Die Engine basiert auf einfachen, aber effektiven Regeln. Eine Regel: Wenn „Empfänger“ enthält „Edeka“, „Lidl“, „Aldi“ oder „Kaufland“, dann Kategorie „Lebensmittel“. Oder: Wenn Empfänger ist „Netflix“, „Spotify“, „Disney+“, dann „Medien“.
Unterstützte Operatoren:
- „ist gleich“
- „enthält“
- „beginnt mit“
- „endet mit“
Mehrere Bedingungen lassen sich kombinieren. Regeln können entweder bei jedem Import automatisch laufen oder manuell auf Knopfdruck. Der entscheidende Vorteil: Diese Integration bleibt innerhalb der App. Keine externe API, keine Datenübertragung – die Automation läuft direkt in Laravel als Background Job nach jedem Import.
Das System kommt mit Default-Regeln für häufige Transaktionspartner. Aber Nutzende können eigene Regeln definieren. Ein neuer Lieblingsladen? Neue Regel. Nach kurzer Zeit haben sich die meisten Transaktionen selbst kategorisiert, nur noch Edge Cases brauchen Nachbearbeitung.
Analysen: Das eigentliche Ziel
Saubere Daten sind nur Mittel zum Zweck. Das Ziel: Verstehen, wohin das Geld wirklich fließt.
Zeitliche Flexibilität
Ein zentraler Datumsselektor mit Quick-Select-Optionen:
- Gesamter verfügbarer Zeitraum
- Letzter Monat, dieser Monat
- Letzte 3, 6 oder 12 Monate
- Dieses Jahr, letztes Jahr
- Spezifisches einzelnes Datum
Diese Flexibilität ermöglicht sowohl große Trends als auch Details zu sehen.
Visualisierungen statt Tabellen
Ein Donut-Diagramm zeigt die Übersicht: Gesamtausgaben, Ersparnisse, verbleibendes Budget auf einen Blick. Ein Breakdown nach Kategorien wird prozentual dargestellt – Wohnen 25,1%, Sparen und Investieren 16,8%, Shopping 12,6%, Lebensmittel 17%.
Das Spannendste: Monatliche Vergleiche nebeneinander. Januar vs. Februar als gestapelte Balkendiagramme. Wo wurde mehr ausgegeben? Welche Kategorien sind gestiegen?
War Shopping im Januar noch wild, im Februar aber deutlich reduziert? Sind Lebensmittelkosten konstant oder volatil? Diese visuellen Vergleiche ermöglichen datenbasierte Finanzentscheidungen – nicht Bauchgefühl.
Was lief nicht optimal – und was ich daraus gelernt habe
Die größten Herausforderungen waren nicht technisch, sondern konzeptionell.
Zuerst dachte ich, dass die Datenbankstruktur das komplexeste Element ist. Tatsächlich war es die Datenharmonisierung. Jede Bank hat ihre eigenen Konventionen – das ist nicht zu unterschätzen. Der Import-Flow musste iterativ überarbeitet werden, nachdem erste Tests mit echten CSVs zeigten, dass die automatische Erkennung Edge Cases nicht abdeckte.
Die Rule-Engine war auch nicht beim ersten Mal perfekt. Manche Transaktionen erfüllen mehrere Regeln gleichzeitig – hier musste ich eine Priorisierungslogik einbauen. Später kam die Erkenntnis, dass „Smart Defaults“ hilfreicher sind als zu viele Optionen für Nutzer.
Bei der Verschlüsselung hätte ich früher merken sollen, dass ich zwar Laravels built-in Features nutze, aber noch nicht eingehend genug die Performance-Implikationen überprüft habe. Große Datasets mit AES-256 zu verarbeiten ist nicht instant, sondern braucht Optimierung (z.B. Selective Encryption statt alles zu verschlüsseln).
Das Lernen aus diesen Punkten:
Datenquellen sind chaotischer als Businesslogik. Das unterschätzen viele Entwickler. Jede externe Datenquelle hat ihre eigenen Quirks.
Integration schlägt Orchestrierung. Externe Workflow-Tools hätten die Lösung vereinfacht, aber verschlüsselte Daten aus der App zu bringen ist die echte Komplexität. Integriert zu sein bedeutet: Die Automation läuft sicherer.
Defaults sind mächtiger als Flexibilität. 80% der Nutzer wollen wahrscheinlich nur, dass das System automatisch funktioniert. Die restlichen 20% brauchen Custom-Rules – aber nicht alle Nutzer.
Performance früh testen. Mit 250 Transaktionen merkt man Verschlüsselungs-Overhead nicht. Bei 5000 wird es relevant.
Ausblick: Was noch fehlt
Beta Tester
Noch hat die App genau einen Nutzer: mich. Ein Deployment und anschließendes Einladen von Family & Friends wäre eine gute Gelegenheit, die UX und das UI noch weiter zu testen und zu iterieren.
Automatische Bankanbindung
Die FinAPI würde den nächsten Schritt bedeuten: echte API-Verbindung zu Banken, Echtzeit-Synchronisation, kein manueller CSV-Import mehr. Die Herausforderung: Das erfordert noch intensivere Auseinandersetzung mit Datensicherheit bei externen Verbindungen. Aber es wäre der logische nächste Schritt für weniger Reibung.
KI für strukturierte Insights
Mit den strukturierten Daten könnten konkrete KI-Analysen arbeiten. Nicht vage Vorschläge, sondern: „Du gibst im Durchschnitt 47€ pro Lebensmitteleinkauf aus. In Kategorie X könntest du 12% sparen.“ Kombiniert mit Kassenzettel-Scans wäre sogar granulares Produkt-Level-Tracking möglich.
Haushaltskonten
Verbinden von zwei Accounts zu einem gemeinsamen Haushaltskonto (entweder vollständig oder Granulat ausgewählt) könnte die Übersicht über mehrere Konten von mehreren Personen ermöglichen.
Budgetplanung und Prognosen
Auf Basis historischer Daten: Warnungen bei Budget-Überschreitungen, Prognosen für kommende Monate, vielleicht sogar Vergleiche mit anonymisierten Durchschnittswerten ähnlicher Personen.
Fazit
Das Projekt ist nicht einfach „ein Finanz-Dashboard“. Es ist ein Projekt mit steiler Lernlkurve in der Technologie und wie sich UX im Laufe der Zeit selbstständig weiterentwickeln kann. Und plötzlich baut man ein kleines FinTech-Systems mit intelligenter Datenspeicherung, Automatisierung und Analysen – alles unter vollständiger Kontrolle.
Die größten Erkenntnisse liegen nicht in der Technologie selbst, sondern darin, wie man chaotische externe Daten in ein sauberes, internes System transformiert. Und dass Datensicherheit nicht später gelöst wird, sondern von Anfang an Teil der Architektur sein muss.
Für mich ist es gleichzeitig ein Portfolio-Projekt geworden – ein Beweis, dass ich nicht nur code schreibe, sondern Systeme baue, die ein echtes Problem lösen.