Il template dei dati per l’onboarding KYC dei clienti

LexisNexis Risk Solutions
Il template dei dati per l’onboarding KYC dei clienti

Il template dei dati per l’onboarding KYC dei clienti

Questo template offre indicazioni complete sulla raccolta dei dati necessari per analizzare il processo di onboarding KYC dei clienti. Descrive gli attributi essenziali da raccogliere e le attività principali da monitorare, oltre a spiegare come estrarre queste informazioni dai sistemi di origine. Utilizzi queste indicazioni per creare un Event Log completo, da cui ricavare informazioni approfondite sul percorso di onboarding.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Indicazioni per l’estrazione
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi dell’onboarding KYC dei clienti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo l’onboarding KYC dei clienti e individuare il processo.
3 Obbligatorio 6 Consigliato 11 Facoltativo
Nome Descrizione
Domanda del cliente
CustomerApplication
Identificativo univoco di ogni domanda di onboarding del cliente, utilizzato come ID principale del caso.
Descrizione

La domanda del cliente è l’identificativo centrale che collega tutte le attività e i dati relativi al percorso di onboarding di un singolo cliente. Il processo inizia con l’invio della domanda e segue il caso fino al completamento o al rifiuto.

Nel Process Mining, questo attributo è essenziale per raggruppare tutti gli eventi in un unico caso e analizzare l’intero ciclo di onboarding. Consente di ricostruire il flusso completo del processo per ogni richiedente, operazione fondamentale per calcolare i tempi di ciclo, analizzare le varianti del processo e monitorare nel tempo lo stato della domanda.

Perché è importante

È l’ID del caso fondamentale. Senza questo identificativo non è possibile ricostruire l’intero percorso di una domanda del cliente, rendendo impossibile l’analisi del processo.

Dove reperirli

È l’identificativo principale del caso nel modulo di gestione dei casi di LexisNexis Risk Solutions.

Esempi
APP-2023-001234APP-2023-005678APP-2024-009101
Marca temporale dell’evento
EventTimestamp
Data e ora esatte di inizio di una specifica attività.
Descrizione

Questa marca temporale indica l’inizio di un’attività e stabilisce l’ordine cronologico di tutti gli eventi di un caso. È la base di ogni analisi temporale nel Process Mining.

La marca temporale dell’evento consente di calcolare la durata delle attività, i tempi di attesa tra una fase e l’altra e il tempo di ciclo end-to-end dell’intero processo di onboarding. Questi dati sono essenziali per individuare i colli di bottiglia, monitorare il rispetto degli SLA e comprendere l’efficienza del processo.

Perché è importante

Questa marca temporale è essenziale per ordinare gli eventi cronologicamente e calcolare tutte le metriche temporali, come i tempi di ciclo e i colli di bottiglia.

Dove reperirli

Si trova nelle tabelle dell’event log o della traccia di audit, insieme al nome dell’attività.

Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
Nome dell’attività
ActivityName
Nome dell’attività o dell’evento specifico che si è verificato in un determinato momento durante il processo di onboarding.
Descrizione

Il nome dell’attività descrive una fase del flusso di lavoro KYC, ad esempio “Domanda inviata”, “Revisione dei documenti eseguita” o “Domanda approvata”. Ogni attività rappresenta un’azione o una tappa distinta del processo.

Questo attributo è fondamentale per creare la mappa del processo, che ne rappresenta visivamente il flusso delle attività. Consente di analizzare le varianti del processo, i colli di bottiglia tra fasi specifiche e la frequenza dei cicli di rilavorazione. Analizzare le attività è essenziale per capire cosa accade nel processo.

Perché è importante

Questo attributo è alla base della mappa del processo e consente di visualizzare e analizzare la sequenza degli eventi nel percorso di onboarding del cliente.

Dove reperirli

In genere si trova in un Event Log o in una tabella della traccia di audit di LexisNexis Risk Solutions che registra le fasi del processo.

Esempi
Domanda inviataControllo preliminare eseguitoDocumenti richiestiRevisione di conformità completata
Data obiettivo SLA
SlaTargetDate
La data entro cui si prevede di completare il processo di onboarding del cliente.
Descrizione

