--- title: "Fintech-Architektur sanieren ohne Rebuild" canonical: https://wavect.io/de/blog/fintech-architecture-remediation-without-rewrite/ language: de description: "Praxisleitfaden zur Fintech-Architektursanierung für TypeScript, Autorisierung, Zahlungen, Webhooks und Release-Gates anhand eines anonymisierten Falls." image: "https://wavect.io/img/blog/headers/header_fintech-architecture-remediation-without-rewrite.png" --- [**Zurück**](/de/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/de/team/christof-jori/) [Christof Jori](/de/team/christof-jori/) https://linkedin.com/company/wavect 13 min Lesezeit · 13. August 2026 [**Weiter**](/de/blog/software-project-takeover-provider-change/) # Fintech-Architektur sanieren, ohne alles neu zu bauen TL;DR Eine Fintech-Architektursanierung sollte mit Evidenz beginnen, nicht mit einem Rebuild. In diesem anonymisierten Projekt überführte Wavect mehrere QA-Durchgänge in stabile Finding-IDs und sanierte das System Schicht für Schicht: TypeScript-Verträge, eindeutige Startup- und Persistenzverantwortung, Constructor Injection, standardmäßig verweigerte Objekt-Autorisierung, dauerhafte Idempotenz, verifizierte Webhooks und gestufte Release-Gates. Der geprüfte Snapshot umfasste am Ende 275 TypeScript-Dateien in Anwendung, Skripten und Tests, 125 injizierbare Klassen und 317 Constructor-Injection-Punkte. Diese Zahlen beschreiben nur diese Codebasis und sind kein Benchmark. Übertragbar ist die Methode: aktive Risiken zuerst schließen, einen einzigen produktiven Implementierungspfad schaffen, die Sanierung in kleine Pull Requests teilen, den Quellcode nach jedem Merge erneut prüfen und vor dem Launch Belege aus User-Flows, Recovery und externen Providern verlangen. **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](/de/blog/vibe-coded-software-audit/). Wenn gleichzeitig ein Anbieterwechsel ansteht, ist der [30-Tage-Plan zur Softwareübernahme](/de/blog/software-project-takeover-provider-change/) die passendere Grundlage. **Anonymisierungsgrenze:** Diese Fallstudie stammt aus Wavect-Delivery-Unterlagen und ist kein zusammengesetztes Beispiel. Wir nennen weder Kunde noch Region, interne Routennamen, Provider-Kombination, Produktionstopologie oder ungelöste Schwachstellendetails. Stack, Sanierungsreihenfolge und Repository-Messwerte sind real. Die Zahlen beschreiben einen geprüften Snapshot und sind keine Branchenbenchmarks. ## 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. | Grenze | Beobachtetes Ausgangsmuster | Warum es relevant war | | --- | --- | --- | | Anwendungsverträge | Untypisiertes JavaScript, breite Shapes und lokale Interfaces | Falsche Annahmen wurden erst zur Laufzeit sichtbar. | | Service-Verantwortung | Statics, globale Instanzen, direkte Konstruktion und Service Location | Der produktive Dependency-Pfad war schwer nachzuvollziehen und zu mocken. | | Persistenz | Raw SQL, Modellfassaden und mehrere Data-Access-Muster | Transaktionen, Schemaregeln und Query-Verantwortung konnten auseinanderlaufen. | | Identität | Vom Aufrufer gelieferte Nutzer- und Objekt-IDs | Authentifizierung belegte nicht immer den Zugriff auf das Zielobjekt. | | Geldbewegung | Uneinheitliche Idempotenz, Locks und Webhook-Verarbeitung | Retries oder Teilfehler konnten Finanzzustand doppelt oder gar nicht verändern. | | Release-Evidenz | Große Changesets und ein bewegliches Staging | Ein Finding wirkte behoben, während eine andere Route noch den alten Pfad nutzte. | 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](https://csrc.nist.gov/pubs/sp/800/218/final), 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. | Reihenfolge | Sanierungsschicht | Exit-Evidenz | | --- | --- | --- | | 1 | Nachvollziehbare Risikobasis | Stabile Finding-IDs, Live-Routen-Mapping und eindeutige Abschlusskriterien | | 2 | Typisierte Anwendungsgrundlage | Striktes TypeScript, gemeinsamer Request Context, DTOs und typisierte Fehler | | 3 | Dependency- und Persistenzgrenzen | Ein Composition Root, Constructor Injection, Repository-basierter Datenzugriff und expliziter Startup | | 4 | Autorisierung und Datenminimierung | Serverseitig abgeleitete Identität, Ownership-Checks und Regressionstests | | 5 | Finanz- und Provider-Integrität | Dauerhafte Idempotenz, verifizierte Webhooks, Reconciliation-Marker und Fail-Closed-Verhalten | | 6 | Staging und Release Readiness | Retests kritischer User-Flows, Recovery-Evidenz und schriftliche Go- oder No-Go-Entscheidung | ### 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](https://typeorm.io/docs/migrations/why/) 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](https://owasp.org/API-Security/editions/2023/en/0xa1-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](https://docs.stripe.com/webhooks) 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? | Messwert | Geprüftes Ergebnis | Was er belegte | | --- | --- | --- | | TypeScript-Fläche | 275 Dateien in Anwendung, Skripten und Tests | Die Anwendung war nicht länger in JavaScript- und TypeScript-Implementierungen geteilt. | | Injizierbare Klassen | 125 | Service-Abhängigkeiten hatten explizite Konstruktionspunkte. | | Constructor-Injection-Punkte | 317 | Abhängigkeiten wurden prüfbar und austauschbar. | | Container Resolution | Auf Routen- und Startup-Komposition begrenzt | Domain-Code versteckte keine Dependencies hinter Service Location. | | Datenbankzugriff | Keine Application DataSource in Controllern oder Services | Persistenzverantwortung lag hinter Repository-Grenzen. | | Statische asynchrone Business-Methoden | Keine unter Services oder Controllern | Business-Verhalten nutzte Instanzabhängigkeiten statt globalen State. | 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](https://martinfowler.com/bliki/StranglerFigApplication.html) 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? | Entscheidung | Wann sie passt | Erster kommerzieller Schritt | | --- | --- | --- | | Im Bestand reparieren | Die Business-Flows sind wertvoll und die Grenzen können explizit werden | Ein begrenztes Architektur- und Release-Readiness-Assessment beauftragen. | | Selektiv ersetzen | Eine Identity-, Payment- oder Persistenzgrenze erzeugt überproportionales Risiko | Diese Grenze mit Coexistence-, Migrations- und Rollback-Kriterien scopen. | | Komplett neu bauen | Das Kerndatenmodell kann das Produkt nicht abbilden oder sichere Koexistenz kostet mehr als Ersatz | Einen evidenzbasierten Vergleich des gesamten Migrationsrisikos verlangen. | Wavects [Software-Qualitätssicherung](/de/services/software-quality-assurance/) kann eine Finanzcodebasis in ein nachvollziehbares Risiko- und Sanierungsprogramm überführen. Die [IKB-Fallstudie zu sensiblen Integrationsgrenzen](/de/case-studies/ikb/) liefert einen separaten Arbeitsnachweis. Der [Leitfaden vom Vibe-Coded-Prototyp zur Produktion](/de/software-development-guide/vibe-coded-prototype-to-production/) 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](/de/contact/). ## FAQ zur Fintech-Architektursanierung ### Was ist Fintech-Architektursanierung? Sie ist die risikogeordnete Reparatur von Anwendungsverträgen, Dependency-Grenzen, Persistenz, Autorisierung, Zahlungsintegrität und Release-Evidenz in einem laufenden Finanzprodukt. Ziel sind sichere Ownership und Änderbarkeit, nicht ein modisches Diagramm oder ein automatischer Komplett-Rebuild. ### Kann ein vibe-codetes Fintech-Produkt produktionsreif werden? Oft ja, wenn wertvolle User Journeys und das Kerndatenmodell tragfähig sind. Beginne mit unabhängiger Quell- und Flow-Prüfung, schließe aktive Risiken, schaffe typisierte und testbare Grenzen und belege Payment- und Recovery-Pfade in Staging. ### Sollte man ein Fintech-Backend komplett neu schreiben? Nicht standardmäßig. Vergleiche Reparatur im Bestand, selektiven Grenzersatz und Komplett-Rebuild anhand derselben Evidenz. Ein Rebuild ist gerechtfertigt, wenn Kernmodell oder Koexistenzrisiko inkrementelle Sanierung teurer oder unsicherer machen. ### Was muss ein Fintech-Architektur-Assessment liefern? Verlange stabile Finding-IDs, Severity, genaue Quellorte, Live-Routen- und Trust-Boundary-Maps, Sanierungsreihenfolge, Retest-Kriterien, Release-Blocker, Restrisiken und einen prüfbaren Pull-Request-Plan. ### Warum ist Idempotenz in Payment-Systemen entscheidend? Netzwerke und Provider wiederholen Requests. Dauerhafte Idempotenz bindet eine Request-Identität an Eingabe und gespeichertes Resultat, damit ein sicherer Retry den Finanzeffekt nicht wiederholt. Webhook-Deduplizierung und Reconciliation benötigen zusätzlichen State. ### Wie verifiziert man einen Architektur-Fix? Verfolge die produktive Route durch Controller, Service, Repository und externen Effekt, prüfe den geänderten Quellcode, reproduziere den ursprünglichen Fehler in einem Regressionstest und teste die repräsentative User Journey. Ein gemergter Pull Request allein ist kein Beweis. ## Fazit Die brauchbare Alternative zum Rebuild ist nicht endloses Flicken. Sie ist ein geordnetes Sanierungsprogramm mit einer Evidenzkette vom Finding über Quelländerung und Regressionstest bis zu Staging-Verhalten und Release-Entscheidung. Stabilisiere zuerst Sprache und Persistenz. Mache Dependencies und Identität explizit. Behandle Payment-Retries und Provider-Callbacks als normalen Betrieb. Halte Pull Requests klein genug für echte Verifikation. So wird das bestehende Produkt sicherer und besser verantwortbar, während es weiter dem Geschäft dient. ## Das könnte dich auch interessieren.. [**Softwareübernahme: ein 30-Tage-Plan** Nutze diesen Plan, wenn die Sanierung auch operative Verantwortung an ein neues Team übertragen muss.](/de/blog/software-project-takeover-provider-change/) [**Vom Vibe-Coded-Prototyp zur Produktion** Plane den größeren Weg vom schnellen Prototyp zu einem eigenen, getesteten Produktionssystem.](/de/software-development-guide/vibe-coded-prototype-to-production/) Architektur und Plattformen ## In diesem Cluster weiterlesen Framework-, Plattform- und Systementscheidungen mit langfristiger Delivery-Wirkung. [Mit dem Grundlagenartikel starten**Smart-City-Architektur: MQTT, LoRaWAN, Kubernetes und Terraform**](/de/blog/smart-city-architecture-best-practices-2026/) - [KI-3D-Modelle für Games: Tools und Qualität 2026](/de/blog/ai-3d-model-generators-game-development-2026/) - [Workflow-Automatisierung mit Tampermonkey](/de/blog/tampermonkey-workflow-automation-guide/) - [Macht KI Cross-Platform-Frameworks überflüssig?](/de/blog/will-ai-kill-cross-platform-frameworks/) - [Floci vs. LocalStack: AWS-Emulator im Praxischeck 2026](/de/blog/floci-vs-localstack-aws-emulator/) - [Git Worktrees vs. Jujutsu für KI-Coding-Agenten: Entscheidungshilfe 2026](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/de/team/christof-jori/) [Christof Jori](/de/team/christof-jori/) https://linkedin.com/company/wavect 13 min Lesezeit · 13. August 2026 [**Weiter**](/de/blog/software-project-takeover-provider-change/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/fintech-architecture-remediation-without-rewrite/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/de/blog/fintech-architecture-remediation-without-rewrite/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Eine Fintech-Architektursanierung sollte mit Evidenz beginnen, nicht mit einem Rebuild. In diesem anonymisierten Projekt überführte Wavect mehrere QA-Durchgänge in stabile Finding-IDs und sanierte das System Schicht für Schicht: TypeScript-Verträge, eindeutige Startup- und Persistenzverantwortung, Constructor Injection, standardmäßig verweigerte Objekt-Autorisierung, dauerhafte Idempotenz, verifizierte Webhooks und gestufte Release-Gates. Der geprüfte Snapshot umfasste am Ende 275 TypeScript-Dateien in Anwendung, Skripten und Tests, 125 injizierbare Klassen und 317 Constructor-Injection-Punkte. Diese Zahlen beschreiben nur diese Codebasis und sind kein Benchmark. Übertragbar ist die Methode: aktive Risiken zuerst schließen, einen einzigen produktiven Implementierungspfad schaffen, die Sanierung in kleine Pull Requests teilen, den Quellcode nach jedem Merge erneut prüfen und vor dem Launch Belege aus User-Flows, Recovery und externen Providern verlangen.", "articleBody": " Blog-Übersicht/Delivery und QA/Architektur und Plattformen Fintech-Architektur sanieren, ohne alles neu zu bauen TL;DR Eine Fintech-Architektursanierung sollte mit Evidenz beginnen, nicht mit einem Rebuild. In diesem anonymisierten Projekt überführte Wavect mehrere QA-Durchgänge in stabile Finding-IDs und sanierte das System Schicht für Schicht: TypeScript-Verträge, eindeutige Startup- und Persistenzverantwortung, Constructor Injection, standardmäßig verweigerte Objekt-Autorisierung, dauerhafte Idempotenz, verifizierte Webhooks und gestufte Release-Gates. Der geprüfte Snapshot umfasste am Ende 275 TypeScript-Dateien in Anwendung, Skripten und Tests, 125 injizierbare Klassen und 317 Constructor-Injection-Punkte. Diese Zahlen beschreiben nur diese Codebasis und sind kein Benchmark. Übertragbar ist die Methode: aktive Risiken zuerst schließen, einen einzigen produktiven Implementierungspfad schaffen, die Sanierung in kleine Pull Requests teilen, den Quellcode nach jedem Merge erneut prüfen und vor dem Launch Belege aus User-Flows, Recovery und externen Providern verlangen. 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. Anonymisierungsgrenze: Diese Fallstudie stammt aus Wavect-Delivery-Unterlagen und ist kein zusammengesetztes Beispiel. Wir nennen weder Kunde noch Region, interne Routennamen, Provider-Kombination, Produktionstopologie oder ungelöste Schwachstellendetails. Stack, Sanierungsreihenfolge und Repository-Messwerte sind real. Die Zahlen beschreiben einen geprüften Snapshot und sind keine Branchenbenchmarks. 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. GrenzeBeobachtetes AusgangsmusterWarum es relevant war AnwendungsverträgeUntypisiertes JavaScript, breite Shapes und lokale InterfacesFalsche Annahmen wurden erst zur Laufzeit sichtbar. Service-VerantwortungStatics, globale Instanzen, direkte Konstruktion und Service LocationDer produktive Dependency-Pfad war schwer nachzuvollziehen und zu mocken. PersistenzRaw SQL, Modellfassaden und mehrere Data-Access-MusterTransaktionen, Schemaregeln und Query-Verantwortung konnten auseinanderlaufen. IdentitätVom Aufrufer gelieferte Nutzer- und Objekt-IDsAuthentifizierung belegte nicht immer den Zugriff auf das Zielobjekt. GeldbewegungUneinheitliche Idempotenz, Locks und Webhook-VerarbeitungRetries oder Teilfehler konnten Finanzzustand doppelt oder gar nicht verändern. Release-EvidenzGroße Changesets und ein bewegliches StagingEin Finding wirkte behoben, während eine andere Route noch den alten Pfad nutzte. 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. ReihenfolgeSanierungsschichtExit-Evidenz 1Nachvollziehbare RisikobasisStabile Finding-IDs, Live-Routen-Mapping und eindeutige Abschlusskriterien 2Typisierte AnwendungsgrundlageStriktes TypeScript, gemeinsamer Request Context, DTOs und typisierte Fehler 3Dependency- und PersistenzgrenzenEin Composition Root, Constructor Injection, Repository-basierter Datenzugriff und expliziter Startup 4Autorisierung und DatenminimierungServerseitig abgeleitete Identität, Ownership-Checks und Regressionstests 5Finanz- und Provider-IntegritätDauerhafte Idempotenz,", "articleSection": "Softwarearchitektur", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "citation": [ { "@type": "WebPage", "name": "NIST Secure Software Development Framework", "url": "https://csrc.nist.gov/pubs/sp/800/218/final" }, { "@type": "WebPage", "name": "TypeORM-Dokumentation zu Migrationen", "url": "https://typeorm.io/docs/migrations/why/" }, { "@type": "WebPage", "name": "OWASP API1:2023 Broken Object Level Authorization", "url": "https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/" }, { "@type": "WebPage", "name": "Stripe-Webhook-Dokumentation", "url": "https://docs.stripe.com/webhooks" }, { "@type": "WebPage", "name": "Beschreibung des Strangler-Fig-Musters", "url": "https://martinfowler.com/bliki/StranglerFigApplication.html" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "Eine Fintech-Architektursanierung sollte mit Evidenz beginnen, nicht mit einem Rebuild. In diesem anonymisierten Projekt überführte Wavect mehrere QA-Durchgänge in stabile Finding-IDs und sanierte das System Schicht für Schicht: TypeScript-Verträge, eindeutige Startup- und Persistenzverantwortung, Constructor Injection, standardmäßig verweigerte Objekt-Autorisierung, dauerhafte Idempotenz, verifizierte Webhooks und gestufte Release-Gates. Der geprüfte Snapshot umfasste am Ende 275 TypeScript-Dateien in Anwendung, Skripten und Tests, 125 injizierbare Klassen und 317 Constructor-Injection-Punkte. Diese Zahlen beschreiben nur diese Codebasis und sind kein Benchmark. Übertragbar ist die Methode: aktive Risiken zuerst schließen, einen einzigen produktiven Implementierungspfad schaffen, die Sanierung in kleine Pull Requests teilen, den Quellcode nach jedem Merge erneut prüfen und vor dem Launch Belege aus User-Flows, Recovery und externen Providern verlangen.", "headline": "Fintech-Architektur sanieren ohne kompletten Rebuild", "image": "https://wavect.io/img/blog/headers/header_fintech-architecture-remediation-without-rewrite.svg", "inLanguage": "de", "keywords": "Softwarearchitektur, Fintech-QA", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/fintech-architecture-remediation-without-rewrite/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/fintech-architecture-remediation-without-rewrite/", "wordCount": 2137 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/delivery-qa/", "name": "Delivery und QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/architecture-platforms/", "name": "Architektur und Plattformen", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/fintech-architecture-remediation-without-rewrite/", "name": "Fintech-Architektur sanieren ohne Rebuild | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Sie ist die risikogeordnete Reparatur von Anwendungsverträgen, Dependency-Grenzen, Persistenz, Autorisierung, Zahlungsintegrität und Release-Evidenz in einem laufenden Finanzprodukt. Ziel sind sichere Ownership und Änderbarkeit, nicht ein modisches Diagramm oder ein automatischer Komplett-Rebuild." }, "name": "Was ist Fintech-Architektursanierung?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Oft ja, wenn wertvolle User Journeys und das Kerndatenmodell tragfähig sind. Beginne mit unabhängiger Quell- und Flow-Prüfung, schließe aktive Risiken, schaffe typisierte und testbare Grenzen und belege Payment- und Recovery-Pfade in Staging." }, "name": "Kann ein vibe-codetes Fintech-Produkt produktionsreif werden?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht standardmäßig. Vergleiche Reparatur im Bestand, selektiven Grenzersatz und Komplett-Rebuild anhand derselben Evidenz. Ein Rebuild ist gerechtfertigt, wenn Kernmodell oder Koexistenzrisiko inkrementelle Sanierung teurer oder unsicherer machen." }, "name": "Sollte man ein Fintech-Backend komplett neu schreiben?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Verlange stabile Finding-IDs, Severity, genaue Quellorte, Live-Routen- und Trust-Boundary-Maps, Sanierungsreihenfolge, Retest-Kriterien, Release-Blocker, Restrisiken und einen prüfbaren Pull-Request-Plan." }, "name": "Was muss ein Fintech-Architektur-Assessment liefern?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Netzwerke und Provider wiederholen Requests. Dauerhafte Idempotenz bindet eine Request-Identität an Eingabe und gespeichertes Resultat, damit ein sicherer Retry den Finanzeffekt nicht wiederholt. Webhook-Deduplizierung und Reconciliation benötigen zusätzlichen State." }, "name": "Warum ist Idempotenz in Payment-Systemen entscheidend?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Verfolge die produktive Route durch Controller, Service, Repository und externen Effekt, prüfe den geänderten Quellcode, reproduziere den ursprünglichen Fehler in einem Regressionstest und teste die repräsentative User Journey. Ein gemergter Pull Request allein ist kein Beweis." }, "name": "Wie verifiziert man einen Architektur-Fix?" } ] } ```