Ihr Datentemplate für das KYC-Kunden-Onboarding
Ihr Datentemplate für das KYC-Kunden-Onboarding
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion aus ACTICO
Attribute für das KYC-Kunden-Onboarding
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name des jeweiligen Geschäftsereignisses oder der Aufgabe im Kunden-Onboarding-Prozess. | ||
| Beschreibung Dieses Attribut erfasst den Namen jedes Schritts oder jeder Aktivität im KYC-Prozess, etwa „Antrag eingereicht“, „Risikobewertung durchgeführt“ oder „Antrag genehmigt“. Diese Angaben bilden die einzelnen Schritte der Prozesslandkarte. Anhand des Aktivitätsnamens lässt sich der Prozessablauf visualisieren. Außerdem können Sie häufige und seltene Aktivitäten erkennen sowie Engpässe und Nacharbeitsschleifen aufdecken. Das Attribut ist eine wichtige Grundlage, um zu verstehen, welche Aktionen in welcher Reihenfolge ausgeführt werden. Das ist entscheidend für die Variantenanalyse und Compliance-Prüfungen. Warum das wichtig ist Das Attribut definiert die Schritte in der Prozesslandkarte. So lassen sich der Prozessablauf visualisieren, Abweichungen erkennen und Häufigkeit sowie Reihenfolge der Aktivitäten analysieren. Woher beziehen Diese Informationen finden sich in der Regel in einer Event-Log-Tabelle in ACTICO, häufig in einem Feld, das den Ereignis- oder Aufgabentyp beschreibt. Weitere Angaben enthält die ACTICO-Dokumentation. Beispiele Antrag eingereichtRisikobewertung durchgeführtCompliance-Prüfung abgeschlossenAntrag abgelehnt | |||
| Ereigniszeitpunkt EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität begonnen hat oder stattgefunden hat. | ||
| Beschreibung Der Ereigniszeitpunkt ist das genaue Datum und die genaue Uhrzeit, zu der eine Aktivität im System erfasst wurde. Er legt die chronologische Reihenfolge aller Events innerhalb eines Kundenantrags-Cases fest und bildet so den zeitlichen Ablauf des Onboardings ab. Dieses Attribut ist für alle zeitbasierten Analysen entscheidend. Es dient dazu, Durchlaufzeiten zwischen Aktivitäten zu berechnen, Verzögerungen und Wartezeiten zu erkennen, die Gesamtdauer eines Cases zu messen und die Einhaltung von Service Level Agreements (SLAs) zu prüfen. Anhand der Timestamps eines Cases können Process-Mining-Tools den tatsächlichen Prozessablauf rekonstruieren. Warum das wichtig ist Dieses Attribut legt die chronologische Reihenfolge der Events fest. Das ist wichtig, um Zeitspannen zu berechnen, Engpässe aufzudecken und den zeitlichen Prozessverlauf zu analysieren. Woher beziehen Dieser Timestamp ist in den Event-Log-Tabellen von ACTICO dem jeweiligen protokollierten Vorgang zugeordnet. Weitere Angaben enthält die ACTICO-Dokumentation. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Kundenantrag CustomerApplication | Der eindeutige Bezeichner eines einzelnen Kunden-Onboarding-Antrags. Er dient als Case-ID für die Prozessanalyse. | ||
| Beschreibung Der Kundenantrag ist der zentrale Case-Bezeichner, der alle Events und Aktivitäten eines einzelnen Kunden-Onboardings zusammenfasst. Er steht für eine vollständige Instanz des KYC-Prozesses, von der ersten Einreichung bis zur endgültigen Genehmigung oder Ablehnung. Beim Process Mining ist dieses Attribut entscheidend, um den gesamten Ablauf jedes Antrags zu rekonstruieren. Analysten können damit die Abfolge der Aktivitäten verfolgen, die Gesamtdurchlaufzeit messen und verschiedene Prozesspfade oder Varianten der Anträge vergleichen. Alle Events mit derselben Kundenantrags-ID gehören zum selben Case. Warum das wichtig ist Dieses grundlegende Attribut des Process Mining führt alle zusammengehörigen Events zu einer einzelnen Prozessinstanz zusammen. So lässt sich das Onboarding jedes Kunden von Anfang bis Ende analysieren. Woher beziehen Dies ist ein Primärschlüssel in den Haupttabellen für Anträge oder Case-Verwaltung in ACTICO. Die ACTICO-Dokumentation enthält die genauen Tabellen- und Feldnamen. Beispiele ANTR-2023-001234ANTR-2023-001235ANTR-2024-000001 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs aus ACTICO. Es handelt sich um ein Metadatenfeld für den gesamten Datensatz, nicht für einzelne Ereignisse. So lässt sich einordnen, wie aktuell die Analyse ist. In Dashboards und Berichten hilft diese Information den Benutzern einzuschätzen, wie aktuell die Daten sind. Sie macht deutlich, wie zeitnah die Erkenntnisse sind, und ist für die operative Überwachung wichtig, wenn Daten nahezu in Echtzeit benötigt werden. Die Anzeige dieses Timestamps schafft Transparenz und Vertrauen in die dargestellten Daten. Warum das wichtig ist Zeigt, wie aktuell die Daten sind. So können Benutzer beurteilen, ob sie mit aktuellen Informationen arbeiten, was für operative Entscheidungen entscheidend ist. Woher beziehen Dieser Wert wird beim Extrahieren, Transformieren und Laden der Daten (ETL) erzeugt und gespeichert. Er gibt den Timestamp an, zu dem der ETL-Auftrag erfolgreich abgeschlossen wurde. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Quellsystem SourceSystem | Das führende System, aus dem die Ereignisdaten stammen. | ||
| Beschreibung Dieses Attribut gibt an, aus welchem Informationssystem die Daten stammen. In diesem Prozess lautet der Wert immer „ACTICO“. Bei umfassenderen Analysen mit mehreren Systemen lassen sich damit die Datenquellen unterscheiden. Beim Process Mining ist das Attribut wichtig für Data Governance und Datenvalidierung. Es stellt sicher, dass die Daten der richtigen Quelle zugeordnet werden. Das ist besonders relevant, wenn Daten aus verschiedenen Systemen zusammengeführt werden, um den Prozess vollständig abzubilden. Außerdem lassen sich damit Probleme mit der Datenqualität bis zum Ursprungssystem zurückverfolgen. Warum das wichtig ist Gibt wichtige Informationen zur Herkunft der Daten und unterstützt die Datenherkunftsnachverfolgung sowie die Data Governance. Das ist entscheidend, wenn Daten aus mehreren Quellen zusammengeführt werden. Woher beziehen In der Regel handelt es sich um einen statischen Wert („ACTICO“), der beim Extrahieren und Transformieren der Daten zur Kennzeichnung des Datensatzes hinzugefügt wird. Beispiele ACTICOACTICO-PlattformACTICO-KYC-Modul | |||
| Ablehnungsgrund RejectionReason | Der konkrete Grund für die Ablehnung eines Kundenantrags. | ||
| Beschreibung Wenn der endgültige Status eines Antrags „Abgelehnt“ lautet, gibt dieses Attribut den Grund dafür an. Beispiele sind „Unvollständige Unterlagen“, „Identitätsprüfung nicht bestanden“ oder „Hohes Risikoprofil“. Das Attribut ist wichtig für die Ursachenanalyse. Anhand der Häufigkeit verschiedener Ablehnungsgründe kann das Unternehmen systematische Probleme im Prozess oder bei den eingereichten Kundenunterlagen erkennen. Eine hohe Zahl von Ablehnungen wegen unvollständiger Unterlagen könnte beispielsweise darauf hindeuten, dass die Antragsanweisungen unklar sind. Das unterstützt direkt das Dashboard „Ablehnungsquote und Ablehnungsgründe“. Warum das wichtig ist Zeigt, warum Anträge abgelehnt werden. So können Sie Ursachen analysieren, die Ablehnungsquote senken und die Prozesseffizienz verbessern. Woher beziehen Dieser Wert ist üblicherweise in der Haupttabelle für Cases oder Anträge in ACTICO zu finden und wird oft nur ausgefüllt, wenn der Antragsstatus „Abgelehnt“ lautet. Beispiele Unvollständige UnterlagenIdentitätsprüfung nicht bestandenSanktionslisten-TrefferHoher Risikowert | |||
| Abteilung Department | Die Fachabteilung oder das Team, das für die Ausführung der Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut ordnet eine Aktivität einer Organisationseinheit zu, zum Beispiel „Compliance“, „Onboarding-Team“ oder „Kundenbetreuung“. Dadurch wird der Prozessablauf organisatorisch eingeordnet. Die Analyse auf Abteilungsebene zeigt, wie Arbeit zwischen verschiedenen Bereichen übergeben wird. Sie hilft, abteilungsübergreifende Engpässe zu erkennen, die Effizienz der Abteilungen zu messen und die Ressourcenverteilung zwischen Teams zu untersuchen. In Dashboards können Sie nach Abteilung filtern, damit Führungskräfte die Leistung ihres Teams gezielt auswerten können. Warum das wichtig ist Ergänzt die Analyse um eine organisatorische Dimension. So lassen sich Verzögerungen zwischen Abteilungen erkennen und die Leistung einzelner Teams bewerten. Woher beziehen Diese Information kann direkt mit den Ereignisdaten gespeichert oder durch eine Verknüpfung der Benutzerdaten mit einer HR-Stammdatentabelle abgeleitet werden, in der Benutzer den Abteilungen zugeordnet sind. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele ComplianceOnboarding-TeamKundenservice | |||
| Antragsstatus ApplicationStatus | Das endgültige Ergebnis oder der aktuelle Status des Kunden-Onboarding-Antrags. | ||
| Beschreibung Dieses Attribut gibt das endgültige Ergebnis eines Cases an, üblicherweise „Genehmigt“ oder „Abgelehnt“. Bei laufenden Cases kann es auch den aktuellen Status anzeigen. Es ist eine wichtige Dimension für die ergebnisorientierte Analyse. Ein zentrales Ziel des KYC-Process-Mining ist es, die Gründe für die Genehmigung oder Ablehnung von Anträgen zu verstehen. Mit diesem Attribut können Sie die Prozesslandkarte filtern und typische Abläufe genehmigter und abgelehnter Anträge vergleichen. So lassen sich Prozessmuster erkennen, die zu unerwünschten Ergebnissen führen. Außerdem bildet das Attribut die Grundlage für die Berechnung der KPI „Ablehnungsquote von Anträgen“. Warum das wichtig ist Gibt das Ergebnis jedes Cases an. So lassen sich erfolgreiche und nicht erfolgreiche Prozessinstanzen vergleichen und Ablehnungsquoten berechnen. Woher beziehen Dieses Attribut gilt für den gesamten Case und ist häufig in der Haupttabelle für Cases oder Anträge in ACTICO zu finden. Es gibt den endgültigen Status des Antrags an. Beispiele GenehmigtAbgelehntIn BearbeitungInformationen ausstehend | |||
| Ausführender Benutzer InitiatingUser | Die Benutzer-ID oder der Name des Mitarbeitenden, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut gibt an, welcher Benutzer oder Systemagent für die Ausführung einer Aktivität verantwortlich war. Es ordnet Prozessschritte den Personen oder Teams zu, die sie ausgeführt haben. Die Analyse der Leistung einzelner Benutzer ist häufig gefragt. Mit diesem Attribut lassen sich Dashboards erstellen, die die Arbeitsverteilung, individuelle Verarbeitungszeiten und Leistungsvergleiche zwischen Benutzern oder Teams zeigen. So erkennen Sie leistungsstarke Mitarbeitende ebenso wie möglichen Schulungsbedarf. Außerdem ist das Attribut wichtig, um die Zuweisung und Auslastung von Ressourcen zu verstehen. Warum das wichtig ist Ordnet Prozessaktivitäten bestimmten Benutzern zu. So lässt sich die Leistung einzelner Personen oder Teams analysieren und Schulungsbedarf oder eine unausgewogene Ressourcenauslastung erkennen. Woher beziehen Üblicherweise wird dieser Wert zusammen mit jedem Ereignis im Event Log oder in den Transaktionshistorientabellen von ACTICO gespeichert. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele john.doejane.smithSYSTEM_USER | |||
| Endzeit EndTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität abgeschlossen wurde. | ||
| Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Zusammen mit der Startzeit (EventTime) lässt sich daraus die genaue Dauer einer Aufgabe, also die Verarbeitungszeit, berechnen. Nicht jedes Ereignis hat eine eigene Endzeit, da manche Aktivitäten sofort abgeschlossen sind. Dieses Attribut ist eine wichtige Grundlage für die Leistungsanalyse, insbesondere für die Messung der Dauer einzelner Prozessschritte. Es ermöglicht detaillierte Leistungs-Dashboards, zeigt zeitintensive Aktivitäten auf und ist für die Berechnung von KPIs wie „Durchschnittliche Dokumentenprüfungszeit“ erforderlich. Warum das wichtig ist Ermöglicht die genaue Berechnung der Aktivitätsdauer (Verarbeitungszeit). Das ist wichtig, um Leistungsengpässe zu erkennen und die Ressourceneffizienz zu analysieren. Woher beziehen Wie die Startzeit ist auch dieser Wert üblicherweise in den Event-Log-Tabellen von ACTICO zu finden. Manche Systeme speichern Start- und Endzeit eines Ereignisses in getrennten Spalten. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Risikostufe RiskLevel | Die berechnete Risikostufe des Kundenantrags, zum Beispiel niedrig, mittel oder hoch. | ||
| Beschreibung Dieses Attribut gibt die bewertete Risikokategorie eines Kunden an. Sie bestimmt häufig, wie umfangreich und gründlich der anschließende KYC-Prozess ausfällt. Bei Kunden mit hohem Risiko können zusätzliche Prüfungen und Freigaben erforderlich sein. Beim Process Mining ist die Risikostufe eine wichtige Dimension für Vergleichsanalysen. Analysten können prüfen, ob der Prozess je nach Risikostufe wie vorgesehen unterschiedliche Abläufe nimmt. So lässt sich beispielsweise kontrollieren, ob bei allen Kunden mit hohem Risiko eine erweiterte Sorgfaltsprüfung erfolgt. Das Attribut ist zentral für das Dashboard „Abläufe der Risikobewertung“. Warum das wichtig ist Ermöglicht die Segmentierung von Cases nach Risikostufe. So lässt sich prüfen, ob der Prozess entsprechend den Compliance-Vorgaben an unterschiedliche Risikoprofile angepasst wird. Woher beziehen Dieser wichtige Datenpunkt wird auf Case-Ebene in der Hauptantragstabelle von ACTICO gespeichert. Beispiele NiedrigMittelHoch | |||
| SLA-Zieldatum SlaTargetDate | Das Datum, bis zu dem der Kunden-Onboarding-Prozess voraussichtlich abgeschlossen sein soll. | ||
| Beschreibung Das SLA-Zieldatum ist die Frist für den Abschluss des Kunden-Onboardings, die in internen Service-Level-Vereinbarungen festgelegt ist. Häufig wird es anhand des Antragsdatums und einer standardmäßigen Bearbeitungszeit berechnet. Dieses Attribut ist wichtig, um die Einhaltung von SLAs zu überwachen. Vergleicht das System das tatsächliche Abschlussdatum eines Cases mit dem SLA-Zieldatum, kann es feststellen, ob der Case fristgerecht abgeschlossen wurde oder die SLA-Frist überschritten hat. Das bildet die Grundlage für das Dashboard „SLA-Leistung im Onboarding“ und die KPI „Einhaltungsquote der Onboarding-SLA“. Warum das wichtig ist Dient als Vergleichswert für die Messung fristgerechter Abschlüsse und ermöglicht die direkte Überwachung und Berichterstattung zur SLA-Einhaltung. Woher beziehen Dieser Wert kann als Feld in der Haupttabelle für Cases in ACTICO gespeichert oder anhand von Geschäftsregeln abgeleitet werden, zum Beispiel Antragsdatum + 5 Arbeitstage. Beispiele 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Automatisiert IsAutomated | Kennzeichnet, ob das System eine Aktivität automatisch oder ein Benutzer manuell ausgeführt hat. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aufgaben, die ein Benutzer ausführt, und solchen, die das System automatisiert erledigt, etwa eine Hintergrundprüfung oder Risikobewertung. Die Analyse dieses Attributs zeigt, wie wirksam Automatisierungsmaßnahmen sind. Sie ermöglicht den Vergleich der Verarbeitungszeiten automatisierter und manueller Schritte, macht weiterhin stark manuell geprägte Prozessbereiche sichtbar und kann Ansatzpunkte für weitere Automatisierung aufzeigen, um die Effizienz zu steigern und Betriebskosten zu senken. Warum das wichtig ist Unterscheidet zwischen menschlichen und systemseitigen Aufgaben. Das ist wichtig, um die Wirkung der Automatisierung zu messen und weitere Möglichkeiten zur Effizienzsteigerung zu erkennen. Woher beziehen Der Wert lässt sich aus dem Attribut „InitiatingUser“ ableiten, zum Beispiel wenn der Benutzer „SYSTEM“ ist. Alternativ kann es dafür ein eigenes Kennzeichen im Event Log geben. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele truefalse | |||
| Kundentyp CustomerType | Kategorisierung des Kunden, zum Beispiel Privatperson oder Unternehmen. | ||
| Beschreibung Dieses Attribut ordnet Antragstellende verschiedenen Kategorien zu, etwa einer Privatperson oder einem Unternehmen. Der KYC-Prozess unterscheidet sich zwischen diesen Kundentypen häufig deutlich. Das Onboarding von Unternehmen ist meist wesentlich komplexer. Mit dem Kundentyp als Dimension können Sie diese unterschiedlichen Prozesse im selben Datensatz getrennt betrachten und vergleichen. Analysten können die Prozesslandkarte beispielsweise auf Unternehmenskunden filtern, um deren spezifische Herausforderungen, Engpässe und Zykluszeiten zu untersuchen. Der deutlich einfachere Prozess für Privatpersonen beeinflusst die Ergebnisse dabei nicht. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach Kundengruppen, deren Abläufe und Komplexität sich oft stark unterscheiden. Das sorgt für genauere Analysen. Woher beziehen Dieses grundlegende Attribut wird in ACTICO auf Case- oder Kundenebene gespeichert. Beispiele PrivatpersonUnternehmenKleinunternehmen | |||
| Land Country | Das Wohnsitzland des Kunden, der das Onboarding beantragt. | ||
| Beschreibung Dieses Attribut gibt das Land des Kunden an und kann den KYC-Prozess erheblich beeinflussen. Je nach Rechtsraum gelten unterschiedliche regulatorische Anforderungen, die zusätzliche oder alternative Prozessschritte erforderlich machen können. Die Analyse nach Ländern ermöglicht den Leistungsvergleich zwischen Regionen. Sie kann zeigen, ob bestimmte Länder regelmäßig längere Zykluszeiten oder höhere Ablehnungsquoten aufweisen. Das kann auf regulatorische Hürden oder besondere Marktbedingungen hindeuten. Für international tätige Unternehmen ist diese geografische Perspektive wichtig, um Prozesse zu standardisieren und zugleich lokale Compliance-Anforderungen zu berücksichtigen. Warum das wichtig ist Ergänzt die Analyse um eine geografische Dimension. So lassen sich Prozessabweichungen und Leistungsunterschiede in verschiedenen Rechtsräumen nachvollziehen. Woher beziehen Diese zentrale Kundeninformation wird im ACTICO-System auf Case- oder Kundenebene gespeichert. Beispiele USADEUGBRSGP | |||
| Nacharbeit IsRework | Ein berechnetes Kennzeichen, das angibt, ob eine Aktivität ein wiederholter Schritt oder Teil einer Nacharbeitsschleife ist. | ||
| Beschreibung Dieses boolesche Attribut kennzeichnet Aktivitäten, die innerhalb desselben Cases zum zweiten oder wiederholten Mal ausgeführt werden. Ein Beispiel ist eine erneute Dokumentenprüfung nach einer Rückfrage zu fehlenden Informationen. Es macht Nacharbeit sichtbar, die häufig zu ineffizienten Prozessen führt. Nacharbeit zu erkennen, ist ein zentrales Ziel des Process Mining. Mit diesem Kennzeichen lässt sich ihr Umfang messen, etwa durch die KPI „Nacharbeitsquote bei Dokumenten“. In der Prozesslandkarte können Nacharbeitsschleifen hervorgehoben werden, um zu zeigen, an welchen Stellen der Prozess wieder von vorn beginnt. So lassen sich Qualitätsprobleme und Bereiche erkennen, in denen der Prozess nicht gleich beim ersten Mal richtig abläuft. Warum das wichtig ist Macht wiederholte Arbeit sichtbar. So lässt sich die Prozessineffizienz direkt messen und erkennen, bei welchen Aktivitäten Qualitäts- oder Verständlichkeitsprobleme auftreten. Woher beziehen Dieses Attribut wird berechnet. Die Logik zur Erkennung wiederholter Aktivitäten innerhalb desselben Cases wird im Process-Mining-Tool oder bei der Datentransformation festgelegt. Beispiele truefalse | |||
| SLA-Status SlaState | Ein berechneter Status, der angibt, ob ein Case seine SLA erfüllt hat, die Frist überschritten hat oder gefährdet ist, die Frist zu überschreiten. | ||
| Beschreibung Dieses Attribut bewertet, wie ein Case im Verhältnis zu seiner Service-Level-Vereinbarung abschneidet. Der Status wird ermittelt, indem die Abschlusszeit des Cases oder bei offenen Cases die aktuelle Zeit mit dem „SlaTargetDate“ verglichen wird. Das Attribut vereinfacht die SLA-Berichterstattung, indem es Datumsvergleiche in einen leicht verständlichen Status überführt. Dashboards können damit beispielsweise in Kreisdiagrammen oder Messanzeigen den Anteil der Cases mit dem Status „Erfüllt“ und „Frist überschritten“ darstellen. Das Attribut ist ein wichtiger Bestandteil des Dashboards „SLA-Leistung im Onboarding“ und unterstützt direkt die KPI „Einhaltungsquote der Onboarding-SLA“. Warum das wichtig ist Gibt für jeden Case einen klaren, kategorisierten Status zur SLA-Einhaltung an. Das vereinfacht die Berichterstattung und die Darstellung der Leistung im Vergleich zu den Zielvorgaben. Woher beziehen Dieses berechnete Attribut basiert auf Geschäftslogik, die den Abschluss-Timestamp des Cases mit dem „SlaTargetDate“ vergleicht. Beispiele ErfülltFrist überschrittenGefährdet | |||
Aktivitäten im KYC-Kunden-Onboarding
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Antrag abgelehnt | Diese Aktivität bezeichnet die abschließende Entscheidung, den Kundenantrag abzulehnen und damit den Onboarding-Prozess zu beenden. Sie ist ein wichtiger Endstatus und wird durch eine abschließende Statusänderung im Antragsdatensatz erfasst. | ||
| Warum das wichtig ist Dies ist das primäre End-Event für einen erfolglosen Prozessausgang. Die Analyse der Cases, die mit dieser Aktivität enden, ist wichtig, um Ablehnungsquoten und Ablehnungsgründe zu verstehen und die Gesamterfolgsquote des Prozesses zu verbessern. Woher beziehen Die Aktivität lässt sich aus dem abschließenden Statusfeld in der Haupttabelle des Antrags oder Cases ableiten. Suchen Sie nach einem Endstatus wie „Abgelehnt“ oder „Geschlossen – abgelehnt“. Erfassung Der endgültige Status des Cases wird in den Stammdaten des Cases auf „Abgelehnt“ gesetzt. Ereignistyp inferred | |||
| Antrag eingereicht | Diese Aktivität markiert den Beginn des KYC-Onboarding-Prozesses, sobald ACTICO einen neuen Kundenantrag offiziell erhält. Sie wird als eigenes Event erfasst, in der Regel mit einem genauen Timestamp bei der Erstellung eines neuen Cases oder Antragsdatensatzes. | ||
| Warum das wichtig ist Als primäres Start-Event ist diese Aktivität wichtig, um die gesamte Onboarding-Durchlaufzeit zu berechnen und das Antragsvolumen zu verfolgen. Ihr Timestamp dient als Ausgangspunkt für alle nachfolgenden Messungen der Prozessleistung. Woher beziehen In ACTICO ist dies in der Regel ein expliziter Eintrag im Protokoll zur Erstellung eines Antrags oder Cases. Suchen Sie nach Tabellen zu Ereignissen bei der Antragseinreichung oder nach dem Erstellungs-Timestamp des zentralen Case-Datensatzes. Erfassung Event, das bei der Erstellung eines neuen Antrags-Cases protokolliert wird. Ereignistyp explicit | |||
| Antrag genehmigt | Diese Aktivität bezeichnet die abschließende fachliche Entscheidung, den Kundenantrag für das Onboarding zu genehmigen. Sie ist ein wichtiger Meilenstein und wird in der Regel als eigene, abschließende Statusänderung im Lebenszyklus des Antrags erfasst. | ||
| Warum das wichtig ist Dieser Meilenstein geht der Kontoerstellung voraus und kennzeichnet einen erfolgreichen Ausgang. Die Zeit bis zu diesem Punkt ist wichtig, um die Dauer des Happy Path zu verstehen. Woher beziehen Die Aktivität lässt sich aus dem abschließenden Statusfeld in der Haupttabelle des Antrags oder Cases ableiten. Suchen Sie nach einem Status wie „Genehmigt“, „Genehmigung abgeschlossen“ oder einem ähnlichen positiven Endstatus. Erfassung Der endgültige Status des Cases wird in den Stammdaten des Cases auf „Genehmigt“ gesetzt. Ereignistyp inferred | |||
| Compliance-Prüfung abgeschlossen | Diese Aktivität markiert das Ende der manuellen Prüfung durch die Compliance-Abteilung. Dabei wird entschieden, ob der Antrag genehmigt oder abgelehnt wird oder weitere Schritte erforderlich sind. Sie lässt sich aus einer Statusänderung des Cases von „Compliance-Prüfung ausstehend“ zu einem Folgestatus wie „Compliance genehmigt“ ableiten. | ||
| Warum das wichtig ist Dieses Event schließt die Compliance-Prüfung ab. Es ist wichtig, um deren Gesamtdauer zu berechnen und den Durchsatz des Teams zu analysieren. Woher beziehen Die Aktivität lässt sich aus dem Statusverlauf des Antrags ableiten. Suchen Sie nach dem Timestamp, an dem der Case den Status „In Compliance-Prüfung“ verlässt. Das zeigt an, dass eine Entscheidung getroffen wurde. Erfassung Abgeleitet aus einer Änderung des Case-Status von „Compliance ausstehend“ zu „Compliance genehmigt“ oder einem ähnlichen Status. Ereignistyp inferred | |||
| Compliance-Prüfung gestartet | Diese Aktivität markiert den Beginn der manuellen Prüfung durch die Compliance-Abteilung, häufig bei Anträgen mit hohem Risiko oder bei auffälligen Fällen. Sie lässt sich in der Regel aus einer Statusänderung zu „Compliance-Prüfung ausstehend“ oder aus der Zuweisung des Cases an die Arbeitsliste einer Compliance-Fachkraft ableiten. | ||
| Warum das wichtig ist Diese Aktivität ist der Ausgangspunkt, um den Engpass bei der Compliance-Prüfung zu messen. Die Zeit bis zum Abschluss der Compliance-Prüfung ist eine zentrale Leistungskennzahl, um Verzögerungen in dieser wichtigen Phase zu erkennen. Woher beziehen Die Aktivität lässt sich aus dem Statusverlauf oder dem Audit Trail des Antrags ableiten. Suchen Sie nach einem Timestamp für den Wechsel zu „In Compliance-Prüfung“ oder nach der Zuweisung an eine Compliance-bezogene Benutzergruppe. Erfassung Abgeleitet aus einer Änderung des Case-Status zu „Compliance ausstehend“ oder aus der Zuweisung an das Compliance-Team. Ereignistyp inferred | |||
| Kunden-Onboarding abgeschlossen | Dies ist die letzte Aktivität im Prozess. Sie zeigt an, dass das Onboarding des Kunden vollständig abgeschlossen und der Antrags-Case geschlossen ist. Sie lässt sich aus einem abschließenden Endstatus des Cases ableiten, etwa „Onboarding abgeschlossen“ oder „Geschlossen – genehmigt“. | ||
| Warum das wichtig ist Als primäres Erfolgs-End-Event ist diese Aktivität wichtig, um die Gesamtdurchlaufzeit für alle erfolgreich aufgenommenen Kunden zu berechnen. Sie liefert den abschließenden Timestamp für die Analyse des Happy Path. Woher beziehen Die Aktivität lässt sich aus dem abschließenden Statusfeld des Kundenantrags-Cases ableiten. Suchen Sie nach einem Timestamp für den Wechsel des Cases in einen abschließenden Erfolgsstatus. Erfassung Abgeleitet aus einer abschließenden Statusänderung des Cases zu „Abgeschlossen“ oder „Geschlossen“. Ereignistyp inferred | |||
| Kundendokumente hochgeladen | Diese Aktivität tritt ein, wenn der Kunde die erforderlichen Identitätsnachweise und Belege über ein Portal oder einen anderen mit ACTICO verbundenen Kanal bereitstellt. Jeder Dokumenten-Upload wird in der Regel als eigenes Event im Dokumentenmanagement oder Case-Protokoll des Systems erfasst. | ||
| Warum das wichtig ist Damit ist ein wichtiger Meilenstein erreicht, der vom Kunden abhängt. Die Erfassung dieses Events ist entscheidend, um Reaktionszeiten der Kunden zu messen und die Dauer der anschließenden Dokumentenprüfung zu analysieren. Woher beziehen Suchen Sie nach Event Logs zur Dokumentenbearbeitung oder nach Anhängen am Antrags-Case. Diese Einträge finden sich häufig in eigenen Tabellen für Dokumenten- oder Nachweisverwaltung in der ACTICO-Datenbank. Erfassung Event, das das System protokolliert, wenn ein Dokument an den Case angehängt wird. Ereignistyp explicit | |||
| Risikobewertung durchgeführt | Diese Aktivität bezeichnet die Ausführung der Entscheidungs-Engine von ACTICO, die einen Risikowert oder eine Risikoeinstufung für den Kundenantrag berechnet. Als zentrale Systemfunktion wird sie als eigenes Event erfasst, wenn der Regelsatz für die Risikobewertung ausgeführt wird. | ||
| Warum das wichtig ist Die Risikobewertung ist ein entscheidender Punkt, der häufig den weiteren Prozessverlauf bestimmt. Ihre Analyse zeigt, wie Risikostufen Prozessvarianten und Durchlaufzeiten beeinflussen. Woher beziehen Dies ist ein zentrales Event in ACTICO und sollte in den Entscheidungs- oder Ausführungsprotokollen erfasst sein. Diese Protokolle enthalten in der Regel die Case-ID, die ausgeführten Regeln und den resultierenden Risikowert. Erfassung Event, das die ACTICO-Entscheidungs-Engine nach Abschluss der Risikobewertung protokolliert. Ereignistyp explicit | |||
| Dokumentenprüfung abgeschlossen | Diese Aktivität zeigt an, dass eine mit der Bearbeitung betraute Person die vom Kunden eingereichten Dokumente geprüft hat. Sie lässt sich in der Regel aus einer Statusänderung des Dokuments oder des gesamten Cases ableiten, etwa zu „Dokumente verifiziert“ oder „Prüfung abgeschlossen“. | ||
| Warum das wichtig ist Dieser Meilenstein ist wichtig, um die Effizienz der Dokumentenbearbeitung zu messen. Die Zeit zwischen „Kundendokumente hochgeladen“ und dieser Aktivität ist eine zentrale Leistungskennzahl, um Verzögerungen bei der manuellen Bearbeitung zu erkennen. Woher beziehen Die Aktivität lässt sich aus Statustabellen zum Antrags-Case oder zu einzelnen Dokumenten ableiten. Ein Wechsel des Dokumentstatus von „Prüfung ausstehend“ zu „Genehmigt“ oder „Geprüft“ weist auf diese Aktivität hin. Erfassung Abgeleitet aus einer Änderung des Dokumentstatus zu „Verifiziert“ oder „Geprüft“. Ereignistyp inferred | |||
| Erste Antragsprüfung | Diese Aktivität bezeichnet die erste Prüfung des eingereichten Antrags durch eine automatisierte Regel oder eine mit der Bearbeitung betraute Person. Dabei werden Vollständigkeit und grundlegende Voraussetzungen geprüft. Häufig lässt sie sich aus einer Statusänderung des Antrags ableiten, zum Beispiel von „Eingereicht“ zu „In Prüfung“. | ||
| Warum das wichtig ist Die Dauer dieser ersten Prüfung zeigt, wo es zu Verzögerungen bei der anfänglichen Bearbeitung kommt. Außerdem lässt sich erkennen, wie viele Anträge diese erste Prüfstufe ohne Probleme durchlaufen. Woher beziehen Die Aktivität lässt sich aus Statustabellen oder Audit Logs zum Kundenantrags-Case ableiten. Vergleichen Sie den Timestamp, an dem der Status von „Neu“ oder „Eingereicht“ zu „In Prüfung“ wechselt. Erfassung Erkennen Sie im Case-Verlauf eine Statusänderung von „Eingereicht“ zu „In Prüfung“. Ereignistyp inferred | |||
| Hintergrundprüfungen gestartet | Diese Aktivität bezeichnet den Start automatisierter oder manueller Hintergrundprüfungen, etwa von Geldwäsche- oder Kredithistorien. Sie wird häufig als eigenes Event protokolliert, wenn das System die Prüfungen auslöst, gegebenenfalls unter Einbindung externer Dienstleister. | ||
| Warum das wichtig ist Der Start von Hintergrundprüfungen ist ein wichtiger Meilenstein im Due-Diligence-Prozess. Die Erfassung hilft, Abhängigkeiten und Durchlaufzeiten bei externen Datenanbietern zu verstehen. Woher beziehen Suchen Sie in Systemprotokollen oder im Audit Trail nach Einträgen, die den Start von Hintergrundprüfungen anzeigen. Diese sind häufig mit der Case-ID des Hauptantrags verknüpft. Erfassung Event, das protokolliert wird, wenn die Workflow-Engine Aufrufe an Dienste für Hintergrundprüfungen startet. Ereignistyp explicit | |||
| Identitätsprüfung durchgeführt | Diese Aktivität bezeichnet eine automatisierte oder manuelle Prüfung, bei der die Identität des Kunden anhand externer oder interner Datenquellen verifiziert wird. Häufig wird sie als eigenes Event erfasst, wenn ein API-Aufruf an einen externen Verifizierungsdienst erfolgt und eine Antwort eingeht. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Compliance-Schritt. Die Analyse ihrer Dauer und Ergebnisse zeigt Abhängigkeiten von externen Diensten und mögliche Engpässe bei der Verifizierung. Woher beziehen Diese Informationen finden sich in der Regel in Integrationsprotokollen oder speziellen Event-Tabellen. Dort werden die Ergebnisse automatisierter Prüfungen und Aufrufe externer Dienste zum Antrags-Case erfasst. Erfassung Event, das durch einen Integrationsaufruf an einen externen Identitätsprüfungsdienst protokolliert wird. Ereignistyp explicit | |||
| Konto erstellt | Nach der Genehmigung markiert diese Aktivität die technische Erstellung des Kundenkontos im Kernbank- oder Benutzerverwaltungssystem. ACTICO protokolliert sie häufig als eigenes Event, nachdem das nachgelagerte System den Erfolg bestätigt hat. | ||
| Warum das wichtig ist Diese Aktivität bestätigt, dass der Prozess zu einem konkreten Geschäftsergebnis geführt hat. Die Zeit zwischen „Antrag genehmigt“ und „Konto erstellt“ kann Verzögerungen bei der Integration oder Ineffizienzen bei den abschließenden Bereitstellungsschritten aufzeigen. Woher beziehen Diese Informationen finden sich wahrscheinlich in Integrations- oder Systemschnittstellenprotokollen in ACTICO. Dort wird das Ergebnis von Aufrufen externer Systeme zur Kontobereitstellung erfasst. Erfassung Event, das nach Eingang einer erfolgreichen API-Antwort vom zentralen Kontosystem protokolliert wird. Ereignistyp explicit | |||
| Zusätzliche Informationen angefordert | Diese Aktivität bezeichnet ein Ereignis, bei dem eine prüfende Person, häufig aus den Bereichen Compliance oder Kreditprüfung, weitere Informationen oder Dokumente vom Kunden anfordert. Sie wird in der Regel ausdrücklich erfasst, da dabei oft eine Mitteilung an den Kunden versendet und der Case pausiert wird. | ||
| Warum das wichtig ist Diese Aktivität führt häufig zu Nacharbeit und längeren Durchlaufzeiten. Ihre Häufigkeit und Auswirkungen zu verfolgen, ist wichtig, um Verbesserungsmöglichkeiten bei der anfänglichen Datenerfassung zu erkennen. Woher beziehen Dieses Event wird wahrscheinlich ausdrücklich im Case-Verlauf oder im Mitteilungsprotokoll erfasst. Suchen Sie nach Einträgen wie „Informationsanfrage gesendet“ oder nach einer Statusänderung zu „Kundeninformationen ausstehend“. Erfassung Ein ausdrücklich durch einen Benutzer ausgelöstes Event, etwa „Informationsanfrage senden“, wird im Audit Trail des Cases protokolliert. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Administrativen Zugriff einrichten: Melden Sie sich mit Zugangsdaten, die über ausreichende Berechtigungen für den Zugriff auf Datenexporte und deren Konfiguration verfügen, bei der ACTICO-Plattform an, zum Beispiel im Visual Modeler oder in einer speziellen Administrationskonsole.
- Exportmodul suchen: Öffnen Sie den Administrations- oder Konfigurationsbereich des Systems. Suchen Sie den Abschnitt für Audit-Trails, Protokollierung oder Datenexporte. Er kann beispielsweise „Audit Export“ oder „Business Object Export“ heißen.
- Neue Exportkonfiguration erstellen: Starten Sie die Erstellung einer neuen Exportdefinition. Geben Sie der Konfiguration einen aussagekräftigen Namen, zum Beispiel „KYC_Onboarding_ProcessMind_Export“.
- Datenquelle festlegen: Geben Sie das zu exportierende primäre Business Object an:
CustomerApplication. Begrenzen Sie den Export unbedingt mit einem Datumsfilter, zum Beispiel auf die letzten 6 Monate. So bleiben Dateigröße und Verarbeitungsaufwand überschaubar. - Ausgabedatei konfigurieren: Wählen Sie CSV als Ausgabeformat. Legen Sie den Dateinamen fest, zum Beispiel
kyc_event_log.csv, und bestätigen Sie das Trennzeichen, üblicherweise ein Komma. Achten Sie darauf, Textfelder korrekt in Anführungszeichen zu setzen, damit Sonderzeichen richtig verarbeitet werden. - Case-ID zuordnen: Legen Sie die eindeutige Kennung des Business Objects
CustomerApplicationals Case-ID für die Process-Mining-Analyse fest. So werden alle zugehörigen Events einem einzelnen Onboarding-Case zugeordnet. - Attributzuordnungen festlegen: Ordnen Sie jede erforderliche Spalte im Event Log dem entsprechenden Attribut im ACTICO-Business-Object-Modell zu. Dazu gehören die Case-ID, der Aktivitätsname und die Timestamps sowie weitere empfohlene Attribute wie Status oder Risikostufe.
- Event-Zuordnungen konfigurieren: Dies ist der wichtigste Schritt. Erstellen Sie für jede der 14 Geschäftsaktivitäten eine eigene Regel oder Zuordnung. Verwenden Sie Systemauslöser wie die Objekterstellung für „Antrag eingereicht“, Statusänderungen für Workflow-Schritte wie „Antrag genehmigt“ und bestimmte Audit-Log-Muster für technische Events wie „Identitätsprüfung durchgeführt“.
- Konfiguration speichern und prüfen: Speichern Sie die Konfigurationsdatei, nachdem Sie alle Zuordnungen festgelegt haben. Prüfen Sie mit den verfügbaren Validierungswerkzeugen in ACTICO, ob Syntaxfehler oder ungültige Attributpfade vorliegen.
- Export ausführen und überwachen: Starten Sie den Exportauftrag. Verfolgen Sie den Fortschritt über den Auftragsplaner oder die Überwachungsoberfläche des Systems. Prüfen Sie nach Abschluss die Protokolle auf Fehler.
- Datei abrufen und vorbereiten: Laden Sie die erzeugte CSV-Datei aus dem vorgesehenen Ausgabepfad auf dem Server herunter. Öffnen Sie die Datei vor dem Upload in ProcessMind, um ihre Struktur zu prüfen und sicherzustellen, dass Timestamp- und Datumsformate einheitlich sind und korrekt erkannt werden.
Konfiguration
- Audit-Log-Stufe: Die systemweite Audit-Protokollierung muss auf eine detaillierte Stufe wie INFO oder FINE eingestellt sein. Eine weniger detaillierte Stufe wie WARNING oder ERROR erfasst nicht die erforderlichen Statusänderungen und Regelausführungen für Process Mining.
- Datenquelle für den Export: Als primäre Datenquelle sollte das Business Object
CustomerApplicationkonfiguriert sein. Möglicherweise müssen Sie verknüpfte Objekte wieCustomerDocumenteinbeziehen, um alle relevanten Events zu erfassen. - Datumsfilter: Begrenzen Sie die extrahierte Datenmenge immer mit einem Datumsfilter. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. Im Produktivbetrieb lässt sich der Zeitraum an den geschäftlichen Anforderungen und der Systemleistung ausrichten.
- Logik für Event-Zuordnungen: Die Genauigkeit der Extraktion hängt maßgeblich davon ab, wie Events zugeordnet werden. Statusänderungen (
on="StatusChange") eignen sich häufig, um Geschäftsaktivitäten abzuleiten. Explizite Protokolleinträge (on="LogEntry") sind hilfreich für technische Events oder Serviceaufrufe. Regelausführungen (on="RuleExecution") eignen sich besonders, um Entscheidungsschritte zu erfassen. - Ausgabeformat: Wählen Sie CSV, um eine breite Kompatibilität sicherzustellen. Konfigurieren Sie Trennzeichen und Textbegrenzungen korrekt, damit die Daten fehlerfrei eingelesen werden.
- Voraussetzungen: Für diese Methode benötigen Sie administrative Berechtigungen für die ACTICO-Plattform. Eine genaue Kenntnis des KYC-Business-Object-Modells, einschließlich aller relevanten Statusfelder und Attributnamen, ist für die korrekte Konfiguration unerlässlich.
Beispielabfrage xml
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration> Bereit für den Einstieg?
Verwenden Sie dieses Template, um Ihre Daten effizient aufzubereiten und schneller mit der Optimierung des KYC-Kunden-Onboardings in ACTICO zu beginnen.
Optimieren Sie das KYC-Kunden-Onboarding: Verkürzen Sie die Dauer jetzt auf 24 Stunden
Vermeiden Sie Abbrüche und falsch-positive Ergebnisse für ein reibungsloses Onboarding.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.