Fintech-Architektur sanieren, ohne alles neu zu bauen

Fintech-Architektursanierung ist die kontrollierte Reparatur der Sicherheits-, Daten- und Delivery-Grenzen eines laufenden Finanzprodukts, ohne das gesamte System zu ersetzen. Die sicherste Reihenfolge lautet: Findings nachvollziehbar machen, Sprache und Persistenz stabilisieren, Abhängigkeiten offenlegen, Autorisierungs- und Zahlungsrisiken schließen und das Ergebnis anschließend durch Staging und Release-Gates belegen.

Dieser Artikel beantwortet die Sanierungsfrage: Was sollte nach einem Architektur- oder Security-Review passieren, wenn ein geldbewegendes Produkt ernsthafte Schwächen zeigt? Für den vorgelagerten Befundprozess dient unser Leitfaden zum Vibe-Coded-Software-Audit. Wenn gleichzeitig ein Anbieterwechsel ansteht, ist der 30-Tage-Plan zur Softwareübernahme die passendere Grundlage.

Wie sah die Ausgangsarchitektur aus?

Das Produkt kombinierte ein Node.js- und Express-Backend, PostgreSQL, Redis, Browser- und Mobile-Clients, ein Next.js-Frontend mit serverseitigen API-Routen, mehrere Identity- und Payment-Integrationen sowie EVM-basierte Transaktionspfade. Teile waren durch heterogene und teilweise KI-generierte Implementierungsmuster gewachsen. Das Problem lag nicht in einem einzelnen Modul. Es gab mehrere konkurrierende Wege, Services zu erzeugen, Daten abzufragen, Nutzer zu identifizieren und externe Events zu verarbeiten.

Ein einmaliger Scanner-Report konnte diese Fläche nicht steuern. Wavect verwendete über mehrere Prüfungen hinweg stabile Finding-IDs, Severity, Quellort, Risiko, Sanierungsrichtung und Retest-Kriterien. Das entspricht dem NIST Secure Software Development Framework, das Code-Review, Triage und empfohlene Sanierung als Aktivitäten im Development-Workflow behandelt und nicht als Schlusszeremonie.

Die Sanierungsreihenfolge in sechs Schichten

Die Reihenfolge war die wichtigste Architekturentscheidung. Domain-Bugs zu reparieren, während Konstruktion, Persistenz und Identität mehrdeutig blieben, hätte weitere Parallelpfade geschaffen. Deshalb bekam jede Schicht klare Exit-Evidenz.

1. Aus Reports ein lebendes Sanierungssystem machen

Jedes Item behielt von der Entdeckung über die Umsetzung bis zum Retest dieselbe ID. Eine Abschlussnotiz musste auf das tatsächlich geänderte Verhalten verweisen, nicht auf den Titel eines Pull Requests. Spätere Prüfungen trennten vier Zustände: behoben, teilweise behoben, weiterhin vorhanden und Implementierung fehlt. So galt ein neuer Guard nicht als Lösung, wenn der produktive Router noch einen Legacy-Controller aufrief.

Die praktische Prüfeinheit war eine Route oder User Journey, nicht eine Datei. Reviewer verfolgten Requests von der Authentifizierung über Controller, Service und Repository bis zum externen Effekt. Bei mehreren Implementierungen wurde zuerst geklärt, welche davon echten Traffic bediente.

2. Vor breiten Domain-Refactorings die Typen etablieren

Das Backend wechselte zu strengem TypeScript mit gemeinsamen Entities, Request Context, Response Envelopes, Domain Contracts und Application Errors. Typen verließen Business-Logic-Dateien und wanderten in klar verantwortete Module. Tiefe relative Imports wurden durch Domain-Aliases ersetzt.

Das allein machte das System nicht sicher. Es machte Annahmen sichtbar und damit prüfbar. Eine User-ID, ein Provider-Event und ein Transaktionsstatus konnten nicht mehr in jedem Service eine andere Form annehmen, ohne dass der Compiler den Widerspruch zeigte.

3. Konstruktion und Persistenz langweilig machen

