Echtzeit-Risk-Scoring
Risk-Scoring reduziert das von einem Kunden oder einer Transaktion ausgehende Risiko auf einen einzigen, messbaren Wert, um diesen für Entscheidungsprozesse nutzbar zu machen. Truvali behandelt diesen Score nicht als statisches Label, sondern als dynamischen Wert, der bei jedem neuen Ereignis in Echtzeit neu berechnet wird.
Warum ein Score nicht statisch sein kann
In vielen Instituten wird das Kundenrisiko beim Onboarding festgelegt und einmal jährlich überprüft. Risiko verändert sich jedoch mit dem Verhalten des Kunden. Ein Kunde, der beim Onboarding als risikoarm eingestuft wurde, kann sechs Monate später ein völlig anderes Profil aufweisen.
Truvali aktualisiert den Score ereignisbasiert. Bei einer neuen Transaktion, einem neuen Gerät, einer Profiländerung oder einem Screening-Treffer wird der Score basierend auf der aktuellen Realität neu berechnet.
Was wird bewertet?
- Kunden-Score: Onboarding-Daten, Screening-Ergebnisse, Verhaltenshistorie und bei Firmenkunden die Eigentümerstruktur.
- Transaktions-Score: Betrag, Uhrzeit, Kanal, Gegenpartei und Abgleich mit dem üblichen Verhalten des Kunden.
- Gegenpartei-Score: Historie des Empfängers, Beziehungsnetzwerk und Blacklist-Status.
Diese drei Scores beeinflussen sich gegenseitig: Eine Transaktion mit einer Hochrisiko-Gegenpartei wirkt sich sowohl auf den Transaktions- als auch auf den Kunden-Score aus.
Kombination aus finanziellen und nicht-finanziellen Signalen
Das Besondere an diesem Score ist, dass er sich nicht nur auf Geldbewegungen stützt. Auch der Branchencode des Unternehmens, der Firmenname, das Gründungsjahr, die Uhrzeit der Transaktion und die Gerätehistorie fließen in die Berechnung ein.
Dadurch werden auch Fälle erfasst, die unterhalb von Betragsschwellenwerten liegen: Eine POS-Transaktion um 03:00 Uhr nachts erhöht den Score, selbst wenn der Betrag gering ist, da sie im Widerspruch zu den branchenüblichen Erwartungen steht.
Wofür wird der Score verwendet?
- Entscheidungsschwellen: Transaktionen oberhalb eines bestimmten Scores werden abgelehnt, genauer überwacht oder einer zusätzlichen Verifizierung unterzogen.
- Kundenannahme (Onboarding): Ein hoher Score löst eine Weiterleitung zur Video-Identifizierung aus.
- Priorisierung von Untersuchungen: Die Fall-Queue wird nach dem Score sortiert; die begrenzte Zeit wird für die risikoreichsten Fälle aufgewendet.
- Periodische Überprüfung: Kunden, die eine verstärkte Sorgfaltspflicht (Enhanced Due Diligence) erfordern, werden anhand ihres Scores identifiziert.
Die Gewichtung bestimmt das Institut
Welches Signal wie stark gewichtet wird, hängt von der Risikopolitik des Instituts ab; dies ist keine Änderung, die beim Software-Team angefordert werden muss. Anpassungen von Gewichtungen und Schwellenwerten können vor dem Live-Gang anhand historischer Daten getestet werden. So sehen Sie im Voraus, wie stark eine Schwellenwertänderung die Untersuchungs-Queue vergrößern würde.
Vorteile für das Institut
- Eine verzögerungsfreie Bewertung, die das Risiko bei jedem Ereignis aktuell hält.
- Eine nachvollziehbare und dokumentierte Zusammensetzung des Scores aus den einzelnen Signalen.
- Ein einheitlicher Maßstab für Onboarding-, Transaktions- und Untersuchungsentscheidungen.
- Eine nachweisbare Risikoklassifizierung, wie sie vom risikobasierten Ansatz gefordert wird.
Häufige Fragen
- Wie oft wird der Risikoscore aktualisiert?
- Nicht periodisch, sondern ereignisbasiert. Bei einer neuen Transaktion, einer Geräteänderung, einer Profilaktualisierung oder einem Screening-Treffer wird der Score sofort neu berechnet.
- Können wir Auditoren oder der Aufsicht zeigen, wie der Score zustande kommt?
- Ja. Die zum Score beitragenden Signale und deren Gewichtung werden lückenlos protokolliert. Warum eine Entscheidung getroffen wurde, lässt sich direkt im jeweiligen Fall nachvollziehen. Dies ist entscheidend für die Dokumentation des risikobasierten Ansatzes.
- Können wir das Scoring-Modell selbst anpassen?
- Ja. Die Signalwichtungen und Entscheidungsschwellen werden gemäß der Risikopolitik des Instituts konfiguriert. Änderungen können vor der Liveschaltung anhand historischer Daten getestet werden.