La data obiettivo SLA definisce il termine previsto dall’accordo sul livello di servizio per il completamento di una richiesta. Spesso viene stabilita in base a fattori quali il tipo di richiesta, il segmento di clientela o la giurisdizione.

Questo attributo è essenziale per la Dashboard «Monitoraggio del rispetto degli obiettivi SLA» e per il KPI «Tasso di rispetto degli SLA». Confrontando la data effettiva di completamento con la data obiettivo SLA, le organizzazioni possono misurare i risultati rispetto agli impegni, individuare i casi a rischio di violazione degli SLA e analizzare le cause profonde dei ritardi.

Perché è importante

Consente di misurare i risultati rispetto agli accordi sul livello di servizio e mette in evidenza le inefficienze del processo che causano violazioni degli SLA.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. Il dato può essere memorizzato nel caso oppure calcolato in base alle regole aziendali.

Esempi
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
Livello di rischio
RiskLevel
Il livello di rischio calcolato per la richiesta del cliente, ad esempio basso, medio o alto.
Descrizione

LexisNexis Risk Solutions è specializzata nella valutazione del rischio. Questo attributo rappresenta il risultato di tale valutazione e classifica ogni richiesta in base al profilo di rischio potenziale. Il livello di rischio determina spesso l’intensità e la durata delle verifiche di due diligence necessarie.

Questo attributo è la dimensione principale della Dashboard «Livello di rischio e durata dell’onboarding». Analizzare il processo in base al livello di rischio permette di verificare se, come previsto, le richieste ad alto rischio richiedono molto più tempo o se quelle a basso rischio subiscono ritardi non necessari. Aiuta inoltre a convalidare e perfezionare le strategie di onboarding basate sul rischio.

Perché è importante

È fondamentale per le analisi basate sul rischio e aiuta a comprendere come il profilo di rischio dei clienti influisca sulla complessità, sulla durata e sui percorsi del processo.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. È uno dei principali risultati dei moduli di valutazione del rischio.

Esempi
BassoMedioAltoSoggetto a sanzioni
Ora di fine
EndTime
La data e l’ora esatte in cui è stata completata un’attività.
Descrizione

Questo timestamp indica il completamento di un’attività. La differenza tra l’ora di fine e l’ora di inizio di un evento corrisponde al suo tempo di elaborazione.

L’ora di fine è essenziale per calcolare con precisione la durata di ogni passaggio ed è uno dei principali dati utilizzati nella Dashboard «Tempi di elaborazione e attesa delle attività». Consente di distinguere il tempo in cui una risorsa ha lavorato attivamente a un’attività da quello in cui il caso è rimasto in attesa dell’avvio del passaggio successivo.

Perché è importante

Consente di calcolare con precisione il tempo di elaborazione delle attività, un dato essenziale per individuare i passaggi inefficienti e analizzare il carico di lavoro delle risorse.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. Spesso è disponibile nei log degli eventi che registrano sia l’inizio sia la fine delle attività.

Esempi
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
Reparto
Department
Il reparto o il team aziendale a cui appartiene l’utente assegnato.
Descrizione

L’attributo Reparto specifica il gruppo funzionale responsabile di un’attività, ad esempio «Conformità», «Operazioni di onboarding» o «Prevenzione delle frodi».

Questo attributo consente di analizzare il processo dal punto di vista dei reparti e di esaminare i passaggi di consegne tra i diversi team. È una dimensione fondamentale nella Dashboard «Allocazione delle risorse e carico di lavoro» e aiuta a individuare inefficienze tra funzioni diverse o ritardi nella comunicazione tra reparti.

Perché è importante

Consente di analizzare i passaggi di consegne e le prestazioni per area funzionale, aiutando a individuare i colli di bottiglia tra reparti.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. Potrebbe essere necessario collegare questo dato a una tabella anagrafica degli utenti o delle risorse umane.

Esempi
ComplianceTeam di onboardingAnalisti KYCAssistenza clienti
Stato della richiesta
ApplicationStatus
Lo stato attuale o finale della richiesta del cliente.
Descrizione

Questo attributo indica lo stato complessivo del caso in un determinato momento o il suo esito finale. Tra gli stati più comuni figurano «In corso», «Approvato», «Rifiutato» e «In attesa di informazioni».