Die Service-Konstruktion wanderte in einen HTTP Composition Root. Domain-Code erhielt Abhängigkeiten über Konstruktoren. Exportierte Service-Instanzen, statische Business-Methoden und Container-Lookups innerhalb der Domain-Schicht wurden entfernt. Controller erhielten nicht länger eine globale DataSource, sondern genau den Service oder das Repository, das sie benötigten.

Die Persistenz wurde hinter TypeORM-Entities und Domain-Repositories konsolidiert. Kontrolliertes Raw SQL blieb dort erhalten, wo komplexe Queries es rechtfertigten. Datenbankinitialisierung wurde eine explizite Startup-Verantwortung, laufzeitbasierte Schemaerzeugung verschwand aus Finanzpfaden und Schema-Synchronisierung blieb deaktiviert. Die TypeORM-Dokumentation zu Migrationen warnt, dass automatische Synchronisierung bei einer Produktionsdatenbank mit echten Daten typischerweise unsicher ist, und stellt Migrationen als kontrollierte Alternative dar.

4. Identität am Server ableiten und jedes Objekt autorisieren

Authentifizierung beantwortet, wer den Request gestellt hat. Sie beantwortet nicht, ob diese Person eine Gruppe lesen, eine Transaktion verändern oder fremde Datensätze sehen darf. Die Sanierung ordnete Operationen als selbstbezogen, mitgliedsbezogen, administratorbezogen oder provider-signiert ein und setzte Zugriff standardmäßig auf verweigert.

Vom Client gelieferte User-IDs, Telefonnummern, Wallet-IDs und Transaktions-IDs wurden zu Lookup-Eingaben, nicht zu Berechtigungsnachweisen. Der authentifizierte Context lieferte die Identität. Gemeinsame Guards prüften Self, Membership, Rolle und Ownership. Responses wurden gefiltert, damit der Client nur die für diese Journey erforderlichen Identitäts- und Finanzfelder erhielt.

Genau diese Fehlerklasse beschreibt OWASP API1:2023 Broken Object Level Authorization: Jeder Endpoint, der eine Objekt-ID entgegennimmt, muss prüfen, ob der angemeldete Nutzer die angeforderte Aktion auf diesem Objekt ausführen darf. Zufällige IDs erschweren Raten, ersetzen aber keine Autorisierung.

5. Payment-Pfade für Retries, Duplikate und Teilerfolg bauen

Geldbewegende APIs scheitern an unangenehmen Stellen. Ein Provider kann erneut zustellen, nachdem das System die Balance geändert, aber die Response verloren hat. Zwei Events können denselben Business Outcome beschreiben. Ein späterer Status kann vor einem früheren Event eintreffen. Ein externer Callback kann echt sein, während die nachgelagerte Datenbankoperation scheitert.

Die Sanierung führte nutzerbezogene Idempotency Records, Request-Body-Hashes, dauerhafte Response-Speicherung und explizites Produktionsversagen ein, wenn dauerhafte Idempotenz nicht verfügbar war. Ein separater Balance-Application-Marker unterschied zwischen „Eventstatus gespeichert“ und „Finanzeffekt abgeschlossen“. Dadurch unterdrückte ein duplizierter Status keine unfertige Balance-Arbeit.

Webhook-Verifizierung geschah vor Monitoring und Mutation. Nicht vertrauenswürdige operative Callbacks blieben deaktiviert, bis ein vertrauenswürdiger Aufrufer und ein Secret feststanden. Die Stripe-Webhook-Dokumentation zeigt die providerunabhängigen Regeln gut: Signaturen prüfen, Retries und Duplikate erwarten, nicht von Event-Reihenfolge abhängen und komplexe Verarbeitung vom Bestätigungspfad trennen.

6. Das Produkt in Staging belegen, nicht nur statisch prüfen

