auxmoney: Event-Driven Credit, Deutschlands größter Loan-Marketplace

Lass mich direkt sagen, wie das hier endete: Die Business Unit wurde im April 2025 im Rahmen einer strategischen Umstrukturierung geschlossen. Kein Performance-Problem. Kein technisches Versagen. Fintech ist so - man kann exzellente Infrastruktur liefern und dann trotzdem zusehen, wie das Org-Chart unter einem zusammenfällt. Die Systeme liefen einwandfrei, als das Licht ausging. Dieser Unterschied ist mir wichtig, und ich sage ihn lieber klar heraus, als ihn zu vergraben.

Jetzt. Zum wirklich interessanten Teil.

Was auxmoney ist

auxmoney ist Deutschlands größter Loan-Marketplace - eine Peer-to-Peer-Kreditplattform, die private Kreditnehmer mit institutionellen und privaten Investoren verbindet. Der Maßstab ist real. Der regulatorische Rahmen ist ernst. BaFin, DSGVO, die Verbraucherkreditrichtlinie, deutsches Kreditrecht - jeder dieser Rahmen hat Zähne, die anders beißen, wenn man Kreditentscheidungen in großem Volumen verarbeitet.

Ich kam als Principal Software Engineer und Architect. Der Job war das, was auxmoney “Playing Captain” nennt: hochgradig hands-on in der Codebase, nicht nur Kästchen auf Whiteboards malen. Ich sollte das System tief genug verstehen, um es zu verändern, nicht nur die Änderungen anderer zu reviewen. Dieser Unterschied ist wichtig und wird unterschätzt. Architektur, die nicht darin geerdet ist, wie der Code tatsächlich läuft, ist Fan-Fiction.

Die Credit-Assessment-Pipeline

Ein Kreditnehmer stellt einen Antrag. Dieser Antrag ist keine Zeile in einer Datenbank, die auf einen Cron-Job wartet. Er ist sofort ein Event - und ein Cluster von nachgelagerten Services wartet bereits darauf. Die Credit-Scoring-Pipeline. Die Fraud-Detection-Layer. Die regulatorischen Reporting-Hooks. Die Partner-Lender-Routing-Logik. Jedes davon ist seine eigene Domain, jedes hat seinen eigenen Failure-Mode, und die Anforderung ist, dass keines der anderen blockiert.

Der Happy-Path muss funktionieren. Die Unhappy-Paths - ein Kreditbüro-Call, der timeouttiert, eine Partner-Lender-API, die um 3 Uhr morgens gedrosselt hat, ein Compliance-Check, der einen mehrdeutigen Status zurückgab - all das muss abgehandelt werden, ohne dass der Kreditnehmer irgendetwas davon mitbekommt.

Kafka ist das Rückgrat, weil man Durability, Replay und unabhängigen Consumer-Fortschritt braucht. Der Kreditbüro-Call schlägt fehl? Der Consumer retryt vom committed Offset mit sauberem State. Man muss drei Tage Events replayed, weil ein nachgelagerter Service einen Bug hatte? Consumer zurückspulen. Ein neuer Partner-Lender wird ongeboardet, der Events verarbeiten muss, die bereits passiert sind? Nochmal replayed. Queues vergessen. Kafka erinnert sich. In einem Finanzsystem ist “Ich habe es vergessen” kein akzeptabler Failure-Mode.

Regulatorische Erklärbarkeit ist nicht optional; sie ist das Produkt

Das ist das Ding, das jede Architekturentscheidung im EU-Fintech prägt und das Conference-Talks systematisch undersellen.

Jede Kreditentscheidung - jedes Kreditangebot, jede Ablehnung, jede Limitanpassung - muss erklärbar, zuordenbar und reproduzierbar sein. Nicht als Nice-to-have. Als gesetzliche Anforderung. Wenn ein Regulierer fragt “Warum wurde dieser Kreditnehmer an diesem Datum abgelehnt”, kann die Antwort nicht “wir haben ein Modell laufen lassen und das Modell sagte nein” sein. Man muss die exakten Inputs, die exakte Modellversion, die exakte Regel, die gefeuert hat, und den exakten Human-in-the-Loop-Übergabepunkt, falls es einen gab, rekonstruieren können.

Das verändert das Design der Event-Pipeline. Events sind immutable. Sie tragen in manchen Fällen mehr Metadaten als Payload: wer die Entscheidung initiiert hat, welche Modellversion konsultiert wurde, welche Regel gefeuert hat, wie die Eingabedaten zum Zeitpunkt der Entscheidung aussahen. All das überlebt jahrelang. Auf Kubernetes bedeutet das Exactly-Once-Consumer-Semantik, idempotente Handler und Dead-Letter-Queues, die tatsächlich gemonitort werden. Frag mich, wie viele Dead-Letter-Queues ich gesehen habe, die als Write-only-Storage behandelt wurden. Die Antwort ist: zu viele.

