Vibe Coding einer FinTech-App: Warum das besonders gefährlich ist

Ein Gründer in Frankfurt baut über ein Wochenende mit Cursor und Claude ein Payment-Feature. Der Code sieht sauber aus, die Tests laufen durch, die Logik fühlt sich richtig an. Drei Monate nach dem Launch stellt er fest, dass sich durch kumulierte Rundungsfehler Abweichungen von 0,01 Euro über zehntausende Transaktionen angesammelt haben. Die Gesamtabweichung beträgt 847 Euro. Schlimmer noch: Die Transaktionslogs enthalten nicht genug Informationen, um zu rekonstruieren, welche Transaktionen betroffen sind.

Das ist kein hypothetisches Szenario. Es ist die Kategorie von Problem, die FinTech fundamental vom Vibe Coding einer Content-Plattform, eines Task-Managers oder selbst eines E-Commerce-Shops unterscheidet. In diesen Domänen produziert KI-generierter Code, der "größtenteils funktioniert", Bugs, die Nutzer nerven. In Finanzsoftware bewegen Bugs, die "größtenteils funktionieren", Geld falsch, setzen Dich regulatorischen Bußgeldern aus und machen Dich im schlimmsten Fall zum Beteiligten an Betrugsermöglichung.

Die Risiken sind spezifisch, vorhersehbar und besonders gefährlich, weil sie sich still und leise aufsummieren. Und sie sind ohne Domänenwissen, das großen Sprachmodellen verlässlich fehlt, kaum zu erkennen.

Das Geld-Problem: Gleitkomma-Arithmetik ist keine Währungsrechnung

Das ist der am weitesten verbreitete Fehler in KI-generiertem Finanzcode, und er taucht in praktisch jeder vibe-gecodeten FinTech-Codebasis auf, die ich geprüft habe. Das Problem ist grundlegend: IEEE-754-Gleitkomma-Arithmetik - also das, was JavaScripts number-Typ, PHPs float und Pythons float verwenden - kann die meisten Dezimalbrüche nicht exakt darstellen.

Führe das in einer beliebigen JavaScript-Konsole aus:

console.log(0.1 + 0.2); // 0.30000000000000004

KI-Coding-Assistenten wissen das. Fragst Du sie nach Währungsbehandlung, generieren sie oft Code, der mit toFixed(2) oder Math.round(amount * 100) / 100 über die Ungenauigkeit hinwegtüncht. Aber das sind Anzeige-Fixes, keine Berechnungs-Fixes. Wende sie in einer Schleife über tausende Transaktionen an, und die Fehler summieren sich. Wende sie vor einer Multiplikation an, und Du erzeugst neue Rundungsfehler. Wende sie inkonsistent über eine Codebasis an - was KI-generierter Code fast immer tut - und Deine Summen gehen nicht auf.

Die korrekte Lösung für Finanzanwendungen ist, in der kleinsten unteilbaren Einheit der Währung (Cents für EUR/GBP/USD, Pence, Öre) mit Ganzzahlen zu rechnen oder eine spezialisierte Bibliothek für beliebige Präzision zu verwenden. In PHP:

// Falsch - Gleitkomma-Akkumulation über tausende Transaktionen
$total = 0.0;
foreach ($transactions as $tx) {
    $total += $tx->getAmountEur(); // float
}

// Korrekt - Ganzzahl-Arithmetik in Minor Units
$totalCents = 0;
foreach ($transactions as $tx) {
    $totalCents += $tx->getAmountCents(); // int, gespeichert als Cents
}
$displayTotal = number_format($totalCents / 100, 2);

In JavaScript/TypeScript sind decimal.js oder dinero.js die Standardbibliotheken dafür. Keine von beiden taucht standardmäßig in vibe-gecodetem Output auf. Die KI greift zum nativen number, weil natives number das ist, was ihre gesamten Trainingsdaten zu JavaScript-Arithmetik verwenden.

Der Audit-Fix besteht nicht nur im Tauschen von Typen. Er erfordert die Prüfung jedes Punkts, an dem Geldbeträge aus einer Datenbank gelesen, zwischen Funktionen übergeben, nach JSON serialisiert und zurückgespeichert werden - und die Sicherstellung, dass Ganzzahl- oder Dezimaltypen über den gesamten Fluss konsistent verwendet werden.

Regulatorische Compliance-Lücken, die KI nicht sehen kann

