Engineering: Integration, Event-Modell und Deployment
Der Integrationsaufwand hängt nicht davon ab, wie viele Endpunkte Sie aufrufen, sondern wie gut das Event-Modell zu Ihrem Geschäft passt. Truvali erfasst das Event und liefert den Score sowie die Entscheidung: Selbst nicht-monetäre Events folgen exakt demselben Pfad.
Auf dem Engineering-Sektor stellt sich meist die Frage: Wie viel Aufwand ist es, dieses System in unseren bestehenden Ablauf zu integrieren? Die Antwort hängt weniger von der Anzahl der Endpunkte ab, sondern vielmehr davon, wie gut das Event-Modell zu Ihrem Geschäftsmodell passt.
Wie funktioniert der Kernprozess?
Ihre Anwendung sendet ein Event, das System wertet es aus und gibt ein Ergebnis zurück: den Score, die ausgelösten Regeln und die Entscheidung. Die Entscheidung wird so schnell zurückgegeben, dass sie direkt inline im laufenden Prozess genutzt werden kann – denn eine verzögerte Entscheidung ist im Grunde gar keine Entscheidung.
Ein Event ist nicht nur eine Finanztransaktion. Logins, Geräteänderungen, Dokumenten-Uploads, Einstellungsänderungen und Kontoeröffnungen sind ebenfalls Events und werden in den Regeln auf exakt dieselbe Weise verwendet. Diese Unterscheidung ist in der Praxis entscheidend: Muster wie Account Takeover und Bonusmissbrauch lassen sich ohne nicht-monetäre Events nicht abbilden.
Was sollten Sie beim Datenmodell beachten?
| Thema | Bedeutung |
|---|---|
| Isolation von Datenquellen | Daten aus verschiedenen Produkten oder Tochtergesellschaften werden getrennt gehalten, und Regeln werden pro Quelle definiert |
| Aggregationsdefinitionen | Anzahl, Summe und Durchschnitt eines Kunden innerhalb eines Zeitraums sind vordefiniert und werden in den Regeln namentlich referenziert |
| Regel-Versionierung | Das spezifische Regelwerk und die ausgeführte Version werden zusammen mit dem Ergebnis jedes Events gespeichert |
| Identitätsfelder | Geräte-ID, IP, E-Mail und Zahlungsmittel sind die Felder, die zum Aufbau des Beziehungsnetzwerks verwendet werden |
| Entscheidungs-Protokollierung | Die ursprüngliche Entscheidung wird gespeichert, zusammen mit einem Änderungsprotokoll, falls sie später geändert wird |
Die Speicherung der Regelversion zusammen mit dem Event ist eine Audit-Anforderung, aber auch aus technischer Sicht äußerst nützlich: Sie ermöglicht es nachzuvollziehen, welche Regeländerung eine Verhaltensänderung verursacht hat.
Erfordern Regeländerungen ein Deployment?
Nein. Regeln existieren als Daten, nicht als Code. Das bedeutet, dass Compliance- und Betrugserkennungsteams Regeln ändern können, ohne die Entwickler-Pipeline zu belasten, was den Arbeitsaufwand für das Engineering dauerhaft reduziert. Die Struktur einer Regel wird auf der Seite Regel- und Szenario-Engine im Detail beschrieben.
Die Auswirkungen einer Regeländerung auf den historischen Datenverkehr können vor dem Go-Live gemessen werden; dies wird auf der Seite Regelsimulation und Backtesting erklärt.
Wo wird es betrieben?
Das Deployment kann auf der eigenen Infrastruktur des Unternehmens erfolgen. Dies ist in bestimmten Sektoren nicht nur eine Präferenz, sondern eine regulatorische Anforderung: Daten verlassen niemals das Unternehmen, Protokolle verbleiben auf Ihren eigenen Systemen und der Audit-Trail kann an ein separates Ziel gesendet werden. Details finden Sie auf der Seite On-Premise-Deployment.
Autorisierung und Zugriff
Das Autorisierungsmodell umfasst das Maker/Checker-Prinzip, Genehmigungsrichtlinien, Multi-Signatur-Entscheidungen und die Delegation von Befugnissen. Zugriffsprotokolle werden unveränderlich aufbewahrt und können an ein separates Ziel geschrieben werden. Details finden Sie auf der Seite Maker/Checker, Autorisierung und Audit-Trail.
Wo fängt man an?
Normalerweise starten Sie mit einem einzelnen Prozess: dem Punkt, der die meisten Verluste verursacht oder die meisten Warnmeldungen generiert. Events für diesen Prozess werden gesendet, Regeln in der Simulation ausgeführt und die Ergebnisse mit Ihrem bestehenden System verglichen. Fällt der Vergleich zufriedenstellend aus, wird die Entscheidung in den Live-Prozess integriert.
Die entsprechenden Perspektiven der Teams werden auf den Seiten Betrug und Risiko und Compliance-Teams näher erläutert.
Häufige Fragen
- Wie funktioniert die Kernintegration?
- Ihre Anwendung sendet ein Event und das System gibt den Score, die ausgelösten Regeln und die Entscheidung zurück. Die Entscheidung wird so schnell zurückgegeben, dass sie direkt inline im laufenden Prozess genutzt werden kann.
- Werden nur Finanztransaktionen gesendet?
- Nein. Logins, Geräteänderungen, Dokumenten-Uploads, Einstellungsänderungen und Kontoeröffnungen sind ebenfalls Events und werden in den Regeln auf exakt dieselbe Weise verwendet.
- Werden Daten aus verschiedenen Produkten vermischt?
- Nein. Datenquellen werden getrennt gehalten und Regeln können pro Quelle definiert werden.
- Wie werden Aggregationen definiert?
- Anzahl, Summe und Durchschnitt der Transaktionen eines Kunden innerhalb eines Zeitraums sind vordefiniert und werden in den Regeln namentlich referenziert.
- Erfordern Regeländerungen ein Deployment?
- Nein. Regeln existieren als Daten, nicht als Code. Compliance- und Betrugserkennungsteams können Regeln ändern, ohne die Entwickler-Pipeline zu belasten.
- Wie findet man die Ursache für eine Verhaltensänderung?
- Das spezifische Regelwerk und die ausgeführte Version werden zusammen mit dem Ergebnis jedes Events gespeichert, sodass sich genau nachvollziehen lässt, welche Regel die Änderung verursacht hat.
- Wo wird das Deployment gehostet?
- Es kann auf der eigenen Infrastruktur des Unternehmens gehostet werden. Daten verlassen niemals das Unternehmen, Protokolle verbleiben auf Ihren eigenen Systemen und der Audit-Trail kann an ein separates Ziel gesendet werden.
- Wo fängt man am besten an?
- Mit einem einzelnen Prozess, der die meisten Verluste verursacht oder die meisten Warnmeldungen generiert. Events für diesen Prozess werden gesendet, Regeln in der Simulation ausgeführt und die Ergebnisse mit Ihrem bestehenden System verglichen.