KI/LLM-Automatisierung in eine regulierte Pipeline bringen

Das Modell ist nicht der schwierige Teil. LLM-Automatisierung durch ein Compliance-Review zu bekommen, in einer Produktions-Credit-Pipeline, in einem regulierten Finanzumfeld - das ist der schwierige Teil.

Die Fähigkeit ist wirklich da. Moderne LLMs sind nützlich für Document Understanding, strukturierte Extraktion aus unstrukturierten Inputs, Klassifikation. Sie sind nützlich für Dinge, die ein Kreditantrag im Überfluss produziert: Einkommensnachweise als PDFs, Arbeitsverträge als Scans, selbst gemeldete Daten, die gegen externe Signale normiert werden müssen.

Die Governance ist die Arbeit. Ein Modell-Call in einem Credit-Workflow ist kein rohes API-Call. Er ist ein versionierter, geloggter, auditierbarer Aufruf mit einem stabilen Prompt-Template, das an eine spezifische Modellversion gebunden ist, mit dem Output, der neben dem Entscheidungsprotokoll als Teil des Audit-Trails gespeichert wird. Das LLM wird zu einem Bestandteil einer auditierbaren Pipeline. Man ruft es nicht auf und hofft das Beste. Man behandelt seinen Output als ein Signal in einem dokumentierten, erklärbaren Entscheidungsprozess. Das ist konservativer als das, was die meisten Teams in Consumer-Apps machen. Das sollte es auch sein. Die Stakes sind anders.

Das interessante Engineering liegt in der Integration-Seam: wie der LLM-Output validiert wird, bevor er in den Entscheidungspfad eintritt, wie Confidence-Thresholds zwischen automatischem und manuellem Review gatekeepen, wie Modell-Version-Pinning mit dem Rest der Event-Schema-Versionierung interagiert. Das steht in keinem Tutorial. Es steckt in den Stellen, wo die abstrakte Architektur auf die spezifische Compliance-Anforderung trifft.

Playing Captain in einer jahrzehntealten Codebase

“Playing Captain” ist kein Titel. Es ist eine Beschreibung der Arbeitsweise. Hände im Code, nicht nur in den Docs.

In einer Fintech-Codebase, die seit einem Jahrzehnt läuft, bedeutet das: navigieren, was tatsächlich existiert. PHP-Services, die die Kubernetes-Migration vorausdatieren. Java-Microservices, die die Kafka-Adoption vorausdatieren. Frische Utilities, die jemand letztes Quartal geliefert hat. Das sind keine Legacy-Probleme, für die man sich schämen müsste - es ist akkumulierte Investition in ein System, das seit Jahren echte Kreditentscheidungen für echte Kreditnehmer trifft. Man kann sie nicht ignorieren und nicht alle dieses Quartal umschreiben.

Also baut man an den Grenzen. Man published Domain-Events von den Rändern der Legacy-Systeme. Man definiert den Contract auf der Kafka-Topic-Ebene und lässt jeden Service seine Implementierung besitzen. Der PHP-Service, der die Source of Truth für den Borrower-State ist, wird diesen Sprint nicht ersetzt - er wird in ein Event-Interface verpackt, das der neuen Credit-Assessment-Pipeline ermöglicht, daraus zu konsumieren, ohne seine Interna zu kennen. Das ist die einzige Art Migration, die wirklich geliefert wird.

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

Was diese Art Arbeit zurücklässt

Lending-Infrastruktur, richtig gemacht, ist eine der technisch gründlichsten Domänen, in denen ich gearbeitet habe. Die Kombination aus hohem Transaktionsvolumen, harten Latenzanforderungen, regulatorischer Erklärbarkeit und echten finanziellen Konsequenzen produziert Engineering-Disziplin, die ich anderswo nicht so konsistent gesehen habe.

Als die Business Unit schloss, schloss sie. Das ist das Business. Was das System vor der Org-Chart-Änderung tat, ist eine separate Frage, und die Antwort lautet: es lief gut.

Ich arbeite aktuell open-source an Fulcrum - einer local-first Agent-Control-Plane - und bin offen für Fintech- und Financial-Infrastructure-Gespräche. Wenn du event-driven Credit-Infrastruktur baust und sich über die Compliance-Integration-Layer austauschen möchtest, weißt du, wo ich zu finden bin.