Regelbasierte Cashflow-Analysen sind tot – wie Vektoren den IT-Abteilungen die Arbeit abnehmen

Regelbasiert ist tot – jedenfalls, wenn es um die Erkennung wiederkehrender Transaktionen geht. Der vektorbasierte Ansatz soll genau da ansetzen, wo klassische Systeme aussteigen. Wolfram Stacklies, CTO vom wealthAPI erklärt im Interview, wie das technisch funktioniert und was es Banken und Versicherer im Echtbetrieb bringt.

Herr Stacklies, was sind die größten Schwächen regelbasierter Transaktionsanalyse – gerade bei wiederkehrenden Zahlungen?

Die größten Schwächen der regelbasierten Transaktionsanalyse, insbesondere im Kontext wiederkehrender Zahlungen, manifestieren sich primär in ihrer inhärenten Intransparenz gegenüber semantischen und kontextuellen Informationen.

Das Hauptproblem ist die Fragilität der Regelwerke gegenüber Variationen und Nuancen im Transaktionsdatensatz.”

Da regelbasierte Systeme auf exakten Mustern und vordefinierten Bedingungen operieren, interpretieren sie weder die Semantik der Transaktionsbeschreibung noch den Kontext der Zahlung. Dies führt zwangsläufig zur Notwendigkeit der Einführung einer proliferierenden Anzahl von Regeln (Regelinflation), um auch nur geringfügige Abweichungen oder neue, aber legitime Muster abzudecken.
Diese Regelinflation resultiert in einem signifikant erhöhten Wartungsaufwand. Die Korrelation und Konsistenzhaltung innerhalb eines umfangreichen Regelwerks wird exponentiell komplexer. Insbesondere bei wiederkehrenden Zahlungen, die sich in Details wie Betrag, Verwendungszweck oder beteiligten Konten leicht ändern können, ohne per se verdächtig zu sein, erfordert die Anpassung der Regeln kontinuierliche Überprüfung und Modifikation.

Ein kritischer Aspekt ist das Potenzial für Regelkonflikte. Die Interaktion einer großen Anzahl von Regeln birgt die Gefahr, dass zum Beispiel Regel 2 und Regel 157 in bestimmten Szenarien konträre Klassifikationen liefern.”

Die Auflösung solcher Konflikte erfordert detaillierte Analysen und potenziell restriktive Priorisierungsmechanismen, welche die Flexibilität und Effektivität des Gesamtsystems weiter einschränken.

Darüber hinaus mangelt es regelbasierten Systemen an der Fähigkeit zur Adaption an sich entwickelnde Betrugsmuster. Da neue Betrugsmaschen typischerweise versuchen, bestehende Regeln zu umgehen, erfordert deren Erkennung eine reaktive und manuelle Anpassung des Regelwerks, was zu einer signifikanten Latenzzeit zwischen dem Auftreten neuer Bedrohungen und deren Detektion führen kann. Die inhärente Statik der Regeln kontrastiert mit der Dynamik betrügerischer Aktivitäten.

Wie funktioniert Ihr vektorbasierter Ansatz technisch genau – inklusive Merkmalsextraktion, Gewichtung und Ähnlichkeitssuche?

Unser Ansatz nutzt KI-Modelle (LLMs/SLMs), um Textinformationen aus Transaktionen (z. B. Verwendungszweck) in Vektoren umzuwandeln. Diese Vektoren fassen die Bedeutung der Texte zusammen, wobei das Modell wichtige Wörter stärker berücksichtigt als unwichtige (wie Datum oder IDs).
Ähnliche Transaktionen haben ähnliche Vektoren.

Um Anomalien zu finden, vergleichen wir den Vektor einer neuen Transaktion mit den Vektoren bekannter, normaler Transaktionen. Je unähnlicher der Vektor ist, desto wahrscheinlicher ist eine Anomalie.”

Das Sprachverständnis der KI hilft uns, Muster und Abweichungen zu erkennen, die rein auf Regeln basierende Systeme oft übersehen würden. Wir suchen also nach Transaktionen, deren „Bedeutung“ ungewöhnlich ist im Vergleich zu dem, was wir normalerweise sehen.