Lo stato della richiesta è fondamentale per monitorare gli esiti del processo di onboarding. Viene utilizzato nelle Dashboard «Motivi e fasi di rifiuto delle richieste» e «Volumi giornalieri e stato delle richieste» per monitorare i tassi di successo e l’andamento operativo. Analizzare le variazioni dello stato nel tempo permette di comprendere meglio il ciclo di vita del caso.

Perché è importante

Tiene traccia dell’esito di ogni richiesta, un dato essenziale per calcolare KPI come il tasso di rifiuto delle richieste e monitorare i volumi.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. In genere è un campo fondamentale dell’oggetto principale del caso o della richiesta.

Esempi
In corsoApprovatoRifiutatoIn attesa di informazioni dal cliente
Utente assegnato
AssignedUser
L’identificativo univoco dell’utente o dell’operatore responsabile dell’attività.
Descrizione

Questo attributo identifica la persona che ha eseguito un’attività, ad esempio un responsabile della conformità che ha esaminato un documento. Consente di analizzare la distribuzione del carico di lavoro e le prestazioni individuali.

Nell’analisi, l’utente assegnato è fondamentale per la Dashboard «Allocazione delle risorse e carico di lavoro». Permette di filtrare la mappa del processo per utente, confrontare le prestazioni dei membri del team e individuare opportunità di formazione o di riequilibrio del carico di lavoro. Può inoltre aiutare a individuare i colli di bottiglia riconducibili a specifici gruppi di utenti.

Perché è importante

Questo attributo è essenziale per analizzare le prestazioni delle risorse e la distribuzione del carico di lavoro, nonché per individuare opportunità di automazione o di ottimizzazione delle risorse.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. In genere si trova nelle tracce di audit o nelle tabelle di gestione delle attività.

Esempi
j.doem.smithk.chen
Canale
Channel
Il canale attraverso cui è stata inviata la richiesta, ad esempio «Web», «Dispositivo mobile» o «Filiale».
Descrizione

L’attributo Canale identifica la modalità di invio della richiesta. Il canale può influire sulla qualità dei dati, sul comportamento dei clienti e sui problemi che si verificano durante l’onboarding.

Questo attributo permette di confrontare i risultati del processo nei diversi canali. Ad esempio, è possibile filtrare per canale la Dashboard «Tassi di conversione del funnel di onboarding» per verificare se gli utenti che inviano la richiesta da dispositivo mobile abbandonano il processo più spesso di quelli che usano il web e definire interventi mirati sul processo per ciascun canale.

Perché è importante

Aiuta ad analizzare i risultati del processo in base al canale di invio e a individuare variazioni utili per definire la strategia di canale e migliorare l’esperienza utente.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. In genere questa informazione viene acquisita all’inizio del processo di richiesta.

Esempi
Portale webApp per dispositivi mobiliFilialeAPI
È automatizzata
IsAutomated
Un indicatore che specifica se un’attività è stata eseguita automaticamente dal sistema o manualmente da un utente.
Descrizione

Questo attributo booleano distingue le attività eseguite automaticamente dal sistema, ad esempio un controllo iniziale, da quelle che richiedono l’intervento di una persona, come la revisione manuale di un documento.

«È automatizzata» viene utilizzato per calcolare il KPI «Percentuale di attività manuali» e analizzare l’efficacia delle iniziative di automazione. Nella mappa del processo può mettere in evidenza il passaggio tra fasi automatizzate e manuali, aiutando a individuare ulteriori opportunità di automazione per ridurre i costi e i tempi di elaborazione.

Perché è importante

Distingue le attività manuali da quelle automatizzate, un dato essenziale per individuare opportunità di automazione e misurarne l’impatto.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. Potrebbe trattarsi di un indicatore nell’event log oppure il dato potrebbe essere dedotto da «AssignedUser», ad esempio quando l’utente è «system».

Esempi
truefalse
È una rilavorazione
IsRework
Un indicatore che identifica le attività che fanno parte di un ciclo di rilavorazione.
Descrizione

Questo indicatore booleano viene impostato su true quando un’attività viene ripetuta all’interno dello stesso caso, ad esempio quando «Revisione del documento eseguita» si verifica una seconda volta dopo «Richieste informazioni aggiuntive». Indica che il processo è tornato a una fase precedente.