Große Sprachmodelle sind auf Code trainiert. Sie sind nicht auf die operative Erfahrung trainiert, Systeme zu bauen, die regulatorische Audits überstehen, denn dieses Wissen lebt in Compliance-Dokumenten, Rechtsauslegungen und institutionellem Gedächtnis - nicht in öffentlichen GitHub-Repositories.

Das Ergebnis: Vibe-gecodete FinTech-Anwendungen haben typischerweise korrekt aussehende Logik, die regulatorische Anforderungen auf Weisen verletzt, die unsichtbar bleiben, bis ein Auditor oder das Compliance-Team eines Payment-Processors das System ansieht.

PSD2 und Starke Kundenauthentifizierung

Die überarbeitete EU-Zahlungsdiensterichtlinie (PSD2) schreibt für die meisten elektronischen Zahlungen im EWR Starke Kundenauthentifizierung (SCA) vor. SCA verlangt mindestens zwei von drei Faktoren: etwas, das der Kunde weiß (Passwort/PIN), etwas, das er besitzt (Gerät, Hardware-Token), und etwas, das er ist (Biometrie). Bestimmte Transaktionskategorien sind ausgenommen - Kleinbetragszahlungen, vertrauenswürdige Empfänger, vom Acquirer als risikoarm bewertete Transaktionen.

KI-generierte Checkout-Flows implementieren OAuth oder JWT-Authentifizierung korrekt. Sie implementieren mit an Sicherheit grenzender Wahrscheinlichkeit nicht die SCA-Step-up-Authentifizierung, die PSD2-Ausnahmelogik oder den 3DS2-Challenge-Flow, den Kartennetzwerke für SCA-Compliance verlangen. Das sind keine Features, die man nachträglich ergänzt. Sie bestimmen Deine Payment-Architektur vom ersten Tag an.

Ein europäisches Payment-Produkt ohne SCA zu launchen erzeugt nicht nur eine Sicherheitslücke. Es kann dazu führen, dass Dein Payment-Processor Dein Konto sperrt, und Dich Bußgeldern nationaler Finanzaufsichtsbehörden aussetzen.

PCI DSS und der Umgang mit Kartendaten

PCI DSS (Payment Card Industry Data Security Standard) verbietet die Speicherung bestimmter Kartendaten nach der Autorisierung - darunter die vollständige Kartennummer (PAN), außer in gehashter oder gekürzter Form, der CVV/CVC in jeglicher Form und die vollständigen Magnetstreifendaten. PCI-DSS-Verstöße können Bußgelder der Kartennetzwerke und die Kündigung Deines Payment-Processing-Vertrags zur Folge haben.

Vibe-gecodete Payment-Flows loggen häufig Kartennummern in Fehlermeldungen, speichern sie in Debug-Feldern oder reichen sie durch Anwendungsschichten, die sie gar nicht brauchen. Die KI generiert Code, der die Daten verarbeitet, die er erhält - nicht Code, der bewusst einschränkt, welche Daten er anfasst. Eine saubere Tokenisierungsarchitektur - bei der Kartendaten Deine Anwendungsserver nie berühren und nur ein Token gespeichert wird, das auf die Karte verweist - erfordert bewusstes Design, das KI-generierter Code nicht von selbst hervorbringt.

AML und Transaktionsüberwachung

Geldwäschebekämpfungs-Regulierung (AML) in Deutschland und der EU (6AMLD und die kommende AMLA) verpflichtet Finanzdienstleister, verdächtige Transaktionsmuster zu überwachen, Aufzeichnungen fünf bis zehn Jahre aufzubewahren und Verdachtsmeldungen abzugeben. Das sind keine Features - das sind rechtliche Pflichten, die in manchen Jurisdiktionen strafrechtliche Haftung für Führungskräfte nach sich ziehen.

KI-generierter Finanzcode produziert nichts von dieser Infrastruktur. Ein Gründer, der über ein Wochenende ein Peer-to-Peer-Payment-Feature baut, hat keine AML-Überwachung, weiß womöglich nicht einmal, dass sie verpflichtend ist, und entdeckt die Lücke erst beim Onboarding mit einem regulierten Payment-Partner, der seine technische Architektur prüft.

Transaktionsintegrität: Wo KI-generierter Code ACID falsch macht