Können Sie das an einem Beispiel zeigen – z.B. bei leicht variierenden Transaktionsdaten?

Betrachten wir das Beispiel wiederkehrender Prämienzahlungen an „Allianz Leben“ und „Allianz Lebensversicherung“ mit leicht variierenden Datumsangaben.
Die LLM/SLM-basierte Merkmalsextraktion erfasst die textuellen Attribute „Allianz Leben 1.1.23“ und „Allianz Lebensversicherung 1.1.24“. Durch das intrinsische Sprachverständnis des Modells werden die Kernentitäten „Allianz Leben“ bzw. „Allianz Lebensversicherung“ als semantisch hochrelevant identifiziert. Die numerischen Datumsangaben „1.1.23“ und „1.1.24“ werden kontextuell als weniger distinktiv für die Art der Transaktion gewichtet.

Die resultierenden Vektorenbettungen für beide Transaktionsbeschreibungen werden im hochdimensionalen Vektorraum eine geringe Distanz zueinander aufweisen. Dies resultiert aus der Fähigkeit des Modells, die semantische Kernidentität („Allianz Leben/Lebensversicherung“) trotz der geringfügigen Variationen in der Oberflächenform (fehlendes „sversicherung“, unterschiedliche Jahreszahl) zu abstrahieren.

Im Rahmen der Ähnlichkeitssuche wird der Vektor der neuen Transaktion mit dem Normalitätsprofil für wiederkehrende Prämienzahlungen verglichen. Da der Vektor sowohl für „Allianz Leben 1.1.23“ als auch für „Allianz Lebensversicherung 1.1.24“ eine hohe Ähnlichkeit zu diesem Profil aufweist (d. h., die Distanz im Vektorraum ist gering), werden beide Transaktionen korrekt als reguläre, wiederkehrende Zahlungen klassifiziert.

Vereinfacht kann man sich das wie bei Wortvektoren vorstellen, wo beispielsweise der Vektor für ‚König‘ plus dem Vektor für ‚Frau‘ sehr nah am Vektor für ‚Königin‘ liegt, weil die Modelle die semantischen Beziehungen zwischen diesen Begriffen gelernt haben.”

Obwohl unsere Transaktionsdaten keine direkten Wortanalogien im gleichen Sinne aufweisen, zeigt dieses Beispiel, wie Vektoren semantische Nähe abbilden können. Bei unseren Transaktionen bedeutet das, dass die inhaltlich sehr ähnlichen, aber formal leicht abweichenden Beschreibungen im Vektorraum benachbart sind und somit als konzeptionell gleichartig behandelt werden, was eine robuste und präzise Klassifizierung ermöglicht.

Wie gut skaliert Ihr System bei tausenden täglichen Transaktionen – und welche Performance-Kennzahlen können Sie teilen?

Unser System ist auf horizontale Skalierbarkeit ausgelegt und bewältigt problemlos das Volumen von tausenden täglichen Transaktionen durch die konsequente Nutzung von Cloud-basierten Infrastrukturen und NoSQL-Datenbanktechnologien.
Die inhärente Architektur dieser Technologien ermöglicht eine dynamische Allokation von Ressourcen in Abhängigkeit von der Last. Bei steigendem Transaktionsvolumen können Computer- und Speicherkapazitäten elastisch und transparent erweitert werden, ohne dass es zu signifikanten Performance-Engpässen kommt. Die NoSQL-Datenbankarchitektur unterstützt eine hochgradig parallele Verarbeitung und optimierte Lese- und Schreiboperationen für große Datenmengen.

Für die Wahl eines KI-Models lohnt es sich, die Kosten im Auge zu behalten und anhand der zu erwartenden Inferenzkosten zu entscheiden, ob ein eigenes Hosting (volle Kontrolle über Hardwarekosten) oder ein SaaS-Modell (Kosten basieren auf Nutzung) gewählt wird.”

