Lass mich eine Sache klarstellen, bevor wir zur Architektur kommen: Die Rolle endete, weil die Business Unit in einer strategischen Restrukturierung geschlossen wurde. Nicht weil Mo irgendwas kaputt gemacht hat. Die Systeme liefen einwandfrei. Fintech ist so — man kann exzellente Infrastruktur shippen und dann trotzdem zusehen, wie der Org-Chart unter einem zusammenfaltet. Weiter. Zum eigentlich interessanten Teil.

Was “event-driven Credit Assessment” bedeutet, wenn man aufhört höflich zu sein

Hier ist die Version, die in jeder Fintech-Stellenbeschreibung steht: “High-Volume- Transaktionsverarbeitung in einer event-driven Architektur.” Hier ist, was das wirklich bedeutet bei einem Kreditmarktplatz mit ernsthaftem Volumen:

Ein Kreditnehmer stellt einen Antrag. Dieser Antrag ist keine Zeile in einer Datenbank, die ein Cron-Job irgendwann aufgreift. Es ist sofort ein Event, und ein Cluster von nachgelagerten Services wartet darauf: die Credit-Scoring-Pipeline, die Fraud-Detection-Schicht, die regulatorischen Reporting-Hooks, die Partner- Lender-Routing-Logik. Jede davon ist ihre eigene Domain, jede hat ihre eigene Failure-Mode, und die Anforderung ist, dass keine davon eine andere blockiert. Der Happy Path muss funktionieren. Die Unhappy Paths — Netzwerk-Timeout bei einem Credit-Bureau-Call, ein Partner-Lender-API, das gedrosselt hat — müssen gehandhabt werden, ohne dass der Kreditnehmer bemerkt, dass irgendetwas passiert ist.

Kafka ist das Backbone, weil man Durability, Replay und unabhängigen Consumer- Fortschritt braucht. Der Credit-Bureau-Call schlägt fehl? Der Consumer retried ab dem committed Offset mit sauberem State. Man muss drei Tage Events replayer, weil ein nachgelagerter Service einen Bug hatte? Consumer zurückspulen. Man muss einen neuen Partner-Lender onboarden, der Events verarbeiten muss, die bereits passiert sind? Nochmal replay. Deshalb greifen Teams in diesem Bereich zu Kafka und nicht einfach zu einer Message Queue: Queues vergessen, Kafka erinnert sich.

Der regulatorische Constraint prägt alles downstream

Fintech-Infrastruktur ist nicht nur ein API, das externe Services aufruft. Jede Entscheidung — jedes Kreditangebot, jedes Kreditlimit, jede Ablehnung — muss erklärbar sein. Das ist nicht optional, es ist eine gesetzliche Anforderung in Deutschland und der gesamten EU. DSGVO, BaFin, die Verbraucherkreditrichtlinie. Der Audit Trail ist kein Nice-to-have; er ist das Produkt.

Das verändert, wie man die Event-Pipeline designed. Man kann nicht einfach process-and-forget. Events müssen unveränderlich, attributiert und abrufbar sein. Das Schema für ein Event in einem Credit-Workflow trägt in manchen Fällen mehr Metadaten als Payload — wer die Entscheidung ausgelöst hat, welche Modellversion konsultiert wurde, welche Regel feuerte, wie die Eingabedaten zum Zeitpunkt der Entscheidung aussahen. All das muss jahrelang überleben.

Auf Kubernetes denkt man dabei auch über Exactly-Once-Semantik auf der Consumer- Seite nach, idempotente Handler und Dead-Letter-Queues, die tatsächlich überwacht werden — statt der Art, die sich still ansammeln, bis jemand merkt, dass die Alerts gedämpft waren. Fragt mich, wie viele Dead-Letter-Queues ich gesehen habe, die als Write-Only-Storage behandelt wurden.

KI/LLM-Automatisierung in einem regulierten Backend zu shippen ist ein anderes Problem

Hier ist das Ding über KI-Integration in Financial Services, das in den meisten Conference-Talks fehlt: Das Modell ist nicht der schwere Teil. LLM-Automatisierung durch ein Compliance-Review zu bekommen, in eine Produktionspipeline einzubetten, in einem regulierten Finanzumfeld — das ist der schwere Teil.