Datenbanktransaktionen sind die Stelle, an der KI-generierter Finanzcode unter Last am verlässlichsten versagt. Die Fehlermodi sind in der Entwicklung subtil und in der Produktion katastrophal.

Betrachte eine Überweisung zwischen zwei Konten: Konto A belasten, Konto B gutschreiben. Die korrekte Implementierung verpackt beide Operationen in eine einzige Datenbanktransaktion, sodass entweder beide gelingen oder keine. KI-generierter Code bekommt die Verpackung häufig richtig hin. Was er übersieht, ist alles andere:

// Was KI typischerweise generiert - sieht korrekt aus, hat gravierende Lücken
public function transfer(int $fromAccountId, int $toAccountId, int $amountCents): void
{
    $this->db->beginTransaction();
    try {
        $from = $this->accountRepo->find($fromAccountId);
        $to = $this->accountRepo->find($toAccountId);
        
        $from->debit($amountCents);
        $to->credit($amountCents);
        
        $this->db->commit();
    } catch (\Exception $e) {
        $this->db->rollBack();
        throw $e;
    }
}

// Was produktionsreifer Finanzcode erfordert
public function transfer(int $fromAccountId, int $toAccountId, int $amountCents): void
{
    $this->db->beginTransaction();
    try {
        // SELECT ... FOR UPDATE - pessimistisches Locking verhindert konkurrierende Änderungen
        $from = $this->accountRepo->findForUpdate($fromAccountId);
        $to = $this->accountRepo->findForUpdate($toAccountId);
        
        if ($from->getBalanceCents() < $amountCents) {
            throw new InsufficientFundsException();
        }
        
        $from->debit($amountCents);
        $to->credit($amountCents);
        
        // Unveränderlicher Audit-Eintrag - wird nie aktualisiert, nur angehängt
        $this->ledgerRepo->recordTransfer($from, $to, $amountCents);
        
        $this->db->commit();
    } catch (\Exception $e) {
        $this->db->rollBack();
        throw $e;
    }
}

Die KI-Version hat eine Race Condition. Ohne SELECT FOR UPDATE (oder gleichwertiges optimistisches Locking mit Versionsprüfungen) können zwei gleichzeitige Überweisungen vom selben Konto beide den Saldo als ausreichend lesen, beide durchgehen und das Konto gemeinsam überziehen. Das ist das Double-Spend-Problem, und es ist nicht theoretisch - es ist unter jedem ernsthaften Lasttest reproduzierbar.

Auch der Audit-Ledger-Eintrag ist nicht optional. Eine veränderbare balance-Spalte in einer accounts-Tabelle ist kein Finanzdatensatz. Sie ist eine laufende Summe. Wenn etwas schiefgeht - ein Bug, eine korrupte Transaktion, eine bestrittene Abbuchung - brauchst Du ein unveränderliches Append-only-Log jedes finanziellen Ereignisses, um den korrekten Zustand zu rekonstruieren. KI-generierter Code modelliert Kontostand als veränderbare Daten, weil fast alle Nicht-Finanz-Software Zustand so modelliert.

Audit-Trails: Die Anforderung, die KI nie generiert

Jede relevante Aktion in einem Finanzsystem - Saldoänderung, Rechtevergabe, Konfigurationsänderung, fehlgeschlagener Authentifizierungsversuch - muss in einen unveränderlichen Audit-Trail geloggt werden, mit genug Kontext, um zu rekonstruieren, was passiert ist, und es einem Regulator zu beweisen.

Das bedeutet:

• Wer die Aktion ausgeführt hat (authentifizierte Nutzeridentität, nicht nur ein Session-Token)
• Was sich geändert hat (Werte vorher und nachher, nicht nur der neue Zustand)
• Wann es passiert ist (serverseitiger Zeitstempel, nicht vom Client geliefert)
• Warum es autorisiert war (die Berechtigung oder Freigabekette, die die Aktion erlaubt hat)
• Von wo (IP-Adresse, Geräte-Fingerprint)

KI-generierter Code produziert Anwendungslogs. Anwendungslogs erfassen Fehler und Debugging-Informationen. Sie sind keine Audit-Trails. Sie sind typischerweise veränderbar (Log-Rotation löscht sie), liegen in der Anwendungsschicht (nicht getrennt von Anwendungsdaten) und sind nicht für die spezifischen Abfragen strukturiert, die ein Compliance-Team bei einer Untersuchung ausführen wird.