Um die AI-Kosten zu minimieren, empfehlen wir unseren Kunden nach Möglichkeit die Implementierung des kleinstmöglichen adäquaten Modells. Größere LLMs/SLMs weisen tendenziell höhere Inferenzkosten (bezüglich Compute-Ressourcen und Latenz) auf, ohne notwendigerweise eine signifikante Verbesserung der Erkennungsleistung für die spezifische Anwendungsdomäne zu bieten. Eine sorgfältige Evaluation der Modellgröße in Bezug auf die erreichte Genauigkeit ist entscheidend für die Kostenoptimierung.

Wie sichern Sie bei asynchroner Verarbeitung die Konsistenz und Integrität der Daten – auch regulatorisch?

Die Sicherstellung von Datenkonsistenz und -integrität bei asynchroner Verarbeitung erfolgt primär durch den Einsatz robuster Messaging-Bus-Systeme mit implementierten Zustellgarantien.
Wir verwenden asynchrone Message Queues als zentrales Kommunikationsmittel zwischen verschiedenen Komponenten unseres Systems. Für jede kritische Operation implementieren wir ein „Senden und Bestätigen“-Muster (Send and Acknowledge).

Sollte die Verarbeitung fehlschlagen oder keine Bestätigung innerhalb eines definierten Timeouts erfolgen, kann der Message Broker die Nachricht erneut zustellen (At-Least-Once Delivery) oder eine Dead-Letter-Queue (DLQ) zur manuellen Fehlerbehebung verwenden. Dies gewährleistet, dass kritische Datenverarbeitungsschritte nicht verloren gehen und die Datenintegrität gewahrt bleibt.

Im Kontext der asynchronen Datenverarbeitung existieren keine spezifischen regulatorischen Vorgaben, die direkt unsere Verarbeitungsmethoden hinsichtlich Konsistenz und Integrität determinieren.”

Die Verantwortung für die Einhaltung relevanter Datenschutzgesetze (z. B. DSGVO) ist davon unberührt und wird durch entsprechende technische und organisatorische Maßnahmen gewährleistet.
Dennoch ist Datensicherheit und -integrität für uns von höchster Priorität. Wir implementieren umfassende Sicherheitsmaßnahmen gemäß Industriestandards und Best Practices (z. B. Verschlüsselung im Transit und im Ruhezustand, Need-to-know-Rollenkonzepte, Audit-Logs).

Die Art der Verarbeitung (synchron vs. asynchron) ist aus regulatorischer Sicht primär relevant für direkt regulierte Institute (z. B. Banken) im Hinblick auf die Einhaltung von Meldepflichten und die Gewährleistung der Richtigkeit und Vollständigkeit von Finanzdaten.

Unsere Verantwortung liegt darin, zuverlässige und sichere Technologien bereitzustellen, die es unseren Kunden ermöglichen, ihre regulatorischen Anforderungen zu erfüllen. Die konkrete Implementierung der Datenverarbeitungspipelines und die Einhaltung spezifischer Bankenregularien obliegen unseren Kunden.”

DSGVO, Mustererkennung, Profiling: Wie gehen Sie technisch mit diesem Spannungsfeld um?

Die technische Handhabung des Spannungsfelds zwischen DSGVO, Mustererkennung und Profiling ist für uns als reiner Technologieanbieter durch eine klare funktionale Trennung und Datenkontrolle charakterisiert.
Wir entwickeln und liefern Werkzeuge und Infrastruktur für die Mustererkennung und Analyse von Transaktionsdaten. Wir selbst verwenden die durch unsere Systeme verarbeiteten Daten unserer Kunden zu keiner Zeit für eigene Zwecke, insbesondere nicht für Marketing oder die Erstellung eigener Nutzerprofile.

Die konkrete Ausgestaltung der Mustererkennung und des Profilings, einschließlich der Definition von Regeln, Schwellenwerten und der Zweckbindung der Datenverarbeitung, liegt vollständig in der Verantwortung und Entscheidungsgewalt unseres Kunden (dem datenverarbeitenden Unternehmen). Dieser entscheidet, welche Daten analysiert werden, wie die Mustererkennung erfolgt und ob bzw. inwieweit Profiling im Einklang mit den DSGVO-Anforderungen durchgeführt wird (z. B. auf Basis einer Rechtsgrundlage wie Einwilligung oder berechtigtem Interesse).
Kurz gesagt:

Wir stellen datenschutzfreundliche Werkzeuge bereit, deren Einsatz im Einklang mit der DSGVO in der Verantwortung unserer Kunden liegt. Unsere technische Architektur ist darauf ausgelegt, die Kontrolle über die Daten und die Art ihrer Verarbeitung beim Kunden zu belassen und jegliche unautorisierte oder zweckfremde Nutzung durch uns auszuschließen.”

Gibt es Anwendungsfälle, bei denen das vektorbasierte System noch an Grenzen stößt?

Obwohl unser vektorbasierter Ansatz wirklich stark darin ist, subtile Muster und semantische Ähnlichkeiten in Transaktionsdaten zu erkennen, gibt es natürlich Bereiche, in denen er an seine Grenzen stoßen kann. Zum Beispiel gibt es häufig Transaktionsdaten, die kaum menschenlesbaren Text enthalten, sondern eher aus reinen Zahlenkolonnen, standardisierten Codes oder internen Systemkennzeichnungen bestehen. In solchen Fällen, wo die eigentliche Stärke der Methode – das Verständnis von Sprache – nicht zum Tragen kommt, ist diese dann möglicherweise nicht mehr so effektiv.

Ein weiterer Punkt sind technische Akronyme und Kürzel, die in Transaktionsbeschreibungen oft vorkommen. Diese sind in den vortrainierten Sprachmodellen nicht immer optimal repräsentiert. Wir können die Modelle zwar daraufhin trainieren, aber das ist aufwändig und birgt das Risiko, dass die Modelle in anderen Bereichen schlechter werden.
Auch die Größe der Modelle spielt eine Rolle.

Sehr große KI-Modelle können zwar ein umfassendes Sprachverständnis haben, aber sie an spezifische Bedürfnisse oder neue Betrugsmuster anzupassen, kann sehr rechenintensiv sein und lange dauern.”

Eine mögliche Lösung, um diese Grenzen zu überwinden, ist die Kombination des vektorisierten Ansatzes mit klassischen, regelbasierten Systemen. Die Regeln können sehr präzise definieren, was wir bereits kennen, während unser KI-System die feineren, semantischen Anomalien aufspürt. Das könnte die Anpassungsfähigkeit deutlich erhöhen.

Und schließlich dürfen wir die Kosten nicht vergessen. Der Einsatz von KI in der Anomalieerkennung kann teuer sein. Wir müssen also sehr sorgfältig abwägen, welche Modelle wir einsetzen und wie wir sie betreiben, um die Kosten im Blick zu behalten und sicherzustellen, dass der Nutzen den Aufwand rechtfertigt.

Wie wird das System für neue Zahlarten oder Anbieter trainiert – und wie fließt Nutzerfeedback mit ein?

Die Anpassung unseres Systems an neue Zahlarten oder Anbieter ist ein fortlaufender Prozess, der im Wesentlichen auf kontinuierlichem Lernen basiert. Wenn eine neue Zahlart oder ein neuer Anbieter auftaucht, beginnen wir damit, relevante Transaktionsdaten zu sammeln, die typische Muster und spezifische Kennzeichnungen dieser neuen Entität enthalten. Idealerweise haben wir auch bereits einige Beispiele, bei denen die korrekte Zuordnung bekannt ist.

Neue Daten nutzen wir dann, um unsere bereits vortrainierten KI-Modelle weiter zu verfeinern, wodurch  das Modell lernt, die besonderen sprachlichen oder numerischen Merkmale dieser neuen Zahlarten oder Anbieter besser zu verstehen und im Vektorraum entsprechend zu repräsentieren.”

Zusätzlich binden wir auch strukturierte Informationen ein. So halten wir beispielsweise unsere Datenbank bekannter Vertragsanbieter wöchentlich auf dem neuesten Stand. Diese Informationen können wir dann nutzen, um die KI bei der Analyse zu unterstützen.

Herr Stacklies, vielen herzlichen Dank für das Interview.Dr. Wolfram Stacklies, WealthAPI