Ihr Daten-Template für das KYC-Kunden-Onboarding
Ihr Daten-Template für das KYC-Kunden-Onboarding
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion aus ACTICO
Attribute des KYC-Kunden-Onboardings
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name des konkreten Geschäftsevents oder der Aufgabe, die im Customer-Onboarding-Prozess ausgeführt wird. | ||
| Beschreibung Dieses Attribut erfasst den Namen jedes Schritts oder jeder Aktivität im KYC-Prozess, etwa „Application Submitted“, „Risk Assessment Performed“ oder „Application Approved“. Es bildet die sequenziellen Bausteine der Prozessdarstellung. Die Analyse des Aktivitätsnamens ermöglicht die Visualisierung des Prozessflusses, die Identifizierung häufiger oder seltener Aktivitäten sowie die Erkennung von Engpässen und Nacharbeitschleifen. Das Attribut ist zentral, um zu verstehen, welche Aktionen in welcher Reihenfolge ausgeführt werden. Diese Informationen sind für die Variantenanalyse und Compliance-Prüfungen entscheidend. Warum das wichtig ist Es definiert die Schritte in der Prozessdarstellung und ermöglicht die Visualisierung des Prozessflusses, die Erkennung von Abweichungen sowie die Analyse der Häufigkeit und Reihenfolge von Aktivitäten. Bezugsquelle Diese Informationen finden sich typischerweise in einer Event-Log-Tabelle innerhalb von ACTICO, häufig in einem Feld, das den Event- oder Aufgabentyp beschreibt. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele Antrag eingereichtRisikobewertung durchgeführtCompliance-Prüfung abgeschlossenAntrag abgelehnt | |||
| Event-Zeit EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität begonnen hat oder stattgefunden hat. | ||
| Beschreibung Event-Zeit bezeichnet das genaue Datum und die genaue Uhrzeit, zu denen eine Aktivität im System erfasst wurde. Sie liefert die chronologische Reihenfolge aller Events innerhalb eines Kundenantrags-Cases und bildet damit die Zeitachse der Onboarding-Journey. Dieses Attribut ist für alle zeitbezogenen Analysen entscheidend. Es dient dazu, Durchlaufzeiten zwischen Aktivitäten zu berechnen, Verzögerungen und Wartezeiten zu erkennen, die gesamte Case-Dauer 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 Prozessfluss rekonstruieren. Warum das wichtig ist Dieses Attribut liefert die chronologische Reihenfolge der Events. Das ist entscheidend für die Berechnung von Dauern, die Erkennung von Engpässen und die Analyse der Prozesszeitachse. Bezugsquelle Dieser Timestamp befindet sich in den Event-Log-Tabellen von ACTICO und ist der jeweiligen erfassten Aktivität zugeordnet. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Kundenantrag CustomerApplication | Der eindeutige Bezeichner für einen einzelnen Kunden-Onboarding-Antrag, der als Case-ID für die Prozessanalyse dient. | ||
| Beschreibung Der Kundenantrag ist der primäre Case-Bezeichner, der alle Events und Aktivitäten einer einzelnen Customer-Onboarding-Journey zusammenfasst. Er steht für eine vollständige Instanz des KYC-Prozesses, von der ersten Einreichung bis zur abschließenden Genehmigungs- oder Ablehnungsentscheidung. Im Process Mining ist dieses Attribut entscheidend, um die End-to-End-Journey jedes Antrags zu rekonstruieren. Es ermöglicht Analysten, die Abfolge der Aktivitäten zu verfolgen, die gesamte Durchlaufzeit zu messen und unterschiedliche Prozesspfade oder Varianten verschiedener Anträge zu vergleichen. Alle Events mit derselben Kundenantrags-ID gelten als Teil desselben Cases. Warum das wichtig ist Dies ist das grundlegende Attribut für Process Mining. Es verbindet alle zusammengehörigen Events zu einer einzigen, konsistenten Prozessinstanz und ermöglicht die End-to-End-Analyse der Customer Experience beim Onboarding. Bezugsquelle Dies ist ein Primärschlüssel in den zentralen Tabellen für Anträge oder Case-Management innerhalb von ACTICO. Die konkreten Tabellen- und Feldnamen entnehmen Sie bitte der ACTICO-Dokumentation. Beispiele APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten zuletzt aus dem Quellsystem aktualisiert oder 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 Events, und liefert Kontext zur Aktualität der Analyse. In Dashboards und Berichten ist diese Information wichtig, damit Sie den Aktualitätsstand der Daten einschätzen können. Sie hilft dabei, Erwartungen an die zeitliche Nähe der Erkenntnisse zu steuern, und ist für die operative Überwachung relevant, wenn Daten nahezu in Echtzeit benötigt werden. Die Anzeige dieses Timestamps schafft Transparenz und stärkt das Vertrauen in die dargestellten Daten. Warum das wichtig ist Zeigt die Aktualität der Daten an. So können Sie beurteilen, ob Sie mit aktuellen Informationen arbeiten, was für operative Entscheidungen entscheidend ist. Bezugsquelle Dieser Wert wird während des Prozesses zur Extraktion, Transformation und zum Laden der Daten (ETL) erzeugt und gespeichert. Er entspricht dem Timestamp, zu dem der ETL-Job erfolgreich abgeschlossen wurde. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Quellsystem SourceSystem | Das führende System, aus dem die Event-Daten stammen. | ||
| Beschreibung Dieses Attribut identifiziert das Informationssystem, in dem die Daten erzeugt wurden. Für diesen Prozess lautet der Wert durchgehend „ACTICO“. Bei umfassenderen Analysen mit mehreren Systemen hilft es jedoch, die Datenquellen voneinander zu unterscheiden. Im Process Mining ist dieses Attribut für Data Governance und Validierung entscheidend. Es stellt sicher, dass Daten korrekt ihrer Quelle zugeordnet werden. Das ist besonders wichtig, wenn Daten aus verschiedenen Systemen zusammengeführt werden, um eine vollständige Prozesssicht zu erstellen. Außerdem unterstützt es die Analyse von Datenqualitätsproblemen, indem sich diese bis zum Ursprungssystem zurückverfolgen lassen. Warum das wichtig ist Liefert wichtigen Kontext zur Datenherkunft und stellt Datenherkunft und Governance sicher. Das ist besonders relevant, wenn Daten aus mehreren Quellen kombiniert werden. Bezugsquelle In der Regel handelt es sich um einen statischen Wert („ACTICO“), der während der Datenextraktion und -transformation zur Kennzeichnung des Datensatzes ergänzt wird. Beispiele ACTICOACTICO PlatformActico KYC Module | |||
| Ablehnungsgrund RejectionReason | Der konkrete Grund, der bei der Ablehnung eines Kundenantrags angegeben wird. | ||
| Beschreibung Wenn der finale Status eines Antrags „Rejected“ lautet, gibt dieses Attribut die zugrunde liegende Ursache an. Beispiele sind „Incomplete Documentation“, „Failed Background Check“ oder „High Risk Profile“. Dieses Attribut ist für die Ursachenanalyse besonders wichtig. Durch die Analyse der Häufigkeit verschiedener Ablehnungsgründe kann das Unternehmen systematische Probleme im Prozess oder bei den Einreichungen von Kunden erkennen. Eine hohe Zahl von Ablehnungen wegen unvollständiger Dokumente kann beispielsweise darauf hindeuten, dass die Antragsanweisungen unklar sind. Dieses Attribut unterstützt direkt das Dashboard „Antragsablehnungsquote und -gründe“. Warum das wichtig ist Zeigt, warum Anträge abgelehnt werden. So können Sie Ursachen analysieren, die Ablehnungsquote senken und die Prozesseffizienz verbessern. Bezugsquelle Befindet sich normalerweise in der zentralen Case- oder Antragstabelle von ACTICO und wird häufig nur ausgefüllt, wenn der Antragsstatus „Rejected“ lautet. Beispiele Unvollständige DokumentationIdentitätsprüfung fehlgeschlagenTreffer auf einer SanktionslisteHoher Risikowert | |||
| Abteilung Department | Die Geschäftsabteilung oder das Team, das für die Ausführung der Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut ordnet eine Aktivität einer bestimmten Organisationseinheit zu, etwa „Compliance“, „Onboarding Team“ oder „Client Relations“. Es liefert den organisatorischen Kontext zum Prozessfluss. Die Analyse auf Abteilungsebene ist entscheidend, um Übergaben zwischen verschiedenen Organisationseinheiten zu verstehen. Sie hilft, abteilungsübergreifende Engpässe zu erkennen, die Effizienz einzelner Abteilungen zu messen und die Ressourcenverteilung über Teams hinweg zu analysieren. Dashboards lassen sich nach Abteilung filtern, damit Führungskräfte die Leistung ihres Teams gezielt betrachten können. Warum das wichtig ist Liefert eine organisatorische Dimension für die Analyse. So lassen sich Verzögerungen zwischen Abteilungen erkennen und die Leistung auf Teamebene bewerten. Bezugsquelle Diese Informationen können direkt bei den Event-Daten gespeichert oder durch eine Verknüpfung der Benutzerdaten mit einer HR-Stammdatentabelle abgeleitet werden, die Benutzer den Abteilungen zuordnet. Ziehen Sie die ACTICO-Dokumentation zu Rate. Beispiele ComplianceOnboarding-TeamKundenservice | |||
| Antragsstatus ApplicationStatus | Das finale Ergebnis oder der aktuelle Status des Kundenantrags für das Onboarding. | ||
| Beschreibung Dieses Attribut zeigt das finale Ergebnis eines Cases an, typischerweise „Approved“ oder „Rejected“. Es kann auch den Status laufender Cases abbilden. Damit ist es eine wichtige Dimension für ergebnisbezogene Analysen. Zu verstehen, warum Anträge genehmigt oder abgelehnt werden, ist ein zentrales Ziel des KYC Process Mining. Mit diesem Attribut können Sie die Prozessdarstellung filtern und die typischen Journeys 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 des KPI „Antragsablehnungsquote“. Warum das wichtig ist Definiert das Ergebnis jedes Cases und ermöglicht den Vergleich erfolgreicher und nicht erfolgreicher Prozessinstanzen sowie die Berechnung von Ablehnungsquoten. Bezugsquelle Dies ist ein Case-Attribut, das sich in ACTICO häufig in der zentralen Case- oder Antragstabelle befindet. Es bildet den finalen Status des Antrags ab. Beispiele GenehmigtAbgelehntIn BearbeitungAusstehende Informationen | |||
| Auslösender Benutzer InitiatingUser | Die Benutzer-ID oder der Name des Mitarbeitenden, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Benutzer oder Systemagenten, der für die Ausführung einer Aktivität verantwortlich ist. Es verknüpft Prozessschritte mit den Personen oder Teams, die sie ausgeführt haben. Die Analyse der Leistung nach Benutzer ist eine häufige Anforderung. Dieses Attribut ermöglicht Dashboards zur Verteilung des Arbeitsaufkommens, zu individuellen Bearbeitungszeiten und zu Leistungsvergleichen zwischen Benutzern oder Teams. Es hilft, besonders leistungsstarke Mitarbeitende ebenso zu erkennen wie Personen mit zusätzlichem Schulungsbedarf, und ist für das Verständnis von Ressourcenzuweisung und -auslastung wichtig. Warum das wichtig ist Verknüpft Prozessaktivitäten mit bestimmten Benutzern. So können Sie die Leistung einzelner Personen oder Teams analysieren und Schulungsbedarf oder ein Ungleichgewicht bei den Ressourcen erkennen. Bezugsquelle Wird typischerweise zusammen mit jedem Event 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) ermöglicht sie die Berechnung der genauen Dauer jeder Aufgabe, also der Bearbeitungszeit. Nicht jedes Event verfügt über eine eigene Endzeit, da manche Events unmittelbar stattfinden. Dieses Attribut ist für die Leistungsanalyse grundlegend, insbesondere zur Messung der Dauer einzelner Schritte. Es ermöglicht detaillierte Performance-Dashboards, zeigt besonders zeitintensive Aktivitäten auf und ist für KPIs wie „Durchschnittliche Dokumentenprüfungsdauer“ erforderlich. Warum das wichtig ist Ermöglicht die genaue Berechnung von Aktivitätsdauern, also der Bearbeitungszeit. Das ist entscheidend, um Leistungsengpässe zu erkennen und die Ressourceneffizienz zu analysieren. Bezugsquelle Wie die Startzeit befindet sich auch dieser Wert typischerweise in den Event-Log-Tabellen von ACTICO. Manche Systeme speichern Start- und Endzeit eines einzelnen Event-Datensatzes 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, etwa niedrig, mittel oder hoch. | ||
| Beschreibung Dieses Attribut steht für die bewertete Risikokategorie eines Kunden. Sie bestimmt häufig die Komplexität und Gründlichkeit des anschließenden KYC-Prozesses. Für einen Kunden mit hohem Risiko können im Vergleich zu einem Kunden mit niedrigem Risiko zusätzliche Prüfungen und Genehmigungen erforderlich sein. Im Process Mining ist Risk Level eine wichtige Dimension für vergleichende Analysen. Damit können Analysten prüfen, ob der Prozess abhängig vom Risiko wie vorgesehen unterschiedliche Pfade durchläuft. So lässt sich beispielsweise verifizieren, dass alle Kunden mit hohem Risiko eine erweiterte Due-Diligence-Prüfung durchlaufen. Das Attribut ist zentral für das Dashboard „Risk Assessment Process Flows“. Warum das wichtig ist Ermöglicht die Segmentierung von Cases nach Risiko. So lässt sich analysieren, ob der Prozess die unterschiedlichen Risikoprofile entsprechend den Compliance-Vorgaben korrekt berücksichtigt. Bezugsquelle Dies ist ein wichtiger Datenpunkt, der auf Case-Ebene in der Hauptanwendungstabelle von ACTICO gespeichert wird. 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 gemäß den internen Service-Level-Vereinbarungen. Häufig wird dieses Datum aus dem Eingangsdatum des Antrags und einer standardmäßigen Bearbeitungszeit berechnet. Dieses Attribut ist für die Überwachung der SLA-Einhaltung entscheidend. Durch den Vergleich des tatsächlichen Abschlussdatums eines Cases mit seinem SLA-Zieldatum kann das System feststellen, ob der Case fristgerecht abgeschlossen wurde oder ob das SLA verletzt wurde. Darauf basieren das Dashboard „Onboarding SLA Performance“ und der KPI „Onboarding SLA Adherence Rate“. Warum das wichtig ist Liefert den Maßstab für die Messung der fristgerechten Bearbeitung und ermöglicht die direkte Überwachung und Berichterstattung zur SLA-Einhaltung. Bezugsquelle Dieses Attribut kann als Feld in der zentralen Case-Tabelle von ACTICO gespeichert oder anhand von Geschäftsregeln abgeleitet werden, beispielsweise aus Eingangsdatum des Antrags plus fünf Arbeitstagen. Beispiele 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Automatisiert IsAutomated | Ein Kennzeichen dafür, ob eine Aktivität automatisch vom System oder manuell von einem Benutzer ausgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aufgaben, die von einem menschlichen Benutzer ausgeführt werden, und Aufgaben der Systemautomatisierung, etwa einer automatisierten Hintergrundprüfung oder Risikobewertung. Die Analyse dieses Attributs hilft bei der Bewertung der Wirksamkeit von Automatisierungsinitiativen. Sie ermöglicht den Vergleich der Bearbeitungszeiten automatisierter und manueller Schritte, zeigt weiterhin stark manuell geprägte Prozessabschnitte auf und kann Ansatzpunkte für zusätzliche Automatisierung liefern, um die Effizienz zu steigern und Betriebskosten zu senken. Warum das wichtig ist Unterscheidet zwischen menschlichen und systemseitigen Aufgaben. Das ist entscheidend, um die Auswirkungen der Automatisierung zu messen und weitere Effizienzpotenziale zu erkennen. Bezugsquelle Dieses Attribut kann aus dem Attribut „InitiatingUser“ abgeleitet werden, beispielsweise wenn der Benutzer „SYSTEM“ ist, oder als eigenes Kennzeichen im Event Log vorliegen. Prüfen Sie dazu die ACTICO-Dokumentation. Beispiele truefalse | |||
| Kundentyp CustomerType | Kategorisierung des Kunden, beispielsweise als Privatperson oder Unternehmen. | ||
| Beschreibung Dieses Attribut ordnet den Antragsteller verschiedenen Kategorien zu, etwa einer Privatperson oder einem Unternehmen. Der KYC-Prozess unterscheidet sich zwischen diesen Typen häufig deutlich, da das Onboarding von Unternehmen wesentlich komplexer ist. Customer Type ermöglicht die klare Trennung und den Vergleich dieser unterschiedlichen Prozesse innerhalb desselben Datensatzes. Analysten können die Prozessübersicht auf Kunden des Typs „Corporate“ filtern, um deren spezifische Herausforderungen, Engpässe und Durchlaufzeiten zu verstehen. Die deutlich einfachere Bearbeitung von Kunden des Typs „Individual“ verfälscht die Analyse dadurch nicht. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach unterschiedlichen Kundengruppen. Diese weisen häufig stark voneinander abweichende Prozessabläufe und Komplexitätsgrade auf, was zu genaueren Analysen führt. Bezugsquelle Dies ist ein grundlegendes Attribut, das in ACTICO auf Case- oder Kundenebene gespeichert wird. 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. In unterschiedlichen Rechtsordnungen gelten unterschiedliche regulatorische Anforderungen, die zusätzliche oder alternative Prozessschritte auslösen können. Die Analyse nach Ländern ermöglicht den Vergleich der Prozessleistung in verschiedenen Regionen. Sie kann zeigen, ob bestimmte Länder regelmäßig längere Durchlaufzeiten oder höhere Ablehnungsquoten aufweisen. Das kann auf regulatorische Hürden oder spezifische Herausforderungen einzelner Märkte hindeuten. Diese geografische Perspektive ist für global tätige Unternehmen wichtig, die ihre Prozesse standardisieren und zugleich lokale Compliance-Anforderungen berücksichtigen möchten. Warum das wichtig ist Liefert eine geografische Analysedimension und hilft dabei, Prozessvarianten und Leistungsunterschiede in verschiedenen regulatorischen Rechtsordnungen zu verstehen. Bezugsquelle Dies ist eine zentrale Kundeninformation, die im ACTICO-System auf Case- oder Kundenebene gespeichert wird. Beispiele USADEUGBRSGP | |||
| Nacharbeit IsRework | Ein berechnetes Kennzeichen, das angibt, ob eine Aktivität ein wiederholter Schritt ist oder zu einer Nacharbeitsschleife gehört. | ||
| Beschreibung Dieses boolesche Attribut kennzeichnet Aktivitäten, die innerhalb desselben Cases zum zweiten Mal oder wiederholt ausgeführt werden, beispielsweise eine „Document Review“ nach einer Aufforderung zur Nachreichung von Informationen. Es identifiziert Nacharbeit, die typischerweise eine Ursache für Ineffizienz im Prozess ist. Die Erkennung von Nacharbeit ist ein zentrales Ziel des Process Mining. Mit diesem Kennzeichen lässt sich Nacharbeit quantifizieren, etwa durch die Berechnung des KPIs „Document Rework Rate“. In der Prozessübersicht können Nacharbeitsschleifen hervorgehoben werden, um sichtbar zu machen, an welchen Stellen der Prozess zurückspringt. So lassen sich Qualitätsprobleme oder Bereiche erkennen, in denen der Prozess nicht beim ersten Durchlauf korrekt abgeschlossen wird. Warum das wichtig ist Macht wiederholte Arbeit sichtbar. Dadurch lassen sich Prozessineffizienzen direkt messen und Aktivitäten mit Qualitäts- oder Verständlichkeitsproblemen identifizieren. Bezugsquelle Dies ist ein berechnetes Attribut. Die Logik wird im Process-Mining-Tool oder während der Datentransformation definiert, um wiederholte Aktivitäten innerhalb desselben Cases zu erkennen. Beispiele truefalse | |||
| SLA-Status SlaState | Ein berechneter Status, der angibt, ob ein Case sein SLA eingehalten, verletzt oder voraussichtlich verletzen wird. | ||
| Beschreibung Dieses Attribut bewertet kategorisch, wie ein Case im Verhältnis zu seinem Service Level Agreement abschneidet. Es wird aus dem Vergleich der Abschlusszeit des Cases oder bei offenen Cases der aktuellen Zeit mit dem „SlaTargetDate“ abgeleitet. Das Attribut vereinfacht die SLA-Berichterstattung, indem es Datumsvergleiche in einen leicht verständlichen Status überführt. Dashboards können damit klare Visualisierungen erstellen, etwa Kreisdiagramme oder Anzeigen, die den Anteil der Cases mit den Statuswerten „Met“ und „Breached“ darstellen. Es ist ein zentrales Element des Dashboards „Onboarding SLA Performance“ und unterstützt direkt den KPI „Onboarding SLA Adherence Rate“. Warum das wichtig ist Liefert für jeden Case einen klaren, kategorischen Status zur SLA-Einhaltung. Dadurch werden Berichte vereinfacht und Leistungswerte im Verhältnis zu den Zielvorgaben leicht visualisierbar. Bezugsquelle Dies ist ein berechnetes Attribut, das aus einer Geschäftslogik abgeleitet wird. Sie vergleicht den Abschlusszeitpunkt des Cases mit dem „SlaTargetDate“. Beispiele EingehaltenVerletztGefährdet | |||
Aktivitäten des KYC-Kunden-Onboardings
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Antrag abgelehnt | Diese Aktivität bezeichnet die abschließende Entscheidung, den Kundenantrag abzulehnen, und beendet damit den Onboarding-Prozess. Sie ist ein kritischer Endstatus, der durch eine abschließende Statusänderung im Antragsdatensatz erfasst wird. | ||
| Warum das wichtig ist Dies ist das primäre negative End-Event. Die Analyse von Cases, die mit dieser Aktivität enden, ist entscheidend, um Ablehnungsquoten und Ablehnungsgründe zu verstehen und den gesamten Prozessertrag zu verbessern. Bezugsquelle Abgeleitet aus dem finalen Statusfeld der Haupttabelle für Anträge oder Cases. Suchen Sie nach einem Endstatus wie „Rejected“, „Declined“ oder „Closed - Rejected“. Erfassen Der finale Status des Cases wird in den Case-Stammdaten auf „Rejected“ aktualisiert. Ereignistyp inferred | |||
| Antrag eingereicht | Diese Aktivität markiert den Beginn des KYC-Onboarding-Prozesses, sobald das ACTICO-System einen neuen Kundenantrag offiziell erhält. Sie wird als explizites Event erfasst und beim Anlegen eines neuen Cases oder Antragsdatensatzes in der Regel mit einem präzisen Timestamp protokolliert. | ||
| Warum das wichtig ist Als primäres Start-Event ist diese Aktivität entscheidend für die Berechnung der gesamten Onboarding-Durchlaufzeit und die Ermittlung des Antragsvolumens. Sie dient als Ausgangs-Timestamp für alle nachfolgenden Messungen der Prozessleistung. Bezugsquelle In der Regel handelt es sich um einen expliziten Eintrag im Protokoll zur Erstellung eines Antrags oder Cases in ACTICO. Suchen Sie nach Tabellen zu Ereignissen bei der Antragseinreichung oder nach dem Erstellungs-Timestamp des primären Case-Datensatzes. Erfassen Event, das beim Erstellen einer neuen Antragsinstanz protokolliert wird. Ereignistyp explicit | |||
| Antrag genehmigt | Diese Aktivität bezeichnet die abschließende Geschäftsentscheidung, den Kundenantrag für das Onboarding zu genehmigen. Sie ist ein wichtiger Meilenstein und wird typischerweise als eigene, abschließende Statusänderung im Lebenszyklus des Antrags erfasst. | ||
| Warum das wichtig ist Dieser Meilenstein geht der Kontoeröffnung voraus und steht für einen erfolgreichen Ausgang. Die Analyse der Zeit bis zu diesem Punkt ist entscheidend, um die Dauer des „Happy Path“ zu verstehen. Bezugsquelle Abgeleitet aus dem finalen Statusfeld der Haupttabelle für Anträge oder Cases. Suchen Sie nach einem Status wie „Approved“, „Approval Complete“ oder einem vergleichbaren positiven Endstatus. Erfassen Der finale Status des Cases wird in den Case-Stammdaten auf „Approved“ aktualisiert. Ereignistyp inferred | |||
| Compliance-Prüfung abgeschlossen | Dies markiert das Ende der manuellen Prüfung durch die Compliance-Abteilung mit der Entscheidung, den Antrag zu genehmigen, abzulehnen oder weitere Maßnahmen anzufordern. Die Aktivität lässt sich aus einer Statusänderung des Cases von „Pending Compliance Review“ in einen nachfolgenden Status wie „Compliance Approved“ ableiten. | ||
| Warum das wichtig ist Dies ist das Abschluss-Event der Compliance-Prüfungsphase. Es ist erforderlich, um die gesamte Dauer der Compliance-Prüfung zu berechnen und den Durchsatz des Teams zu analysieren. Bezugsquelle Abgeleitet aus dem Statusverlauf des Antrags. Suchen Sie nach dem Timestamp, zu dem der Case den Status „In Compliance Review“ verlässt und damit eine Entscheidung anzeigt. Erfassen Abgeleitet aus der Änderung des Case-Status von „Pending Compliance“ in „Compliance Approved“ oder einen vergleichbaren Status. Ereignistyp inferred | |||
| Compliance-Prüfung gestartet | Dies markiert den Beginn der manuellen Prüfung durch die Compliance-Abteilung, häufig bei Anträgen mit hohem Risiko oder entsprechenden Auffälligkeiten. In der Regel lässt sich die Aktivität aus einer Änderung des Case-Status in „Pending Compliance Review“ oder aus der Zuweisung des Cases an die Arbeitswarteschlange eines Compliance-Beauftragten ableiten. | ||
| Warum das wichtig ist Diese Aktivität bildet den Ausgangspunkt für die Messung des Compliance-Engpasses. Die Zeit bis zu „Compliance Review Completed“ ist ein zentraler KPI, um Verzögerungen in dieser wichtigen Prozessphase zu erkennen. Bezugsquelle Abgeleitet aus der Statushistorie oder dem Audit Trail des Antrags. Suchen Sie nach einem Timestamp, der mit der Statusänderung in „In Compliance Review“ oder der Zuweisung an eine Compliance-bezogene Benutzergruppe verbunden ist. Erfassen Abgeleitet aus der Änderung des Case-Status in „Pending Compliance“ oder der Zuweisung an das Compliance-Team. Ereignistyp inferred | |||
| Customer Onboarding abgeschlossen | Dies ist die letzte Aktivität des Prozesses. Sie zeigt an, dass der Kunde vollständig aufgenommen und der Antrags-Case geschlossen wurde. Sie lässt sich aus einem finalen Endstatus wie „Onboarded“ oder „Closed - Approved“ ableiten, der dem Case zugewiesen wird. | ||
| Warum das wichtig ist Als primäres erfolgreiches End-Event ist diese Aktivität entscheidend für die Berechnung der End-to-End-Durchlaufzeit aller erfolgreich aufgenommenen Kunden. Sie liefert den abschließenden Timestamp für die Analyse des Happy Path. Bezugsquelle Abgeleitet aus dem finalen Statusfeld des Kundenantrags-Cases. Suchen Sie nach einem Timestamp, der mit dem Wechsel des Cases in einen erfolgreichen Endstatus verbunden ist. Erfassen Abgeleitet aus einer abschließenden Aktualisierung des Case-Status in „Completed“ oder „Closed“. Ereignistyp inferred | |||
| Kundendokumente hochgeladen | Diese Aktivität findet statt, wenn der Kunde die erforderlichen Identitäts- und Nachweisdokumente über ein Portal oder einen anderen in ACTICO integrierten Kanal bereitstellt. Jeder Upload wird normalerweise als eigenes, explizites Event im Dokumentenmanagement- oder Case-Protokoll des Systems erfasst. | ||
| Warum das wichtig ist Dies markiert einen wichtigen, vom Kunden abhängigen Meilenstein. Die Erfassung dieses Events ist entscheidend, um die Reaktionszeiten der Kunden zu messen und die Dauer der anschließenden Dokumentenprüfung zu analysieren. Bezugsquelle Suchen Sie nach Event Logs zur Dokumentenverarbeitung oder nach Anhängen des Antrags-Cases. Diese werden in der ACTICO-Datenbank häufig in eigenen Tabellen für Dokumente oder Nachweise gespeichert. Erfassen Event, das vom System protokolliert wird, sobald ein Dokument an den Case angehängt wird. Ereignistyp explicit | |||
| Risikobewertung durchgeführt | Diese Aktivität bezeichnet die Ausführung der Decisioning Engine von ACTICO zur Berechnung eines Risikoscores oder einer Risikoeinstufung für den Kundenantrag. Als zentrale Systemfunktion wird sie als explizites Event erfasst, sobald das Regelwerk für die Risikobewertung ausgeführt wird. | ||
| Warum das wichtig ist Die Risikobewertung ist ein entscheidender Entscheidungspunkt, der den weiteren Prozesspfad häufig vorgibt. Die Analyse dieser Aktivität zeigt, wie Risikostufen Prozessvarianten und Durchlaufzeiten beeinflussen. Bezugsquelle Dies ist ein zentrales Event in ACTICO und sollte in den Entscheidungs- oder Ausführungsprotokollen erfasst sein. Diese Protokolle enthalten typischerweise die Case-ID, die ausgeführten Regeln und den resultierenden Risikoscore. Erfassen Event, das von der ACTICO Decision Engine nach Abschluss der Risikobewertung protokolliert wird. Ereignistyp explicit | |||
| Dokumentenprüfung abgeschlossen | Diese Aktivität zeigt an, dass ein Mitarbeitender die vom Kunden eingereichten Dokumente vollständig geprüft hat. In der Regel lässt sie sich aus einer Statusänderung des Dokuments oder des gesamten Cases ableiten, etwa „Documents Verified“ oder „Review Complete“. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein zur Messung der Effizienz der Dokumentenverarbeitung. Die Zeit zwischen „Customer Documents Uploaded“ und dieser Aktivität ist ein zentraler KPI, um Verzögerungen bei der manuellen Bearbeitung zu erkennen. Bezugsquelle Abgeleitet aus Statuseinträgen zum Antrags-Case oder zu einzelnen Dokumenten. Eine Änderung des Dokumentstatus von „Pending Review“ zu „Approved“ oder „Reviewed“ weist auf diese Aktivität hin. Erfassen Abgeleitet aus einer Änderung des Dokumentstatus in „Verified“ oder „Reviewed“. Ereignistyp inferred | |||
| Erste Antragsprüfung | Diese Aktivität bezeichnet die erste Prüfung des eingereichten Antrags durch eine automatisierte Regel oder einen Mitarbeitenden. Dabei werden Vollständigkeit und grundlegende Voraussetzungen geprüft. Häufig lässt sie sich aus einer Statusänderung des Antrags ableiten, etwa von „Submitted“ zu „In Review“. | ||
| Warum das wichtig ist Die Analyse der Dauer dieser ersten Prüfung hilft, Verzögerungen in der anfänglichen Bearbeitung zu erkennen. Außerdem zeigt sie, wie viele Anträge diese erste Prüfstufe ohne Probleme passieren. Bezugsquelle Abgeleitet aus Statustabellen oder Audit Logs, die dem Kundenantrags-Case zugeordnet sind. Vergleichen Sie den Timestamp, zu dem sich der Status von „new“ oder „submitted“ in einen Prüfstatus ändert. Erfassen Erkennen Sie die Statusänderung von „Submitted“ zu „Under Review“ im Case-Historienprotokoll. Ereignistyp inferred | |||
| Hintergrundprüfungen gestartet | Diese Aktivität bezeichnet den Beginn automatisierter oder manueller Hintergrundprüfungen, etwa von AML- oder Kredithistorien. Häufig wird sie als explizites Event protokolliert, sobald das System diese 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 dieses Schritts hilft, Abhängigkeiten und Durchlaufzeiten externer Datenanbieter zu verstehen. Bezugsquelle Suchen Sie in Systemprotokollen oder einem Audit Trail nach Einträgen, die das Auslösen von Hintergrundprüfungen anzeigen. Diese sind häufig mit der ID des Hauptantrags-Cases verknüpft. Erfassen Event, das protokolliert wird, sobald die Workflow Engine Aufrufe an Dienste für Hintergrundprüfungen auslöst. Ereignistyp explicit | |||
| Identitätsprüfung durchgeführt | Diese Aktivität bezeichnet eine automatisierte oder manuelle Prüfung, bei der die Identität des Kunden mit externen oder internen Datenquellen abgeglichen wird. Häufig wird sie als explizites Event erfasst, sobald 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 hilft, Abhängigkeiten von externen Diensten und mögliche Engpässe im Verifizierungsprozess zu erkennen. Bezugsquelle Diese Informationen finden sich in der Regel in Integrationsprotokollen oder speziellen Event-Tabellen, in denen die Ergebnisse automatisierter Prüfungen und Aufrufe externer Dienste zum Antrags-Case gespeichert werden. Erfassen Event, das aus einem Integrationsaufruf an einen externen Dienst zur Identitätsprüfung protokolliert wird. Ereignistyp explicit | |||
| Konto erstellt | Nach der Genehmigung markiert diese Aktivität die technische Erstellung des Kundenkontos im Kernbankensystem oder Benutzerverwaltungssystem. Häufig wird sie von ACTICO als explizites Event protokolliert, sobald das nachgelagerte System eine erfolgreiche Bestätigung zurückgibt. | ||
| Warum das wichtig ist Diese Aktivität bestätigt, dass der Prozess zu einem konkreten Geschäftsergebnis geführt hat. Die Zeit zwischen „Application Approved“ und „Account Created“ kann Integrationsverzögerungen oder Ineffizienzen bei den abschließenden Bereitstellungsschritten sichtbar machen. Bezugsquelle Diese Informationen finden sich wahrscheinlich in Integrations- oder Systemschnittstellenprotokollen innerhalb von ACTICO. Dort wird das Ergebnis von Aufrufen externer Systeme zur Kontobereitstellung dokumentiert. Erfassen Event, das beim Eingang einer erfolgreichen API-Antwort vom zentralen Kontosystem protokolliert wird. Ereignistyp explicit | |||
| Zusätzliche Informationen angefordert | Diese Aktivität bezeichnet ein Event, bei dem ein Prüfer, häufig aus Compliance oder Underwriting, zusätzliche Informationen oder Dokumente vom Kunden anfordert. Die Aktion wird normalerweise explizit erfasst, da sie häufig eine Mitteilung an den Kunden auslöst und den Case pausiert. | ||
| Warum das wichtig ist Diese Aktivität ist ein wesentlicher Treiber für Nacharbeit und längere Durchlaufzeiten. Ihre Häufigkeit und Auswirkungen zu verfolgen, ist entscheidend, um Verbesserungsmöglichkeiten bei der ersten Datenerfassung zu erkennen. Bezugsquelle Wahrscheinlich handelt es sich um ein explizites Event im Case-Verlauf oder Mitteilungsprotokoll. Suchen Sie nach Events wie „RFI Sent“ (Request for Information) oder einer spezifischen Statusänderung wie „Pending Customer Information“. Erfassen Ein explizites, von einem Benutzer ausgelöstes Event wie „Send RFI“ wird im Case-Audit-Trail protokolliert. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Administrativen Zugriff erhalten: Melden Sie sich mit ausreichend berechtigten Zugangsdaten an der ACTICO-Plattform an, beispielsweise am Visual Modeler oder an einer dedizierten Administrationskonsole. Sie benötigen Zugriff auf die Konfiguration und den Export von Daten.
- Exportmodul finden: Ö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. Vergeben Sie einen aussagekräftigen Namen, beispielsweise „KYC_Onboarding_ProcessMind_Export“.
- Datenquelle definieren: Legen Sie das primäre zu exportierende Business Object fest, in diesem Fall
CustomerApplication. Begrenzen Sie den Export unbedingt mit einem Datumsfilter, beispielsweise auf die letzten sechs Monate, damit Dateigröße und Systemleistung kontrollierbar bleiben. - Ausgabedatei konfigurieren: Wählen Sie CSV als Ausgabeformat. Legen Sie den Dateinamen fest, beispielsweise
kyc_event_log.csv, und bestätigen Sie das Trennzeichen, üblicherweise ein Komma. Stellen Sie sicher, dass Textfelder korrekt in Anführungszeichen gesetzt werden, damit Sonderzeichen verarbeitet werden können. - Case-Identifier zuordnen: Legen Sie den eindeutigen Identifier des Business Objects
CustomerApplicationals Case-ID für die Process-Mining-Analyse fest. Dadurch werden alle zugehörigen Ereignisse einem Onboarding-Case zugeordnet. - Attributzuordnungen definieren: Ordnen Sie jede erforderliche Spalte im Event Log dem entsprechenden Attribut im ACTICO-Business-Object-Modell zu. Dazu gehören Case-ID, Aktivitätsname, Zeitstempel und weitere empfohlene Attribute wie Status oder Risikostufe.
- Ereigniszuordnungen 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 „Application Submitted“, Statusänderungen für Workflow-Schritte wie „Application Approved“ und bestimmte Muster in Audit-Log-Nachrichten für technische Ereignisse wie „Identity Verification Performed“.
- Konfiguration speichern und validieren: Speichern Sie die Konfigurationsdatei, nachdem Sie alle Zuordnungen definiert haben. Verwenden Sie die in ACTICO verfügbaren Validierungswerkzeuge, um Syntaxfehler oder falsche Attributpfade zu prüfen.
- Export ausführen und überwachen: Starten Sie den Exportauftrag. Überwachen Sie den Fortschritt über den Job-Scheduler oder die Monitoring-Oberfläche des Systems. Prüfen Sie nach Abschluss die Protokolle auf Fehler.
- Datei abrufen und vorbereiten: Laden Sie die resultierende 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 Zeitstempel- und Datumsformate einheitlich und korrekt interpretiert 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 die für Process Mining erforderlichen Statusänderungen und Regelausführungen nicht.
- Datenquelle des Exports: Als primäre Datenquelle sollte das Business Object
CustomerApplicationkonfiguriert werden. Möglicherweise müssen Sie verwandte Objekte wieCustomerDocumentverknüpfen oder referenzieren, um alle relevanten Ereignisse zu erfassen. - Datumsfilter: Verwenden Sie immer einen Datumsfilter, um die Menge der extrahierten Daten zu begrenzen. Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten. Im Produktivbetrieb kann dieser Zeitraum abhängig von Geschäftsanforderungen und Systemleistung angepasst werden.
- Logik der Ereigniszuordnung: Die Genauigkeit der Extraktion hängt wesentlich davon ab, wie Ereignisse zugeordnet werden. Statusänderungen (
on="StatusChange") eignen sich häufig zur Ableitung von Geschäftsschritten. Explizite Protokolleinträge (on="LogEntry") sind für technische Ereignisse oder Serviceaufrufe hilfreich. Regelausführungen (on="RuleExecution") eignen sich besonders für Entscheidungsschritte. - Ausgabeformat: Wählen Sie CSV, um eine breite Kompatibilität sicherzustellen. Konfigurieren Sie Trennzeichen und Anführungszeichen für Textfelder korrekt, damit keine Probleme bei der Dateninterpretation entstehen.
- Voraussetzungen: Für diese Methode benötigen Sie administrative Berechtigungen für die ACTICO-Plattform. Für eine korrekte Konfiguration ist außerdem ein umfassendes Verständnis des KYC-Business-Object-Modells einschließlich aller relevanten Statusfelder und Attributnamen erforderlich.
a 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> Möchten Sie jetzt starten?
Verwenden Sie dieses Template, um Ihre Daten effizient vorzubereiten und die Optimierung Ihres KYC-Kunden-Onboardings in ACTICO zu beschleunigen.
Optimieren Sie Ihr KYC-Kunden-Onboarding: Verkürzen Sie die Bearbeitungszeit jetzt auf 24 Stunden
Vermeiden Sie Abbrüche und Fehlalarme für ein reibungsloses Onboarding.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.