Eine konforme Audit-Trail-Architektur erfordert bewusste Entscheidungen über Speicherung (Append-only-Tabellen oder unveränderlicher Objektspeicher), Aufbewahrungsfristen (fünf bis zehn Jahre für die meisten EU-Finanzregulierungen), Zugriffskontrollen (Auditoren dürfen lesen, aber nicht ändern) und Abfrage-Infrastruktur (Audit-Events müssen nach Nutzer, Entität und Zeitraum effizient und skalierbar durchsuchbar sein).

Was ein professionelles FinTech-Code-Review prüfen muss

Wenn Wolf-Tech eine vibe-gecodete Finanzanwendung prüft, schauen wir zuerst an diese Stellen, weil dort am verlässlichsten Probleme zu finden sind:

Geldrepräsentation: Jedes Feld und jede Variable, die einen Währungswert hält. Sind es Ganzzahlen (Minor Units), Decimal-Objekte oder float? Werden Umrechnungen konsistent durchgeführt? Gibt es ein typisiertes Money-Value-Object, das Korrektheit erzwingt, oder ist rohe Arithmetik über die Codebasis verstreut?

Transaktionsgrenzen: Läuft jede Operation, die mehrere Finanzdatensätze berührt, in einer expliziten Datenbanktransaktion? Werden Locks vor dem Lesen von Salden gesetzt, um konkurrierende Änderungen zu verhindern? Sind Szenarien für Teilausfälle getestet?

Regulatorische Berührungspunkte: Implementiert der Authentifizierungs-Flow SCA für relevante Transaktionen? Folgt der Umgang mit Kartendaten einer Tokenisierungsarchitektur? Gibt es eine AML-Transaktionsüberwachung, wenigstens mit Basisschwellen?

Audit-Abdeckung: Gibt es einen unveränderlichen Ledger, der jede Saldoänderung aufzeichnet? Werden sensible administrative Aktionen mit vollem Kontext geloggt? Ist der Audit-Speicher vom Anwendungsspeicher getrennt und für Anwendungsprozesse unzugänglich?

Fehlerbehandlung und Observability: Erzeugen fehlgeschlagene Zahlungsverarbeitungen handlungsfähige Alerts statt bloßer 500er-Fehler? Sind fehlgeschlagene Transaktionen in einem Zustand, der ein sicheres Retry erlaubt, oder riskiert ein Retry eine Doppelbuchung?

Keine dieser Prüfungen lässt sich durch einen Linter oder ein statisches Analysetool automatisieren. Sie erfordern Verständnis der Domäne, Kenntnis des regulatorischen Umfelds und Erfahrung mit genau diesen Fehlermodi.

Die Kosten, wenn das schiefgeht

In einer Content-Plattform kostet ein in Produktion entdeckter Bug Entwicklungszeit und vielleicht etwas Nutzervertrauen. In einer Finanzanwendung sind die Kosten qualitativ anders: regulatorische Bußgelder, Strafen der Kartennetzwerke, Kündigung durch den Payment-Processor und - für Gründer - potenzielle persönliche Haftung unter AML- und anderen Finanzregulierungen.

Die DSGVO-Bußgelder der EU für Datenpannen sind bekannt. Weniger diskutiert wird, dass die strafrechtliche Haftung der 6AMLD für AML-Versäumnisse sich auf Einzelpersonen erstrecken kann, nicht nur auf Unternehmen. Ein Gründer, der ein Payment-Feature ohne AML-Überwachung baut und betreibt, trägt nicht nur regulatorisches Risiko - er ist womöglich persönlich exponiert.

Das ist kein Argument gegen den Bau von FinTech-Produkten oder gegen KI-Tools, um schneller voranzukommen. Es ist ein Argument dafür, dass Finanzanwendungen ein Code-Quality-Audit und ein professionelles Review brauchen, bevor sie echtes Geld bewegen - nicht danach.

Wolf-Tech hat Finanzsoftware für europäische FinTech-Gründer, Payment-Plattformen und Unternehmen geprüft, die Payment-Features in bestehende Produkte integrieren. Wenn Du eine vibe-gecodete Finanzanwendung kurz vor der Produktion hast oder ein bestehendes System, dem Du nicht voll vertraust, melde Dich unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung. Ein sauberes Review ist deutlich günstiger als das, was passiert, wenn diese Fehler in Produktion auftauchen.