«È una rilavorazione» è fondamentale per la Dashboard «Analisi delle rilavorazioni e delle ripetizioni» e per il KPI «Percentuale di cicli di rilavorazione». Permette di quantificare il lavoro sprecato e aiuta a individuare le cause profonde delle rilavorazioni, come istruzioni poco chiare o dati di scarsa qualità, così da definire interventi mirati sul processo.

Perché è importante

Quantifica direttamente le inefficienze e il lavoro sprecato nel processo, mettendo in evidenza le attività ripetute di frequente che aumentano i costi e i tempi di ciclo.

Dove reperirli

È un attributo calcolato, in genere ricavato dallo strumento di Process Mining rilevando le sequenze di attività ripetute all’interno di un caso.

Esempi
truefalse
Motivo del rifiuto
RejectionReason
Un codice o una descrizione che spiega perché una richiesta è stata rifiutata.
Descrizione

Quando lo stato finale di una richiesta è «Rifiutato», questo attributo ne specifica il motivo. Alcuni esempi sono «Verifica dell’identità non superata», «Corrispondenza con un elenco di sanzioni» o «Documentazione incompleta».

Questi dati sono l’input principale della Dashboard «Motivi e fasi di rifiuto delle richieste». Analizzare i motivi di rifiuto aiuta a individuare i punti del processo in cui si verificano più spesso problemi e a definire interventi mirati sulle linee guida per le richieste, sulla comunicazione con i clienti o sui criteri di revisione interni. Capire perché le richieste vengono rifiutate è fondamentale per aumentare il tasso complessivo di approvazione.

Perché è importante

Fornisce indicazioni dirette sui motivi per cui l’onboarding non va a buon fine e permette di intervenire in modo mirato per aumentare il tasso di approvazione delle richieste.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. Spesso si trova in un campo compilato quando lo stato della richiesta viene impostato su «Rifiutato».

Esempi
Corrispondenza con un elenco di sanzioniDocumentazione incompletaVerifica dell’identità non superataProfilo ad alto rischio
Paese del cliente
CustomerCountry
Il paese di residenza del cliente o quello in cui è costituita la sua società.
Descrizione

Questo attributo specifica il paese del cliente, un fattore fondamentale per le procedure KYC, poiché le normative internazionali e i livelli di rischio variano da una giurisdizione all’altra.

Analizzare il processo per paese del cliente può rivelare differenze significative nei tempi di ciclo e nella complessità del processo. Ad esempio, le richieste provenienti da giurisdizioni ad alto rischio possono richiedere controlli aggiuntivi e tempi più lunghi. Questa analisi aiuta a pianificare le risorse e a definire SLA realistici per le diverse aree geografiche.

Perché è importante

Consente di analizzare i dati per giurisdizione, un aspetto essenziale per comprendere come le normative regionali e i fattori di rischio influiscano sui risultati del processo.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. È un campo standard nei dati anagrafici dei clienti.

Esempi
USAGBRDEUSGP
Responsabile della revisione di conformità
ComplianceReviewer
L’utente o l’operatore assegnato specificamente alle attività di revisione della conformità.
Descrizione

Mentre «AssignedUser» identifica l’utente per qualsiasi attività, questo attributo individua nello specifico lo specialista della conformità coinvolto nelle fasi di revisione più importanti. Permette quindi di analizzare più da vicino la funzione di conformità.

Questo attributo è fondamentale per la Dashboard «Durata e arretrato delle revisioni di conformità». Aiuta ad analizzare il carico di lavoro e i risultati del team addetto alla conformità, mostrando se alcuni revisori costituiscono colli di bottiglia o se il team nel suo complesso dispone di risorse insufficienti.

Perché è importante

Offre una visione mirata della funzione di conformità e consente di analizzare nel dettaglio il carico di lavoro e i risultati dei revisori in questa fase critica, spesso soggetta a ritardi.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. Il dato può essere ricavato filtrando «AssignedUser» per le attività legate alla conformità.

Esempi
c.joness.patelsystem_escalation
Sistema di origine
SourceSystem
Il sistema o l’applicazione da cui provengono i dati degli eventi.
Descrizione

