Deine eigene Finanzanwendung mit Lovable und KI bauen – so geht’s richtig

Dein Finanzteam möchte Kontostände, monatlichen Cashflow und auffällige Kosten auf einen Blick sehen. Ein KI-Coding-Tool wie Lovable hilft dir, die Oberfläche samt Diagrammen und Filtern zu bauen. Ein überschaubares internes Dashboard eignet sich gut als erstes Vibecoding-Projekt.

Echte Bankdaten brauchen klare Zugriffsregeln. Die Kontoflux.io-API verbindet deine eigenen Bankkonten, auch Geschäftskonten, mit deiner Anwendung. Dein Backend entscheidet, wer welche Daten sehen darf. Eine vermeintlich private Oberfläche allein schützt sie nicht.

Ein internes Finanzdashboard als Beispiel

Die Teamleitung braucht Monatssummen und Ausgabenkategorien. Das Finanzteam prüft zusätzlich einzelne Buchungen. Ein Mitarbeiter-Login sollte deshalb nicht automatisch deine gesamte Kontohistorie freigeben.

Diese Svelte-Demo enthält nur erfundene Namen und Beträge. Sie ruft keine Bank oder API auf. Die Filter zeigen die Bedienung; echte Zugriffskontrollen gehören ins Backend.

---
import FinanceDashboardDemo from '../../components/FinanceDashboardDemo.svelte';
---

<!-- Diese Komponente enthält ausschließlich Beispieldaten. -->
<FinanceDashboardDemo client:visible />

Was Kontoflux.io bei der Bankanbindung übernimmt

Kontoflux.io ermöglicht kontrollierten, ausschließlich lesenden Zugriff auf deine verbundenen Konten. Du wählst die Konten aus und bestätigst die Verbindung über finAPI mit dem Anmeldeverfahren deiner Bank.

Verlangt deine Bank eine Zwei-Faktor-Authentifizierung (2FA), bestätigst du mit einer echten Banking-TAN oder ihrer App. Verfahren und erneute Freigaben bestimmt die Bank. Dein Dashboard erfasst keine Bankzugangsdaten. Mehr dazu findest du unter Sicherheit bei Kontoflux.io.

Die API liest Konten, Salden, Buchungen und Kategorien, ohne Zahlungen auszulösen. Diese Daten können trotzdem Gehälter, Lieferanten, Kunden und Rücklagen offenlegen. Die Bank-2FA bestätigt die Bankanbindung. Einzelne API-Abfragen erfordern keine neue TAN. Die Bank-2FA ersetzt keine Mitarbeiterberechtigungen und schützt keinen offengelegten Schlüssel.

Warum der API-Schlüssel nicht ins Frontend darf

Schlüssel in Komponenten, Browser-Code, Local Storage oder öffentlichen Umgebungsvariablen sind auslesbar. Eine Frontend-Datei namens .env schützt keinen Schlüssel, der im ausgelieferten JavaScript landet. Auch Netzwerkanfragen können ihn offenlegen.

Nutzer können den Schlüssel aus den Entwicklertools kopieren und alle damit freigegebenen Konten und Buchungen abrufen. Versteckte Tabellen, deaktivierte Exporte oder Rollenprüfungen im Frontend verhindern das nicht.

Speichere den Schlüssel auf dem Server. Dein eigener Endpunkt, etwa /api/finance/summary, prüft Identität und Berechtigungen und liefert nur erlaubte Felder zurück. CORS beschränkt Browser-Ursprünge, ersetzt aber keine Berechtigungsprüfung.

Prüfe Berechtigungen zwischen Oberfläche und API

1. MitarbeiterMeldet sich in deiner internen App an.
2. Dein BackendPrüft Identität, Rolle und erlaubte Konten.
3. Kontoflux.io-APILiest die vom Server-Schlüssel freigegebenen Daten.
4. DashboardErhält nur das erlaubte Ergebnis.

Die Authentifizierung stellt die Identität fest. Die Autorisierung prüft den Zugriff auf Workspace, Konto und Detailtiefe. Dein Backend braucht beides bei jeder Anfrage.

Lies Berechtigungen aus vertrauenswürdiger Serverkonfiguration und Mitgliedschaften. Gleiche angefragte Konten mit dieser Freigabe ab. Vertraue niemals Rollen, Workspace-IDs oder API-Zieladressen aus dem Browser.

Die Teamleitung könnte nur diese Summen erhalten, ohne Namen, IBANs oder Buchungstexte. Das Beispiel mit erfundenen Werten zeigt deinen eigenen Endpunkt, nicht das Antwortformat von Kontoflux.io. Beträge sind ganzzahlige Eurocent.

{
  "period": "2026-08",
  "currency": "EUR",
  "cashInMinor": 4280000,
  "cashOutMinor": 3175000,
  "netCashflowMinor": 1105000,
  "dataThrough": "2026-08-31",
  "complete": true
}