Als ich diese Arbeit bei auxmoney machte, war die Herausforderung nicht Capability. Moderne LLMs sind genuinely nützlich für Dokumentenverständnis, Klassifikation, strukturierte Daten aus unstrukturierten Eingaben extrahieren. Die Herausforderung war Governance. Wie erklärt man eine Entscheidung, bei der ein LLM beteiligt war? Wie versioniert man das Modell so, dass eine Entscheidung vom Januar im Oktober reproduziert und erklärt werden kann, wenn ein Regulierer fragt? Wie testet man, dass der Output des Modells als Signal in einem Human-in-the- Loop-Flow verwendet wird, im Gegensatz zu einem vollautomatisierten, und wie wird das dokumentiert?

Die Antworten beinhalten viel Engineering, das für den User unsichtbar ist. Ein Modell-Call in einem Credit-Workflow ist kein roher API-Call; er ist ein versionierter, geloggter, auditierbarer Aufruf mit einem stabilen Prompt-Template, das auf eine spezifische Modellversion gepinnt ist, mit Output, der neben dem Entscheidungsdatensatz gespeichert wird. Der LLM wird zu einer Komponente in einer auditierbaren Pipeline, nicht zu einer Black Box, die man aufruft und vergisst. Das ist konservativer als das, was die meisten Teams in Consumer-Apps tun, und das sollte es sein. Die Stakes sind anders.

Playing Captain in einer Legacy-PHP-+Java-Codebase

“Highly hands-on in der Codebase als Playing Captain” ist Unternehmensdeutsch für: Ich war ein Principal Architect, der auch Code schrieb, Code reviewte und Dinge fixte, wenn sie in Flammen standen. In einer Fintech-Codebase, die ein Jahrzehnt lang läuft, bedeutet das, die echte Archäologie dessen zu navigieren, was existiert. PHP-Services, die noch vor der Kubernetes-Migration datieren, neben Java-Microservices, die noch vor der Kafka-Adoption datieren, neben frischen Go-Utilities, die jemand letztes Quartal geschrieben hat.

Die Architekturarbeit ist untrennbar von der Realität des bestehenden Codes. Man kann keine schöne neue event-driven Credit-Pipeline designen, ohne den PHP-Service zu berücksichtigen, der die aktuelle Source of Truth für den Kreditnehmer-Status ist und dieses Quartal nicht neu geschrieben wird. Also baut man Adapter, publiziert Domain-Events an den Grenzen der Legacy-Systeme, definiert den Contract auf der Kafka-Topic-Ebene und lässt jeden Service seine eigene Implementierung besitzen. Das ist keine glamouröse Arbeit. Es ist die einzige Arbeit, die tatsächlich shippt.

AWS darunter: EKS für die Kubernetes-Workloads, MSK für das managed Kafka, RDS für den relationalen State, der relational sein muss. Die Infrastruktur ist nicht exotisch. Die Probleme liegen in der Domain, nicht im Stack.

Was diese Art von Arbeit einem wirklich hinterlässt

Lending-Infrastruktur, richtig gemacht, ist eine der technisch gründlichsten Domains, in denen ich gearbeitet habe. Die Kombination aus hohem Transaktionsvolumen, harten Latency-Anforderungen, regulatorischer Erklärbarkeit und den finanziellen Konsequenzen des Falschliegen-Könnens produziert Engineering-Disziplin, die ich in nicht so vielen anderen Umgebungen repliziert gesehen habe.

Ich habe Healthcare-Systeme auf Krankenhausmaßstab geshippt (EHR, Pharmacy- Dispensing, klinische Workflows), Consumer-Apps gebaut, Enterprise-Integration- Archäologie betrieben. Fintech-Credit-Infrastruktur sitzt in einer spezifischen Kategorie: sie bestraft Schlampigkeit auf jeder Schicht, und wenn man es richtig macht, hat man etwas gebaut, das wirklich robust ist. Die Schließung der Business Unit ändert nichts daran, was das System tat, bevor der Org-Chart sich veränderte.

Ich bin aktuell zwischen W-2-Stellen, mache Open-Source-Arbeit an Fulcrum — einer local-first Agent-Control-Plane — und consulting. Wenn du event-driven Financial Infrastructure baust und über Architektur reden willst, weißt du, wo du mich findest.