Der letzte Durchgang testete Gruppen-Lifecycle-Aktionen, Ein- und Auszahlungen, Wallet-Handoffs, Provider-Fehler, responsive Layouts und Backend-Trust-Boundaries. Er dokumentierte reproduzierbare IDs, Screenshots, bestätigtes Verhalten und Restrisiken. Statische Prüfung konnte zeigen, dass eine Signaturprüfung existierte. Nur ein repräsentativer Flow zeigte, ob der richtige Provider-Pfad sie aufrief und ob Nutzer sich von einem Fehler erholen konnten.

Was änderte sich im geprüften Snapshot?

Das sind Strukturmesswerte, keine Behauptung, jedes Risiko sei verschwunden. Automatisierte Abdeckung musste weiter wachsen, externe Provider konnten weiterhin ausfallen, Smart-Contract-Reviews blieben ein separates Release-Gate und große Domain-Services benötigten weiterhin selektive Zerlegung.

Warum kleine Pull Requests wichtiger waren als ein sauberes Diagramm

Frühe Sanierungskandidaten bündelten Dutzende Findings. Einer bearbeitete 27 nachverfolgte Items in ungefähr 85.000 geänderten Zeilen. Ein anderer enthielt noch etwa 50 Findings. KI-gestützte Umsetzung erzeugte Code schneller, als Menschen das kombinierte Verhalten verifizieren konnten.

Das Delivery-Modell wechselte zu zwei oder drei zusammengehörigen Findings pro Pull Request und, wo praktikabel, ungefähr 20 Dateien. Foundation-Branches wurden in Abhängigkeitsreihenfolge gestapelt. Jeder Branch brauchte Implementierungsplan, Testevidenz, Review und erneute Quellprüfung nach dem Merge. Der finale Merge-Stand wurde nochmals geprüft, weil einzeln korrekte Branches gemeinsam ein falsches System ergeben können.

Das war inkrementelle Modernisierung und keine Ausrede, jede alte Entscheidung zu behalten. Martin Fowlers Beschreibung des Strangler-Fig-Musters erklärt, warum schrittweise Ablösung Investition und Resultate sichtbar macht, während das bestehende System weiter Nutzer bedient. In diesem Fall lagen die Seams bei Typen, Komposition, Repositories, Autorisierung und Provider-Adaptern statt in einem Big-Bang-Plattformwechsel.

Wann ist ein Fintech-Produkt releasebereit?

Ein grüner Build war notwendig, aber nicht ausreichend. Die Release-Entscheidung brauchte Evidenz auf fünf Ebenen:

1. Finding-Abschluss: Jeder Blocker hatte Quelländerung, Retest und einen Owner für das Restrisiko.
2. Kritische Journeys: Authentifizierung, Gruppen-Lifecycle, Ein- und Auszahlung sowie Fehlererholung bestanden in einer repräsentativen Umgebung.
3. Finanzielle Integrität: Doppelte, verspätete, ungültige und teilweise abgeschlossene Events hatten deterministische Outcomes und Reconciliation-Pfade.
4. Operative Recovery: Deployment, Rollback, Monitoring, Incident Ownership und Datenwiederherstellung waren belegt.
5. Externe Assurance: Provider- und Smart-Contract-Risiken außerhalb des Anwendungscodes hatten eigene Tests oder unabhängige Prüfung.

Diese Liste ist keine Behauptung regulatorischer Compliance. Pflichten hängen von Rolle, Markt, Daten und Zahlungsmodell ab. Architektursanierung liefert Engineering-Evidenz für qualifizierte Security-, Rechts- oder Regulierungsprüfungen. Sie ersetzt keine davon.

Reparieren, selektiv ersetzen oder neu bauen?

Wavects Software-Qualitätssicherung kann eine Finanzcodebasis in ein nachvollziehbares Risiko- und Sanierungsprogramm überführen. Die IKB-Fallstudie zu sensiblen Integrationsgrenzen liefert einen separaten Arbeitsnachweis. Der Leitfaden vom Vibe-Coded-Prototyp zur Produktion hilft bei der breiteren Hardening-Entscheidung. Wenn Geld, Identität oder Provider-Callbacks bereits durch das System laufen, kannst du einen unabhängigen Fintech-Architektur-Review anfragen.