Prüfe den Zugriff auf Buchungsdetails gesondert. Bloßes Weiterleiten mit einem geheimen Schlüssel schützt deine Daten nicht. Trenne Caches nach Workspace und Berechtigungen. Prüfe auch zwischengespeicherte Antworten und verhindere mit privaten Cache-Einstellungen die Weitergabe zwischen Nutzern.

So helfen dir Supabase und Lovable

Supabase Edge Functions als Backend

Supabase Edge Functions können Kontoflux.io aus deinem Backend aufrufen. Nutze serverseitige Secrets und die Authentifizierung für Edge Functions. Rollen, erlaubte Konten und zurückgegebene Felder prüft weiterhin dein Code.

Speichert Supabase Postgres deine Daten, aktiviere und teste Row Level Security (RLS) für alle aus dem Browser erreichbaren Tabellen. Service-Role-Zugänge umgehen RLS; dein Backend muss den Zugriff dann selbst prüfen. Öffentliche Supabase-Keys und geheime Kontoflux.io-Schlüssel sind nicht austauschbar.

Mit Lovable die Anwendung bauen

Lovable unterstützt dich beim Bau des Dashboards. Die Supabase-Anbindung liefert Anmeldung, Datenspeicherung und Edge Functions. Verlange ausdrücklich geschützte Serverfunktionen für Kontoflux.io-Aufrufe und Server-Secrets für den Schlüssel.

Prüfe erzeugte Funktionen, Berechtigungen und Antwortfelder vor der Anbindung echter Konten. Lovables Sicherheitshinweise erklären die Aufgaben des Backends. Lovable baut die App; deine Supabase Edge Functions kontrollieren den API-Zugriff. Die separate Svelte-Demo zeigt eine mögliche Oberfläche. Das Backend-Prinzip funktioniert auch mit anderen Frameworks.

Gib der KI klare Zugriffsregeln mit

Starte mit Beispieldaten und festgelegten Berechtigungen. So könnte dein Auftrag an das Coding-Tool aussehen:

Lass die Sicherheitsprüfungen von einem Entwickler kontrollieren. Lege dann eine eigene Integration mit den benötigten Konten und Leserechten an. Nutze die API-Anleitung und API-Referenz. Echte Bankdaten und Zugangsschlüssel gehören nicht in KI-Prompts.

Was kannst du mit der API noch bauen?

Nutze Salden, Buchungen, Kategorien und Suche als Grundlage. Deine Anwendung ergänzt Geschäftsregeln und weitere Daten:

• Liquiditätsübersichten über deine eigenen Konten, getrennt nach Währung.
• Monatsberichte mit Einnahmen, Ausgaben und separat ausgewiesenen Umbuchungen.
• Ausgabenübersichten nach Abteilungen und Budgets.
• Rechnungsabgleich über Referenzen und Beträge, mit Prüfliste für unklare Treffer.
• Kostenprüfungen für mögliche Abos und veränderte Lieferantenzahlungen.
• Berichte und Warnungen bei Grenzwerten, vom Backend an berechtigte Empfänger gesendet.

Abo-Erkennung und Prognosen brauchen eigene Logik. Matching findet mögliche Zahlungen; deine Regeln entscheiden, ob eine Rechnung bezahlt ist. Zeige Datenstand und Importabdeckung an. Eine API-Antwort ist nicht automatisch eine Live-Ansicht der Bank.

Best Practices vor der Anbindung echter Bankdaten

1. Schlüssel gehören in Backend-Secrets, niemals in Browser-Code, öffentliche Build-Variablen, Repositories, Screenshots oder KI-Prompts.
2. Vergib nur nötige Rechte für ausgewählte Konten. Widerrufe ungenutzte Schlüssel und ersetze offengelegte.
3. Prüfe Identität und Berechtigungen bei jeder Anfrage, auch für Exporte und Caches: Workspace, Konto und erlaubte Details.
4. Liefere nur benötigte Daten. Berechne Summen auf dem Server und lasse unberechtigte Buchungsdetails weg.
5. Schütze gespeicherte Kopien mit RLS, Speicherregeln und Löschfristen. Prüfe Backups; Service-Zugangsdaten bleiben auf dem Server.
6. Entwickle mit Beispieldaten. Gib externe Datenverarbeiter bewusst frei. Schlüssel und Buchungen gehören nicht in Logs.
7. Nutze präzise Geldberechnungen: kleinste Währungseinheiten als Ganzzahlen oder Dezimalarithmetik. Trenne Währungen; Umbuchungen sind keine Einnahmen.
8. Prüfe die Vollständigkeit der Daten: Pagination, Dubletten, Buchungsdaten und Historie. Markiere veraltete Importe; Fehler sind keine Nullsalden.
9. Setze Anfragelimits und Zeitlimits, wiederhole Aufrufe kontrolliert und protokolliere Zugriffe ohne Buchungsinhalte.
10. Teste das Backend direkt: ohne Anmeldung, mit entzogenem Zugang und manipulierten Konto-IDs. Prüfe Browser-Code und Antworten auf Datenlecks.