Kreditplattform entwickeln – als ein Ablauf: NeoFin vom Antrag bis zur Rückzahlung

Wer eine Kreditplattform entwickeln will, bekommt meist eine Liste von Modulen zu hören: ein Frontend, eine Scoring-Engine, ein Dokumentenwerkzeug, ein Servicing-System. Wir beginnen am anderen Ende. Kreditvergabe ist ein Ablauf – Antrag, Verifizierung, Entscheidung, Dokumente, Auszahlung, Rückzahlung –, und die Plattform muss als dieser Ablauf entworfen werden, bevor sie in Komponenten zerlegt wird.

NeoFin, die Plattform zur Kreditautomatisierung, die wir bauen und betreiben, zeigt, was das bedeutet: wo die Nähte brechen, was über Make or Buy entscheidet und wofür das Modell sonst noch passt.

NeoFin ist eine Cloud-Plattform, die den Kreditzyklus vom Antrag – online, in einer mobilen App oder in der Filiale – bis zu Rückzahlung, Betreuung und dem Umgang mit überfälligen Konten abdeckt. Ein Datenmodell darunter, ein Ablauf darüber: Der Kreditgeber sieht denselben Datensatz vom Antrag bis zur Rückzahlung.

Sie ist aus Komponenten gebaut, nicht als Monolith: 10 vorgefertigte Komponenten, darunter digitales Onboarding und KYC, ein Produktkonfigurator, ein Underwriting-Studio, CRM und BI, ein Datenquellen-Konnektor, die Überwachung von Zahlungsrückständen und Dokumentenmanagement. Sie trägt 3 Produktlinien – Wallet, Zahlungen und Kredite – und 8 Kreditarten auf einem Kern: Payday-Kredite, Konsumentenkredite, POS und BNPL, Kreditkarten, Mikrofinanz, Ratenkredite, Peer-to-Peer und Kreditlinien.

Die Lizenz gehört nicht uns. Die Finanzlizenzierung verbleibt beim jeweiligen Betreiber und der jeweiligen Rechtsordnung; NeoFin läuft in jedem Markt unter der Lizenz des Betreibers, statt sie zu ersetzen. Produkt- und Workflow-Umsetzung liegen bei Logics7. Screens und Module zeigt die Fallstudie zu NeoFin.

Jedes Kreditprodukt durchläuft dieselbe Kette. Baut man sie für jedes neue Produkt neu, wird jeder Launch zum Projekt, und jede Regeländerung berührt mehrere Systeme. Die Alternative ist ein Ablauf in einem Datensatz, in dem jede Stufe liest, was die vorige geschrieben hat.

Antrag und KYC

Hier beginnt der Datensatz. NeoFin nimmt Anträge online, in einer mobilen App oder in der Filiale entgegen, mit Formularen und Identitätsprüfung für Web und Mobile. Jeder Kanal sollte in denselben Datensatz schreiben, damit ein Filialantrag später nicht abgetippt wird. KYC- und AML-Pflichten liegen beim Kreditgeber; eine Plattform sollte die Nachweise einmal erfassen und beim Kredit aufbewahren.

Entscheidung und Underwriting

Kreditscoring und Entscheidung laufen im Underwriting-Studio und in der Entscheidungs-Engine; Daten Dritter kommen über den Datenquellen-Konnektor herein. Die Kreditpolitik – wer infrage kommt, was tragbar ist, zu welchen Konditionen – ist ein Satz von Regeln, die das Geschäft lesen und ohne Release ändern kann. Das unterscheidet eine Entscheidungs-Engine für Kredite von einem im Code vergrabenen Scoring-Aufruf: Die Entscheidung lässt sich prüfen, wenn jemand fragt, warum sie so getroffen wurde.

Dokumente, Signatur und Auszahlung

Kreditdokumente werden elektronisch ausgestellt, unterschrieben und mit dem Antrag aufbewahrt; Dokumentenmanagement und E-Signatur sind Teil der Plattform. Die Auszahlung verweist auf denselben Datensatz wie Entscheidung und Dokument, und Wallet und Payment-Gateway laufen auf derselben Engine wie die Kredite.

Betreuung, Rückzahlung und Inkasso