Questo attributo identifica il sistema di origine che ha generato i dati degli eventi, ad esempio LexisNexis Risk Solutions o uno strumento di terze parti integrato. Negli ambienti complessi, i dati relativi a un singolo processo possono provenire da più sistemi.

Conoscere il sistema di origine è utile per convalidare i dati, risolvere i problemi e analizzare le variazioni del processo che possono dipendere da un sistema specifico. Aiuta a garantire l’integrità dei dati e fornisce un contesto su come e dove è stata registrata un’attività.

Perché è importante

Identifica la provenienza dei dati, un’informazione essenziale per la governance e la convalida dei dati e per comprendere l’esecuzione del processo nei diversi sistemi IT.

Dove reperirli

Questa informazione può essere memorizzata come valore statico o in un campo specifico dell’esportazione dei dati o della risposta API.

Esempi
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
Stato SLA
SlaStatus
Indica se la richiesta completata ha rispettato l’obiettivo SLA.
Descrizione

Questo attributo classifica ogni caso completato in base al rispetto della «SlaTargetDate». I valori più comuni sono «Rispettato» e «Non rispettato».

Questo campo calcolato è alla base della Dashboard «Monitoraggio del rispetto degli obiettivi SLA» e del KPI «Tasso di rispetto degli SLA». Offre una visione chiara e sintetica dei risultati rispetto agli impegni di servizio e permette di approfondire le caratteristiche comuni dei casi in cui gli SLA non vengono rispettati.

Perché è importante

Fornisce un esito chiaro e binario sul rispetto degli SLA, semplificando il monitoraggio, la rendicontazione e l’analisi della conformità agli obiettivi di servizio.

Dove reperirli

È un attributo calcolato confrontando, per ogni caso, il timestamp dell’attività finale con la «SlaTargetDate».

Esempi
RispettatoNon rispettatoA rischio
Tempo di ciclo
CycleTime
La durata complessiva della richiesta del cliente, dall’invio alla decisione finale.
Descrizione

Il tempo di ciclo misura il tempo totale trascorso dal primo evento, ad esempio «Richiesta inviata», all’ultimo, ad esempio «Onboarding del cliente completato» o «Richiesta rifiutata», per un singolo caso.

È un KPI fondamentale per misurare la salute complessiva del processo e viene visualizzato nella Dashboard «Tempo di ciclo end-to-end dell’onboarding». Monitorare il tempo di ciclo medio permette alle organizzazioni di valutare l’impatto dei miglioramenti apportati al processo e di capire come fattori quali il livello di rischio o il tipo di richiesta influiscano sull’esperienza complessiva del cliente.

Perché è importante

È un indicatore chiave che misura il tempo complessivo necessario affinché il cliente ottenga il risultato atteso, con un impatto diretto sulla sua soddisfazione e sull’efficienza operativa.

Dove reperirli

È una metrica calcolata sottraendo, per ogni caso, il timestamp del primo evento da quello dell’ultimo.

Esempi
5 giorni e 4 ore22 giorni e 8 ore1 giorno e 2 ore
Tipo di richiesta
ApplicationType
Il tipo di richiesta del cliente, ad esempio «Persona fisica» o «Azienda».
Descrizione

Questo attributo classifica le richieste in base al tipo di soggetto da sottoporre a onboarding. Tipi di richiesta diversi seguono spesso percorsi distinti e presentano profili di rischio e obiettivi SLA differenti.

Analizzare il processo per tipo di richiesta permette di segmentare i dati e confrontare l’efficienza e la complessità dell’onboarding per le diverse categorie di clienti. È un filtro comune nella maggior parte delle Dashboard e offre una visione più dettagliata dei risultati.

Perché è importante

Consente di segmentare il processo in modo efficace, mostrando come vengono gestiti i diversi tipi di richiesta e dove si trovano i colli di bottiglia specifici per ciascuno.

Dove reperirli

Consulti la documentazione di LexisNexis Risk Solutions o l’amministratore di sistema. In genere è un campo fondamentale dell’oggetto della richiesta o del caso.

Esempi
Persona fisicaAziendaPersona fisica con patrimonio elevatoTrust
Ultimo aggiornamento dei dati
LastDataUpdate
Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione

Questo attributo indica la data e l’ora dell’ultimo aggiornamento del set di dati. In genere viene applicato all’intero set durante il processo di estrazione e caricamento dei dati.

Questa informazione è fondamentale perché chi consulta le Dashboard possa valutare quanto siano aggiornati i dati analizzati. Consente di basare le decisioni su dati aggiornati quanto necessario e di avere aspettative realistiche sulla tempestività delle analisi.

Perché è importante

Fornisce un contesto essenziale sull’aggiornamento dei dati, affinché le analisi siano pertinenti e le decisioni non si basino su informazioni obsolete.

Dove reperirli

Di solito viene generato e associato al set di dati durante il processo ETL (Extract, Transform, Load).

Esempi
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
Obbligatorio Consigliato Facoltativo

Attività dell’onboarding KYC dei clienti

Questi sono i passaggi e le tappe principali da registrare nell’Event Log per individuare il processo con precisione e analizzarne le prestazioni.
8 Consigliato 6 Facoltativo
Attività Descrizione
Documenti ricevuti
Conferma che il cliente ha caricato o fornito al sistema i documenti richiesti. In genere, si tratta di un evento esplicito generato dal portale di invio dei documenti o inserito manualmente da un operatore.
Perché è importante

Questa attività conclude un periodo di attesa e avvia le successive attività di revisione. È una tappa fondamentale nella fase di raccolta dei dati.

Dove reperirli

Rilevato nei log del sistema di gestione dei documenti o in una voce con marca temporale nel fascicolo della domanda, quando vengono allegati nuovi documenti.

Acquisizione

L’evento viene registrato quando un documento è caricato correttamente o contrassegnato manualmente come ricevuto nel sistema.

Tipo di evento explicit
Domanda approvata
La decisione finale di approvare la domanda del cliente viene presa e registrata nel sistema. È un esito aziendale fondamentale e viene quasi sempre rilevato tramite una modifica esplicita dello stato.
Perché è importante

Questa tappa segna la conclusione positiva del processo decisionale. Analizzare i percorsi che portano all’approvazione aiuta a individuare le pratiche più efficaci.

Dove reperirli

Cerchi nel record del caso un aggiornamento finale dello stato della domanda, impostato su “Approvato” o su uno stato terminale equivalente.

Acquisizione

Registrato come modifica definitiva dello stato nella tabella principale delle domande o dei casi.

Tipo di evento explicit
Domanda inviata
Segna l’inizio del processo di onboarding KYC, quando il sistema riceve per la prima volta la domanda di un cliente. In genere, l’evento viene registrato esplicitamente quando il modulo è inviato tramite un portale clienti o un sistema interno di inserimento dei dati integrato con LexisNexis.
Perché è importante

È l’evento iniziale principale del processo. Analizzare il tempo che intercorre tra questa attività e il completamento è fondamentale per misurare il tempo di ciclo end-to-end e il rispetto degli SLA.

Dove reperirli

Rilevato nei log di sistema o in una tabella delle domande che registra la marca temporale di creazione iniziale di una nuova domanda di un cliente.

Acquisizione

L’evento viene registrato quando si crea un nuovo caso relativo a una domanda o una nuova voce nella tabella principale delle domande.

Tipo di evento explicit
Domanda rifiutata
La decisione finale di rifiutare la domanda del cliente viene registrata. Si tratta di un evento terminale, rilevato tramite una modifica definitiva dello stato nel sistema.
Perché è importante

È l’evento finale che indica l’esito negativo del processo. Per migliorarlo è fondamentale analizzare le fasi in cui avvengono i rifiuti e i relativi motivi.

Dove reperirli

Rilevato quando il campo dello stato finale del record della domanda viene impostato su “Rifiutato”, “Non accolto” o uno stato terminale equivalente.

Acquisizione

Registrato come modifica definitiva dello stato nella tabella principale delle domande o dei casi.

Tipo di evento explicit
Onboarding del cliente completato
Questo evento segna la conclusione positiva dell’intero processo di onboarding e conferma che il cliente è pienamente attivo. Può essere uno stato finale esplicito oppure essere dedotto dall’evento “Conto attivato”.
Perché è importante

È l’evento finale che indica il completamento positivo del processo. È essenziale per calcolare il tempo di ciclo end-to-end di tutti i clienti che hanno completato l’onboarding.

