Fintech-Architektur: Die nicht verhandelbaren Grundlagen

In den meisten Systemen ist ein Bug ein Vorfall. Im Fintech ist ein Bug eine Verbindlichkeit, die möglicherweise schon Geld gekostet hat, ohne dass es jemand bemerkt hat.

Fintech-Architektur hat eine kleine Zahl wirklich nicht verhandelbarer Entscheidungen. Macht man sie falsch, holt keine spätere Entwicklungsarbeit das vollständig auf — man erbt ein System, in dem Geld lautlos falsch sein kann, und das ist der eine Fehlermodus, den ein Finanzprodukt nicht verkraftet.

1. Salden werden abgeleitet, nie als Wahrheit gespeichert

Der mit Abstand häufigste und schädlichste Fehler ist eine veränderbare Saldo-Spalte, die Code direkt aktualisiert. Das ist bequem, schnell und nicht wiederherstellbar: Läuft sie auseinander, lässt sich nicht mehr feststellen, was sie hätte sein sollen.

Das korrekte Modell ist ein Append-only-Journal von Buchungen. Nichts wird je aktualisiert oder gelöscht; Korrekturen sind neue Gegenbuchungen. Der Saldo ist die Summe der Buchungen — für Performance gecacht, aber jederzeit aus dem Journal rekonstruierbar.

2. Jeder Geldpfad ist idempotent

Netzwerke wiederholen. Nutzer doppelklicken. Zahlungsanbieter liefern Webhooks mehr als einmal — das ist dokumentiertes Verhalten, kein Randfall. Jede Operation, die Geld bewegt, muss gefahrlos wiederholt ausführbar sein.

• Jede Geldoperation trägt einen vom Aufrufer gelieferten Idempotency Key, eindeutig pro logischer Absicht
• Der Schlüssel wird mit Eindeutigkeits-Constraint gespeichert, bevor Seiteneffekte eintreten, nicht danach
• Ein wiederholter Schlüssel gibt das ursprüngliche Ergebnis zurück, statt die Arbeit erneut auszuführen
• Webhook-Handler speichern die Rohdaten mit der Provider-Event-ID als Schlüssel und verarbeiten danach — so wird eine erneute Zustellung auch mitten in der Verarbeitung erkannt

3. Geld sind Ganzzahlen in Minor Units

Fließkommazahlen können Dezimalbrüche nicht exakt darstellen, deshalb akkumuliert Arithmetik auf Float-Geld Fehler. Speichern Sie Minor Units als Ganzzahlen (oder als Dezimaltyp mit fester Präzision) und machen Sie die Währung an jedem Betrag explizit — ein Betrag ohne Währung ist ein Bug, der auf den ersten internationalen Kunden wartet.

4. Abstimmung ist ein Feature, kein Nachgedanke

Gehen Sie von Abweichungen zwischen Ihrem Ledger und dem Zahlungsanbieter aus — sie werden auftreten, durch Timeouts, Teilausfälle und Korrekturen auf Anbieterseite. Die Frage ist, ob Sie sie bemerken.

• Ein geplanter Job, der internen Zustand gegen die Settlement-Daten des Anbieters vergleicht
• Alarmierung bei Abweichung, mit definiertem Verantwortlichen und Runbook
• Ein definierter Auflösungsweg — Gegenbuchungen, niemals stille Anpassung
• Sweeps für hängende Zustände: Transaktionen, die länger als vorgesehen pending sind

5. Isolierung, in beiden Bedeutungen

• Mandantenisolierung — auf Datenebene erzwungen, nicht in der Hoffnung, dass jede Query den richtigen Filter enthält
• Fehlerisolierung — ein langsamer Anbieter darf nicht den Request-Pool erschöpfen und unbeteiligte Funktionalität lahmlegen
• Umgebungsisolierung — niemals Testtransaktionen in Produktions-Ledgern

6. Bauen Sie für das Audit, das irgendwann kommt

Nein. Es liefert technische Feststellungen im vereinbarten Umfang. Rechtliche Bewertung und formelle Zertifizierung erfordern entsprechend qualifizierte Prüfer.

• Unveränderlicher Audit-Trail, wer wann was getan hat — einschließlich interner Admin-Aktionen
• Kartendaten berühren Ihre Server nie, es sei denn, Sie wollen wirklich PCI-konform sein (nutzen Sie Hosted Fields oder eine Hosted Page)
• Aufbewahrung und Löschung, die auf Anfrage tatsächlich ausführbar sind
• Zugriffskontrolle, die überprüfbar ist — wer Geld bewegen darf, wer es genehmigt hat

In gewöhnlicher Software optimieren Sie auf Änderungsgeschwindigkeit. Im Fintech optimieren Sie darauf, später exakt beweisen zu können, was passiert ist und warum.

Die fünf Fragen an Ihr eigenes System

1. Wenn dieser Webhook zweimal ankommt, ändert sich beim zweiten Mal irgendetwas?
2. Kann ich den Saldo jedes Kunden zu jedem vergangenen Zeitpunkt allein aus dem Ledger rekonstruieren?
3. Würden wir eine Abweichung zum Anbieter bemerken — oder würde ein Kunde es uns sagen?
4. Kann eine präparierte Anfrage das Geld eines anderen Mandanten lesen oder bewegen?
5. Wenn ein Regulierer fragte, wer im vergangenen März eine manuelle Anpassung genehmigt hat — könnten wir das in Minuten beantworten?

Transaktionsannahme und Abwicklung unterscheiden

Zahlungszustände müssen verspätete und wiederholte Ereignisse abbilden. Finanzielle Einträge und den kontrollierten Korrekturablauf gemeinsam prüfen.

1. Exakte Dezimal- oder ganzzahlige Untereinheiten mit Währungsregeln verwenden.
2. Anbieterereignisse zuordnen, ohne Wiederholungen doppelt zu verbuchen.
3. Originaleinträge erhalten und freigegebene Korrekturen nachvollziehbar dokumentieren.

• Fintech Audit →