Tilores für Kreditgeber: Doppelte Finanzierungsanträge vermeiden
Kurzfassung
- Identity Resolution ist in einem modernen Data Stack die Schicht, die rohe Kunden- und Antragsdatensätze aus einem Data Warehouse oder Lakehouse in verwertbaren Kontext für operative Systeme verwandelt: Duplikat, eindeutig oder verbundene Entität.
- Im Fall Banxware blieben die Kunden- und Kreditantragsdaten in Snowflake, Tilores wurde an dieses Warehouse angebunden, und Taktile fragte Tilores über eine API ab, sodass der Risiko-Workflow Signale zu Duplikaten und verbundenen Konten in Echtzeit abrufen konnte.
- Setzen Sie eine dedizierte Entity-Resolution-Schicht ein, wenn exakte Abgleiche im Warehouse für unsaubere Antragstellerdaten, verbundene Unternehmen, Risiken durch verbundene Kunden oder eine hohe manuelle Prüflast nicht ausreichen. Kreditentscheidung, aufsichtsrechtliche Auslegung und Modellentscheidungen bleiben im gesteuerten Risikoprozess des Kreditgebers.
Inhaltsverzeichnis
- Kurze Antwort
- Der nächste Schritt mit Tilores
- Entscheidungshilfe
- Wo Identity Resolution in einem Snowflake-Kreditstack sitzt
- Warum doppelte Finanzierungsanträge schwieriger sind als exakter Abgleich
- Wie Echtzeitabrufe Kreditrisiko-Workflows unterstützen
- Was Sie messen sollten, bevor Sie die manuelle Prüfung ersetzen
- Häufig gestellte Fragen
Kurze Antwort
Identity Resolution sitzt zwischen der Datenplattform und dem Entscheidungs-Workflow. Snowflake oder Databricks können Kunden- und Antragsdatensätze zentralisieren, doch das Risikoteam braucht darüber hinaus eine aufgelöste Entitätsschicht, die vor der Entscheidung erkennt, ob ein neuer Antragsteller eindeutig ist, ein Duplikat darstellt oder möglicherweise mit bestehenden Kunden verbunden ist.
Dieser Quellartikel belegt das Muster am Beispiel Snowflake: Banxware speicherte Kunden- und Kreditantragsdaten in Snowflake, band Tilores an diese Daten an und nutzte eine Taktile-API-Integration, um die Ergebnisse der Tilores-Identity-Resolution in den Kreditrisiko-Workflow zu holen. Dieselbe Architekturfrage stellt sich bei Lakehouse-Stacks, doch der belegte Integrationsnachweis in diesem Artikel bezieht sich auf Snowflake.
Der nächste Schritt mit Tilores
Wählen Sie den nächsten Schritt, der zu Ihrem Evaluierungsstand passt.
Entscheidungshilfe
| Frage | Tilores einsetzen, wenn | Worauf zu achten ist |
|---|---|---|
| Reicht das Warehouse für sich allein? | Snowflake hält die Kunden- und Antragsdaten, aber das Geschäft braucht vor jeder Risikoentscheidung verlässlichen Kontext zu Duplikaten, Eindeutigkeit und verbundenen Konten. | SQL-Regeln und exakter Abgleich fangen offensichtliche Duplikate ab. Unsaubere Antragstellerdaten und verbundene Unternehmen brauchen sorgfältigere Entity-Resolution-Logik. |
| Wo soll das Identitätsergebnis genutzt werden? | Eine Kreditrisikoplattform, ein Betrugs-Workflow oder eine Entscheidungs-Engine braucht per API abrufbaren, aufgelösten Kundenkontext, während die Ursprungsdaten im Data Stack gesteuert bleiben. | Halten Sie Datenzugriff, Berechtigungen, Aufbewahrung und Audit-Anforderungen ausdrücklich fest. Identity Resolution unterstützt den Entscheidungs-Workflow; sie ersetzt keine Risiko-Governance. |
| Sollte das Team eigene Deduplizierungs-Workflows bauen? | Ein Entity-Resolution-System auf Enterprise-Niveau selbst zu bauen würde Entwicklungszeit vom eigentlichen Kreditprodukt abziehen oder eine langfristige Wartungslast erzeugen. | Ein eigener Workflow kann für einen kleinen, stabilen Datenbestand mit geringem Risiko sinnvoll sein. Produktive Fintech-Anwendungsfälle brauchen Monitoring, Schwellenwerte, Prüfpfade und Kontrolle über False Positives. |
| Welches Risikosignal soll der Workflow zurückgeben? | Der Kreditgeber muss wissen, ob ein Antragsteller eindeutig, doppelt oder möglicherweise mit anderen Kunden verbunden ist, bevor die Kreditrisikoprüfung weiterläuft. | Behandeln Sie Entity Resolution nicht als rechtliche oder aufsichtsrechtliche Garantie. Sie liefert Match-Kontext, den die Risiko-, Compliance- und Entscheidungsteams des Kreditgebers auslegen müssen. |
Wo Identity Resolution in einem Snowflake-Kreditstack sitzt
In einem Snowflake-zentrierten Kreditstack kann das Warehouse der Ort bleiben, an dem Kunden- und Kreditantragsdatensätze liegen, während Identity Resolution als operative Schicht jene Datensätze verknüpft, die zur selben Person, zum selben Unternehmen oder zu einer verbundenen Gruppe gehören.
Der aufgelöste Kontext muss dann für die Systeme verfügbar sein, die Kreditentscheidungen treffen oder unterstützen. Im Banxware-Workflow fragte Taktile Tilores über eine API ab, sodass der Risikoprozess abrufen konnte, ob ein Kunde eindeutig, doppelt oder möglicherweise mit einem anderen Banxware-Kunden verbunden war.
Warum doppelte Finanzierungsanträge schwieriger sind als exakter Abgleich
Doppelte Finanzierungsanträge enthalten häufig kleine Abweichungen in den Angaben der Antragsteller. Namen, Firmendatensätze, Adressen und Kontaktfelder passen nicht sauber zusammen – gerade wenn ein Antragsteller zuvor schon über einen Marktplatz oder Händlerpartner beantragt hat.
Damit ist ein einfacher exakter Abgleich für Risikoteams eine schwache Kontrolle. Das nützliche Signal ist nicht nur, ob zwei Zeilen identisch sind, sondern ob mehrere Datensätze auf denselben Antragsteller, dasselbe Unternehmen oder auf Konten verweisen, die eng genug verbunden sein könnten, um eine Prüfung auszulösen.
Wie Echtzeitabrufe Kreditrisiko-Workflows unterstützen
Ein Kreditgeber braucht Identity Resolution nicht nur als nachgelagerten Datenqualitätsbericht. Der Risiko-Workflow braucht den aktuellen aufgelösten Kundenkontext, während ein Antrag geprüft wird, damit Signale zu Duplikaten und verbundenen Konten berücksichtigt werden können, bevor der Entscheidungspfad weitergeht.
Im vorliegenden Fall band Tilores die Snowflake-Daten von Banxware an, und Taktile baute die API-Integration, die die Tilores-Daten in den Kreditrisiko-Workflow von Banxware brachte. Das ist die praktische Aufgabenteilung: Das Warehouse speichert die Daten, Tilores löst den Identitätskontext auf, und die Entscheidungsplattform ruft das Ergebnis ab.
Was Sie messen sollten, bevor Sie die manuelle Prüfung ersetzen
Der zugrunde liegende Fall berichtet von einer Reduktion der manuellen Prüfung von Kreditanträgen um nahezu 100 %, von einem Tag für die Konfiguration der Snowflake-Integration, von einer Woche für die Taktile-API-Integration und von einer deutlichen Steigerung bei der Erkennung nicht offensichtlicher Duplikate und verbundener Konten gegenüber dem manuellen Prozess.
Diese Kennzahlen sind als Belege aus der Banxware-Fallstudie zu lesen, nicht als allgemeingültiger Benchmark. Ein Kreditgeber, der dasselbe Muster prüft, sollte Prüfvolumen, Duplikaterkennung, Erkennung verbundener Konten, False Positives, False Negatives, Integrationsaufwand und die Frage verfolgen, wie das Risikoteam die Match-Belege prüft.
Banxware ist ein Anbieter für eingebettetes Lending as a Service, angetreten mit dem Ziel, den Zugang zu Kapital zu demokratisieren. Banxware nimmt die Komplexität heraus, Kreditvergabe selbst aufzubauen: Das Unternehmen sichert die Kreditlinie, übernimmt KYC, AML und Kreditentscheidungen und verwaltet Auszahlungen und Rückzahlungen. Über diese Lösung können Plattformen und Zahlungsdienstleister wie Fiserv, Forto und Lieferando ihren Verkäufern vollständig digitale Geschäftskredite anbieten.
Lesen Sie auch die Fallstudie auf der Website von Banxware.
Herausforderungen bei der Risikoentscheidung
Banxware muss zu jedem Kreditantrag kleiner Unternehmen eine individuelle Kreditrisikoentscheidung treffen, wenn diese über die Marktplätze und Händlerpartner des Unternehmens eine Finanzierung beantragen.
Sämtliche kunden- und kreditantragsbezogenen Daten von Banxware liegen in Snowflake, der cloudbasierten Data-Warehouse-Lösung. Bevor das Risikoteam von Banxware über die Genehmigung eines Kreditantrags entscheidet, muss es zunächst prüfen, ob der Antragsteller bereits zuvor eine Finanzierung beantragt hat oder schon Kunde von Banxware ist.
Dieser Prozess bereitete dem Risikoteam von Banxware Kopfzerbrechen, denn kleine Abweichungen in den Angaben der Antragsteller machten es schwer, doppelte Anträge zu finden, die auf mögliche Betrugsfälle hindeuten können. Hinzu kommt, dass Banxware die Leitlinien der Europäischen Bankenaufsichtsbehörde (EBA) zu „Gruppen verbundener Kunden" einhalten muss, um Konzentrationsrisiken durch Kredite an verschiedene, tatsächlich aber miteinander verbundene Unternehmen zu vermeiden.
Mit steigendem Kreditvolumen brauchte Banxware eine besser skalierbare Lösung.
Die Partnerschaft mit Tilores
„Da ich schon zuvor hoch skalierbare Kreditplattformen aufgebaut habe, weiß ich, wie entscheidend gute Daten für Kreditrisikoentscheidungen und Betrugsprävention sind. Umso mehr habe ich mich über die Partnerschaft mit Tilores gefreut. Ihre Identity-Resolution-Technologie liefert uns genau das, was wir brauchen, um in Echtzeit zu erkennen, ob Kreditantragsteller Duplikate oder wirklich eigenständige Kunden sind." – Nicolas Kipp, Mitgründer und Chief Risk Officer bei Banxware.
Banxware zog in Betracht, eigene Workflows zur Erkennung doppelter Daten im Data Warehouse zu bauen, erkannte aber, dass der Aufbau eines Entity-Resolution-Systems auf Enterprise-Niveau teuer wäre und wertvolle Entwicklungskapazität von der Arbeit am Kernprodukt abziehen würde.
Mit Tilores fand das Unternehmen einen Snowflake Technology Partner, der bereits über eine maßgeschneiderte Integration verfügte, die die Anbindung an Snowflake schnell und einfach macht. Das Risikoteam von Banxware konnte Tilores mit dem Snowflake Data Warehouse verbinden, ohne das Entwicklungsteam einbinden zu müssen.
Ein weiterer Technologiepartner von Banxware, Taktile, die Entscheidungsplattform für Kreditrisiken, baute über die API eine Integration mit Tilores. Damit werden die Kundendaten in Tilores über Taktile in Echtzeit abgefragt, um zu prüfen, ob ein Kunde eindeutig, ein Duplikat oder möglicherweise mit anderen Banxware-Kunden verbunden ist.
Mit der Entity-Resolution-Technologie von Tilores an seiner Seite verfügt Banxware nun über die fortschrittliche Dateninfrastruktur, die seine Kreditrisikomodelle ergänzt und mit dem Unternehmen mitwächst – auf dem Weg, Europas führender Anbieter für Embedded Finance zu werden.
Besuchen Sie Banxware
Wichtigste Kennzahlen
- ✅ Reduktion der manuellen Prüfung von Kreditanträgen um nahezu 100 %.
- ✅ Ein Tag für die Konfiguration der Tilores-Integration mit dem Snowflake Data Warehouse von Banxware.
- ✅ Eine Woche, bis Taktile eine API-Integration gebaut und die Tilores-Daten in den Workflow der Kreditrisikoabteilung von Banxware eingebunden hatte.
- ✅ Deutliche Steigerung bei der Erkennung nicht offensichtlicher Kundenduplikate und verbundener Konten gegenüber dem manuellen Prozess.
Häufig gestellte Fragen
- Wie fügt sich Identity Resolution in einen modernen Data Stack mit Snowflake oder Databricks ein?
- Identity Resolution sitzt zwischen den gespeicherten Kundendatensätzen und den nachgelagerten operativen Workflows. Das Warehouse oder Lakehouse zentralisiert die Daten, während die Identity-Resolution-Schicht doppelte oder verbundene Datensätze verknüpft und Entscheidungssystemen den aktuellen aufgelösten Kundenkontext bereitstellt.
- Kann Deduplizierung in Snowflake allein doppelte Finanzierungsanträge erkennen?
- Snowflake kann Deduplizierungslogik abbilden, insbesondere für exakte oder regelbasierte Prüfungen. Eine dedizierte Entity-Resolution-Schicht passt besser, wenn die Angaben der Antragsteller variieren, Übereinstimmungen unscharf sind, verbundene Unternehmen eine Rolle spielen und das Ergebnis von einem laufenden Risiko-Workflow abgerufen werden muss.
- Warum setzte Banxware Tilores zusammen mit Snowflake ein?
- Banxware speicherte Kunden- und Kreditantragsdaten in Snowflake und brauchte einen skalierbaren Weg, doppelte Antragsteller und möglicherweise verbundene Kunden vor Kreditrisikoentscheidungen zu erkennen. Tilores wurde an die Snowflake-Daten angebunden, und Taktile band Tilores für den Risiko-Workflow über eine API ein.
- Ersetzt Tilores die Kreditrisikoentscheidung oder die Compliance-Prüfung?
- Nein. Tilores liefert Kontext aus der Identity Resolution, etwa ob ein Antragsteller eindeutig, doppelt oder möglicherweise mit einem anderen Kunden verbunden erscheint. Kreditgenehmigung, aufsichtsrechtliche Auslegung, Compliance-Kontrollen und die endgültige Risikoentscheidung bleiben in der Verantwortung des Kreditgebers und seines gesteuerten Entscheidungsprozesses.
Tilores mit Ihren eigenen Daten testen
Wählen Sie den nächsten Schritt, der zu Ihrem Evaluierungsstand passt.
Sehen Sie, was aufgelöste Entitätsdaten für Ihr Unternehmen — und Ihre KI — leisten.