Nach der Auszahlung wird der Kredit zur Betreuungsaufgabe: Rückzahlungen nach Tilgungsplan, Überwachung von Rückständen und Inkasso. Hier übernimmt üblicherweise ein Loan Management System (LMS) vom Loan Origination System (LOS), und hier trennen viele Plattformen den Datensatz. In NeoFin liegen Kreditvergabe (Origination), Kreditverwaltung und Kreditbuchhaltung auf einem Datenmodell, sodass Betreuung und Inkasso mit der Historie arbeiten, auf deren Grundlage entschieden wurde.

Die meisten Kreditgeber nähen ein Frontend, einen Scoring-Anbieter, ein Dokumentenwerkzeug und ein Servicing-System zusammen. Jedes kann für sich gut sein; das Problem sind die Nähte. Jede Übergabe bedeutet Handarbeit, Verzögerung, Fehler und eine Lücke im Prüfpfad. Kreditnehmerdatensätze doppeln sich, und eine Änderung der Kreditpolitik muss an mehreren Stellen vorgenommen werden.

Das ist der praktische Kern, wenn man eine Kreditplattform entwickeln will. NeoFin wurde so entworfen, dass Entscheidung, Dokument und Zahlung sich auf denselben Datensatz beziehen: Der Prozess verhält sich jedes Mal gleich und bleibt prüfbar. Tempo folgt daraus; es ist nicht das Ziel an sich.

Make or Buy ist bei Kreditsoftware selten eine saubere Wahl. Ein White-Label-Loan-Management-System ist schnell, wenn Ihr Prozess zum Produkt passt. Loan-Origination-Software von Grund auf zu entwickeln lohnt sich nur, wenn die Kreditlogik Ihr Vorteil ist. Produkte auf einem Kern zu konfigurieren liegt dazwischen. Für jede digitale Kreditplattform entscheiden drei Fragen über den Weg.

Lizenzierung und Rechtsordnung

Software trägt keine Lizenz zur Kreditvergabe. Lizenzierung, Datenschutz und Verbraucherkreditrecht unterscheiden sich je Markt; in Großbritannien etwa brauchen Verbraucherkreditunternehmen eine Zulassung der FCA. Klären Sie, wer die Lizenz hält, bevor Sie entscheiden, wie Sie die Kreditplattform entwickeln: Die Software muss zu den Compliance-Pflichten dieses Betreibers passen, nicht umgekehrt.

Wem die Entscheidungslogik gehört

Die Kreditpolitik ist das Geschäft, kein Implementierungsdetail. Liegen die Regeln im Code eines Anbieters, wartet jede Änderung auf ein Release. In NeoFin werden Kreditprodukte, Scoring-Regeln und Abläufe im Produktkonfigurator und im Underwriting-Studio eingestellt, sodass eine Regeländerung kein Release werden muss. Für die Ausnahmen muss trotzdem jemand verantwortlich sein.

Die dritte Frage ist, wer die Plattform betreibt. Die Integration in Buchhaltungs- und Kernsysteme muss entworfen und nicht angeflanscht werden, und die Plattform muss überwacht, ausgeliefert und unterstützt werden. Das ist dauerhafte Arbeit, und deshalb betreiben wir NeoFin, statt es nur auszuliefern.

Dieselbe Struktur – ein Datensatz, Komponenten auf einer Engine, Regeln, die dem Geschäft gehören – trägt weitere Produkte der Kreditautomatisierung:

• →Kreditplattformen für Banken, Mikrofinanzinstitute und Kreditgenossenschaften
• →Buy now, pay later und Händlerkredite
• →Eingebettete Kreditvergabe in Marktplätzen und Plattformen
• →Interne Werkzeuge für Kreditentscheidungen
• →Servicing- und Inkasso-Workflows

Wir bauen sie als Produkte, die betrieben werden: keine Entwicklung ohne Produktlogik. Für ein neues Kreditprodukt prüft Product Partnership zuerst, ob es einen Markt, einen zahlenden Nutzer und einen Weg zum Launch gibt – noch bevor entschieden wird, wie die Kreditplattform entwickelt oder ein MVP zugeschnitten wird. Wenn Ihr Kreditprozess an Übergaben zwischen Systemen hängt, beginnen Sie beim Prozess, nicht beim Werkzeug: Annual Product Operations. Für ein live laufendes Kreditprodukt mit Nutzern, das stagniert, ist Existing Product Review der Weg, auf dem Logics7 entscheidet, ob es eine Beteiligung eingeht.