Dove reperirli

Dedotto dalla marca temporale di “Conto attivato” oppure rilevato da uno stato finale, come “Onboarding completato”, nel fascicolo del caso.

Acquisizione

Dedotto dall’ultimo evento positivo significativo, ad esempio l’attivazione del conto, o da un aggiornamento dello stato finale.

Tipo di evento inferred
Revisione di conformità avviata
Un caso viene assegnato a un responsabile o a un team della conformità per una revisione manuale, di solito quando la domanda presenta un rischio elevato. L’avvio si deduce spesso da una modifica dello stato a “Revisione di conformità in attesa” o da un log di assegnazione dell’attività.
Perché è importante

Segna l’inizio di una fase di revisione manuale, spesso lunga. Misurare il tempo che intercorre fino al completamento aiuta a quantificare i colli di bottiglia legati alla conformità.

Dove reperirli

Rilevato in un log di assegnazione dell’attività, in una modifica del responsabile del caso a un team della conformità o in un aggiornamento dello stato nella cronologia del caso.

Acquisizione

Dedotto da una modifica dello stato, ad esempio “In revisione di conformità”, o dall’assegnazione del caso a una coda utenti dedicata alla conformità.

Tipo di evento inferred
Revisione di conformità completata
Il responsabile della conformità completa la revisione e formula una raccomandazione, facendo passare il caso alla fase successiva. L’attività può essere registrata esplicitamente quando un’attività viene contrassegnata come “completata” oppure dedotta dal passaggio dallo stato “Conformità in attesa” a un altro stato.
Perché è importante

È una tappa fondamentale che conclude una fase critica, spesso manuale, del processo. Segna la fine del periodo da misurare per calcolare la durata della revisione di conformità.

Dove reperirli

Rilevato dalla marca temporale di completamento di un’attività di conformità o da una modifica dello stato che indica l’uscita da “In revisione di conformità”.

Acquisizione

Dedotto da una modifica dello stato che indica la conclusione della revisione, ad esempio il passaggio a “Approvato”, “Rifiutato” o “Decisione finale”.

Tipo di evento inferred
Valutazione del rischio eseguita
Sulla base delle informazioni raccolte e dei controlli effettuati, il sistema calcola un punteggio di rischio per il cliente. È una funzione centrale di LexisNexis e viene in genere registrata come evento automatico esplicito nella cronologia del caso.
Perché è importante

L’esito della valutazione determina spesso il percorso successivo, ad esempio la necessità di una due diligence rafforzata. È un punto decisionale fondamentale nel flusso di lavoro.

Dove reperirli

Cerchi nel registro di audit o nella cronologia del flusso di lavoro della domanda un evento che registri il completamento del calcolo del punteggio di rischio o del modulo di valutazione.

Acquisizione

Quando il motore di valutazione del rischio completa l’analisi e assegna un profilo o un punteggio di rischio, viene registrato un evento specifico.

Tipo di evento explicit
Conto attivato
Dopo l’approvazione, il conto del cliente viene creato e attivato ufficialmente nella piattaforma bancaria o dei servizi. L’attività viene spesso registrata in una traccia di audit oppure dedotta dalla data di creazione del conto.
Perché è importante

È la fase finale in cui viene fornito valore al cliente. Eventuali ritardi tra “Domanda approvata” e questa fase possono indicare problemi di integrazione tra sistemi.

Dove reperirli

Rilevato in un log di creazione del conto, in una chiamata API a un altro sistema o nella marca temporale di creazione del record del conto.

Acquisizione

Registrato come evento separato dopo l’approvazione oppure individuato dalla presenza della marca temporale di attivazione nel record del cliente.

Tipo di evento explicit
Controllo preliminare eseguito
Subito dopo l’invio, il sistema esegue un controllo automatico per verificare che i dati di base siano completi e svolgere le verifiche preliminari. Questa attività viene spesso registrata come passaggio automatico esplicito nella cronologia del flusso di lavoro.
Perché è importante

Permette di individuare le domande che non superano la prima fase e di comprendere i problemi di qualità dei dati. Segna inoltre il primo passaggio automatico che aggiunge valore al processo.

Dove reperirli

Cerchi nei log l’esecuzione automatica delle regole oppure una modifica dello stato nella cronologia del flusso di lavoro che indichi il completamento del controllo preliminare.

Acquisizione

Registrato come attività automatica completata o come aggiornamento specifico dello stato nella cronologia del caso.

Tipo di evento explicit
Documenti richiesti
Il sistema o un utente richiede al cliente documenti specifici, come la patente di guida o una bolletta. L’evento può essere rilevato nei log delle comunicazioni generate dal sistema o da una modifica dello stato che indica che il caso è in attesa dei documenti.
Perché è importante

Questa attività spesso introduce tempi di attesa significativi nel processo. Analizzarne la frequenza e la durata aiuta a individuare i ritardi dovuti ai tempi di risposta dei clienti.

Dove reperirli

Cerchi nei log delle comunicazioni inviate al cliente un evento oppure una modifica dello stato della domanda, ad esempio “Documenti del cliente in attesa”.

Acquisizione

Dedotto da una modifica dello stato a “In attesa dei documenti” o dalla marca temporale di un log delle comunicazioni in uscita.

Tipo di evento inferred
Informazioni aggiuntive richieste
Un responsabile della conformità o un revisore chiede al cliente altre informazioni o chiarimenti. Questa attività genera spesso rilavorazioni e viene in genere registrata con una modifica esplicita dello stato o una voce nel log delle comunicazioni.
Perché è importante

Questa attività crea cicli di rilavorazione che allungano il tempo di ciclo dell’onboarding. Monitorarne la frequenza aiuta a individuare requisiti poco chiari o carenze ricorrenti nelle domande.

Dove reperirli

Cerchi una modifica dello stato a “Informazioni del cliente in attesa” o un evento nell’Event Log delle comunicazioni in uscita. Spesso si tratta di un’azione avviata da un utente.

Acquisizione

L’evento viene registrato quando un operatore utilizza la funzione “Richiedi informazioni”, che modifica lo stato del caso e può registrare una comunicazione.

Tipo di evento explicit
Revisione dei documenti eseguita
Un utente o uno strumento automatico verifica l’autenticità, la validità e la completezza dei documenti inviati. L’attività può essere dedotta da una modifica dello stato da “Documenti ricevuti” a “Revisione completata” oppure da una voce esplicita nel log.
Perché è importante

Questa fase è una causa frequente di colli di bottiglia e rilavorazioni. Analizzarne il tempo di elaborazione e le ripetizioni è fondamentale per migliorare l’efficienza e individuare opportunità di automazione.

Dove reperirli

Dedotto monitorando il tempo tra lo stato “Documenti ricevuti” e uno stato successivo, come “Verifica superata” o “Informazioni aggiuntive richieste”.

Acquisizione

Calcolato come il tempo tra la ricezione dei documenti e l’evento che ne indica il completamento della revisione.

Tipo di evento inferred
Verifica dell’identità avviata
Indica il momento in cui il sistema avvia la verifica dell’identità, una fase centrale del processo, utilizzando servizi LexisNexis, ad esempio per effettuare controlli incrociati con le banche dati. Di solito viene registrato un evento esplicito nell’Event Log quando viene richiamato il servizio di verifica.
Perché è importante

Questa attività segna l’inizio di un sottoprocesso critico e spesso lungo. Monitorarne la durata aiuta a isolare i colli di bottiglia legati ai controlli dell’identità.

Dove reperirli

Rilevato nei log delle chiamate API al modulo di verifica dell’identità o in una voce della traccia di audit che indica l’avvio dell’attività di verifica.

Acquisizione

L’evento viene registrato quando il modulo di verifica dell’identità o l’API del sistema viene attivato per la domanda.

Tipo di evento explicit
Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da LexisNexis Risk Solutions

È pronto a iniziare?

Utilizzi questo template per avviare il percorso di Process Mining nell’onboarding KYC dei clienti. Inizi oggi a trasformare i dati in informazioni utili per agire.

Ottimizzi l’onboarding KYC e riduca subito gli abbandoni

Offra un onboarding senza intoppi e riduca i tempi a sole 24 ore.

Inizi la prova gratuita

Non è richiesta la carta di credito. Inizi oggi a ottimizzare il processo.