Il template dei dati per l’onboarding KYC dei clienti
Il template dei dati per l’onboarding KYC dei clienti
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati da ACTICO
Attributi per l’onboarding KYC dei clienti
| Nome | Descrizione | ||
|---|---|---|---|
| Nome dell’attività ActivityName | Nome dello specifico evento aziendale o dell’attività svolta nell’ambito del processo di onboarding del cliente. | ||
| Descrizione Questo attributo registra il nome di ogni fase o attività del processo KYC, ad esempio «Pratica inviata», «Valutazione del rischio eseguita» o «Pratica approvata». Costituisce uno degli elementi che compongono la mappa del processo. Analizzare il nome dell’attività consente di visualizzare il flusso del processo, individuare le attività frequenti o rare e rilevare colli di bottiglia o cicli di rilavorazione. È un elemento fondamentale per capire quali azioni vengono svolte e in quale ordine, aspetto essenziale per analizzare le varianti e verificare la conformità. Perché è importante Definisce le fasi della mappa del processo e consente di visualizzare il flusso, individuare gli scostamenti e analizzare la frequenza e la sequenza delle attività. Dove reperirli Queste informazioni si trovano in genere in una tabella dei log degli eventi di ACTICO, spesso in un campo che descrive il tipo di evento o attività. Consulti la documentazione ACTICO. Esempi Pratica inviataValutazione del rischio eseguitaRevisione di conformità completataPratica rifiutata | |||
| Ora dell’evento EventTime | La marca temporale che indica quando una specifica attività è iniziata o si è verificata. | ||
| Descrizione L’ora dell’evento è la data e l’ora esatte in cui un’attività è stata registrata nel sistema. Definisce l’ordine cronologico di tutti gli eventi associati a una singola pratica del cliente e traccia il percorso di onboarding nel tempo. Questo attributo è fondamentale per tutte le analisi basate sul tempo. Serve a calcolare i tempi di ciclo tra le attività, individuare ritardi e tempi di attesa, misurare la durata complessiva dei casi e verificare il rispetto degli accordi sul livello di servizio (SLA). La sequenza delle marche temporali di un caso consente agli strumenti di Process Mining di ricostruire il flusso effettivo del processo. Perché è importante Questo attributo definisce l’ordine cronologico degli eventi, indispensabile per calcolare le durate, individuare i colli di bottiglia e analizzare l’andamento temporale del processo. Dove reperirli Si trova nelle tabelle dei log degli eventi di ACTICO ed è la marca temporale associata a ogni attività registrata. Consulti la documentazione ACTICO. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Pratica del cliente CustomerApplication | Identificativo univoco di una singola pratica di onboarding del cliente, utilizzato come ID del caso per l’analisi del processo. | ||
| Descrizione La pratica del cliente è l’identificativo principale del caso, che raggruppa tutti gli eventi e le attività relativi al percorso di onboarding di un singolo cliente. Rappresenta un’istanza completa del processo KYC, dall’invio iniziale alla decisione finale di approvazione o rifiuto. Nel Process Mining, questo attributo è essenziale per ricostruire il percorso completo di ogni pratica. Consente agli analisti di seguire la sequenza delle attività, misurare i tempi di ciclo complessivi e confrontare i diversi percorsi, o varianti, seguiti dalle varie pratiche. Tutti gli eventi associati allo stesso ID della pratica del cliente sono considerati parte dello stesso caso. Perché è importante È l’attributo fondamentale per il Process Mining, perché collega tutti gli eventi correlati in un’unica istanza di processo coerente e consente di analizzare dall’inizio alla fine l’esperienza di onboarding di ogni cliente. Dove reperirli È una chiave primaria nelle tabelle principali delle pratiche o della gestione dei casi in ACTICO. Consulti la documentazione ACTICO per conoscere i nomi specifici delle tabelle e dei campi. Esempi APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Sistema di origine SourceSystem | Il sistema di registrazione da cui provengono i dati degli eventi. | ||
| Descrizione Questo attributo identifica il sistema informativo di origine in cui sono stati generati i dati. Per questo processo il valore sarà sempre «ACTICO», mentre nelle analisi più ampie che coinvolgono più sistemi consente di distinguere la provenienza dei dati. Nel Process Mining è fondamentale per la governance e la convalida dei dati: assicura che i dati siano attribuiti correttamente alla fonte e risulta quindi importante quando si uniscono dati provenienti da sistemi diversi per ottenere una visione complessiva del processo. Inoltre, aiuta a risalire al sistema di origine quando si verificano problemi di qualità dei dati. Perché è importante Fornisce un contesto essenziale sulla provenienza dei dati e ne garantisce la tracciabilità e la governance, aspetti fondamentali quando si combinano dati provenienti da più fonti. Dove reperirli In genere è un valore statico («ACTICO»), aggiunto durante l’estrazione e la trasformazione dei dati per identificare il set di dati. Esempi ACTICOPiattaforma ACTICOModulo KYC di Actico | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine. | ||
| Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione dei dati da ACTICO. È un campo di metadati riferito all’intero set di dati, non ai singoli eventi, e fornisce un’indicazione sull’aggiornamento dei dati utilizzati nell’analisi. Nelle Dashboard e nei report, questa informazione è essenziale per capire quanto siano aggiornati i dati. Aiuta a valutare la tempestività delle informazioni e risulta fondamentale per il monitoraggio operativo, quando è importante disporre di dati quasi in tempo reale. Mostrare la data e l’ora dell’aggiornamento rende i dati presentati più trasparenti e affidabili. Perché è importante Indica quanto sono aggiornati i dati e permette di capire se l’analisi si basa su informazioni recenti, un aspetto fondamentale per le decisioni operative. Dove reperirli Questo valore viene generato e memorizzato durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Corrisponde alla data e all’ora in cui il processo ETL è stato completato correttamente. Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Data obiettivo SLA SlaTargetDate | Data entro cui si prevede di completare il processo di onboarding del cliente. | ||
| Descrizione La data obiettivo SLA è il termine entro cui completare l’onboarding di un cliente, secondo quanto stabilito dagli accordi interni sui livelli di servizio. Spesso viene calcolata a partire dalla data di invio della richiesta, aggiungendo il tempo di elaborazione standard. Questo attributo è essenziale per monitorare il rispetto degli SLA. Confrontando la data effettiva di completamento di un caso con la relativa data obiettivo SLA, il sistema può determinare se il caso è stato completato in tempo o se lo SLA è stato superato. È la base della Dashboard «Prestazioni SLA dell’onboarding» e del KPI «Tasso di rispetto degli SLA dell’onboarding». Perché è importante Fornisce il valore di riferimento per misurare il rispetto delle scadenze e consente di monitorare e rendicontare direttamente il rispetto degli SLA. Dove reperirli Può essere registrata in un campo della tabella principale dei casi in ACTICO oppure ricavata applicando regole aziendali, ad esempio: data di invio + 5 giorni lavorativi. Esempi 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Livello di rischio RiskLevel | Livello di rischio calcolato per la richiesta del cliente, ad esempio basso, medio o alto. | ||
| Descrizione Questo attributo rappresenta la categoria di rischio assegnata al cliente, che spesso determina la complessità e il rigore delle fasi successive del processo KYC. Un cliente ad alto rischio può richiedere controlli e approvazioni aggiuntivi rispetto a un cliente a basso rischio. Nel Process Mining, il livello di rischio è una dimensione utile per le analisi comparative. Consente agli analisti di verificare che il processo segua correttamente percorsi diversi in base al rischio, come previsto. Per esempio, è possibile controllare che tutti i clienti ad alto rischio siano sottoposti a una verifica rafforzata. È un elemento fondamentale della Dashboard «Flussi del processo di valutazione del rischio». Perché è importante Consente di suddividere i casi in base al rischio e di verificare se il processo si adatta correttamente ai diversi profili di rischio, come previsto dalle politiche di conformità. Dove reperirli È un dato fondamentale, registrato a livello di caso nella tabella principale delle richieste di ACTICO. Esempi BassoMedioAlto | |||
| Motivo del rifiuto RejectionReason | Motivo specifico indicato per il rifiuto di una richiesta del cliente. | ||
| Descrizione Quando lo stato finale di una richiesta è «Respinto», questo attributo ne indica la causa. Alcuni esempi sono «Documentazione incompleta», «Verifica dei precedenti non superata» o «Profilo ad alto rischio». È un attributo essenziale per l’analisi delle cause profonde. Analizzando la frequenza dei diversi motivi di rifiuto, l’azienda può individuare problemi sistemici nel processo o nelle richieste dei clienti. Per esempio, un numero elevato di rifiuti dovuti a documentazione incompleta potrebbe indicare che le istruzioni per presentare la richiesta non sono chiare. Questo attributo alimenta direttamente la Dashboard «Tasso e motivi di rifiuto delle richieste». Perché è importante Spiega perché le richieste vengono respinte e consente di analizzare le cause profonde, ridurre il tasso di rifiuto e migliorare l’efficienza del processo. Dove reperirli Di solito si trova nella tabella principale dei casi o delle richieste in ACTICO e viene compilato solo quando lo stato della richiesta è «Respinto». Esempi Documentazione incompletaVerifica dell’identità non superataCorrispondenza con un elenco di sanzioniPunteggio di rischio elevato | |||
| Ora di fine EndTime | Data e ora di completamento di una specifica attività. | ||
| Descrizione L’ora di fine indica quando si conclude un’attività. Insieme all’ora di inizio (EventTime), consente di calcolare la durata esatta di ogni task, detta tempo di elaborazione. Non tutti gli eventi hanno un’ora di fine distinta, perché alcuni possono essere istantanei. Questo attributo è fondamentale per l’analisi delle prestazioni, in particolare per misurare la durata di ogni passaggio. Consente di creare Dashboard dettagliate sulle prestazioni, aiuta a individuare le attività che richiedono più tempo ed è indispensabile per calcolare KPI come «Tempo medio di revisione dei documenti». Perché è importante Consente di calcolare con precisione la durata delle attività (tempo di elaborazione), un dato fondamentale per individuare i colli di bottiglia e analizzare l’efficienza nell’impiego delle risorse. Dove reperirli Come l’ora di inizio, in genere si trova nelle tabelle del log degli eventi di ACTICO. Alcuni sistemi registrano l’ora di inizio e quella di fine in colonne separate dello stesso record di evento. Consultare la documentazione di ACTICO. Esempi 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Reparto Department | Il reparto o il team responsabile dello svolgimento dell’attività. | ||
| Descrizione Questo attributo assegna un’attività a una specifica unità organizzativa, ad esempio «Conformità», «Team di onboarding» o «Relazioni con i clienti». In questo modo, aggiunge al flusso di lavoro un contesto organizzativo. L’analisi per reparto è fondamentale per capire come il lavoro passa da una parte all’altra dell’organizzazione. Aiuta a individuare i colli di bottiglia tra reparti, misurare l’efficienza dei singoli reparti e analizzare l’assegnazione delle risorse ai team. Le Dashboard possono essere filtrate per reparto, così i responsabili possono consultare i dati sulle prestazioni del proprio team. Perché è importante Aggiunge una dimensione organizzativa all’analisi, consentendo di individuare i ritardi tra reparti e valutare le prestazioni dei singoli team. Dove reperirli Queste informazioni possono essere registrate direttamente nei dati degli eventi oppure ricavate unendo i dati degli utenti a una tabella anagrafica delle risorse umane che associa ogni utente al relativo reparto. Consultare la documentazione di ACTICO. Esempi ComplianceTeam di onboardingServizio clienti | |||
| Stato della richiesta ApplicationStatus | Esito finale o stato attuale della richiesta di onboarding del cliente. | ||
| Descrizione Questo attributo indica l’esito finale di un caso, in genere «Approvato» o «Respinto». Può anche indicare lo stato dei casi ancora in corso. È una dimensione fondamentale per l’analisi degli esiti. Capire perché le richieste vengono approvate o respinte è uno degli obiettivi principali del Process Mining applicato ai processi KYC. Questo attributo consente di filtrare la mappa del processo per confrontare i percorsi tipici delle richieste approvate con quelli delle richieste respinte e individuare gli schemi che portano a esiti indesiderati. È inoltre la base per calcolare il KPI «Tasso di rifiuto delle richieste». Perché è importante Definisce l’esito di ogni caso e consente di confrontare le istanze di processo concluse con successo con quelle non riuscite, oltre a calcolare il tasso di rifiuto. Dove reperirli È un attributo a livello di caso, spesso presente nella tabella principale dei casi o delle richieste in ACTICO. Indica lo stato finale della richiesta. Esempi ApprovatoRespintoIn corsoIn attesa di informazioni | |||
| Utente che avvia l’attività InitiatingUser | ID o nome dell’utente che ha eseguito l’attività. | ||
| Descrizione Questo attributo identifica l’utente o l’agente di sistema responsabile dell’esecuzione di un’attività. Collega i passaggi del processo alle persone o ai team che li hanno svolti. L’analisi delle prestazioni per utente è un’esigenza comune. Questo attributo consente di creare Dashboard che mostrano la distribuzione del carico di lavoro, i tempi di elaborazione individuali e le differenze di prestazioni tra utenti o team. Aiuta a individuare sia le persone con prestazioni elevate sia quelle che potrebbero aver bisogno di ulteriore formazione, ed è utile per comprendere come vengono assegnate e utilizzate le risorse. Perché è importante Collega le attività del processo agli utenti che le hanno svolte, consentendo di analizzare le prestazioni di singole persone o team e di individuare esigenze formative o squilibri nell’impiego delle risorse. Dove reperirli In genere è registrato insieme a ogni evento nel log degli eventi o nelle tabelle della cronologia delle transazioni di ACTICO. Consultare la documentazione di ACTICO. Esempi john.doejane.smithSYSTEM_USER | |||
| Automatizzata IsAutomated | Indicatore che specifica se un’attività è stata svolta automaticamente dal sistema o manualmente da un utente. | ||
| Descrizione Questo attributo booleano distingue i task eseguiti da una persona da quelli svolti automaticamente dal sistema, come un controllo dei precedenti o il calcolo del punteggio di rischio. Analizzare questo attributo aiuta a valutare l’efficacia delle iniziative di automazione. Consente di confrontare i tempi di elaborazione delle attività automatizzate con quelli delle attività manuali, individuare le parti del processo che richiedono ancora molto lavoro manuale e mettere in luce opportunità per aumentare l’efficienza e ridurre i costi operativi. Perché è importante Distingue le attività svolte da persone da quelle eseguite dal sistema, un aspetto fondamentale per misurare l’impatto dell’automazione e individuare possibili miglioramenti dell’efficienza. Dove reperirli Il valore può essere dedotto dall’attributo «InitiatingUser», ad esempio quando l’utente è «SYSTEM», oppure può corrispondere a un indicatore specifico nel log degli eventi. Consultare la documentazione di ACTICO. Esempi truefalse | |||
| Paese Country | Paese di residenza del cliente che richiede l’onboarding. | ||
| Descrizione Questo attributo indica il paese del cliente, che può influire in modo significativo sul processo KYC. Le diverse giurisdizioni prevedono requisiti normativi diversi, che possono comportare fasi aggiuntive o alternative nel processo. Analizzare il processo per paese consente di confrontare le prestazioni nelle diverse aree geografiche. Può aiutare a individuare i paesi in cui i tempi di ciclo sono sistematicamente più lunghi o il tasso di rifiuto è più elevato, possibili segnali di ostacoli normativi o di specifiche difficoltà di mercato. Questa prospettiva geografica è importante per le organizzazioni internazionali che intendono standardizzare i processi rispettando al contempo i requisiti locali di conformità. Perché è importante Aggiunge una dimensione geografica all’analisi e aiuta a comprendere le variazioni del processo e le differenze di prestazioni tra le diverse giurisdizioni normative. Dove reperirli È un dato essenziale del cliente, registrato a livello di caso o di cliente nel sistema ACTICO. Esempi USADEUGBRSGP | |||
| Rilavorazione IsRework | Indicatore calcolato che identifica se un’attività è un passaggio ripetuto o fa parte di un ciclo di rilavorazione. | ||
| Descrizione Questo attributo booleano segnala le attività svolte una seconda volta o più all’interno dello stesso caso, per esempio una «Revisione dei documenti» ripetuta dopo una richiesta di ulteriori informazioni. Identifica le rilavorazioni, che sono spesso una fonte di inefficienza del processo. Individuare le rilavorazioni è uno degli obiettivi principali del Process Mining. Questo indicatore consente di quantificarle, per esempio calcolando il KPI «Tasso di rilavorazione dei documenti». Nella mappa del processo, i cicli di rilavorazione possono essere evidenziati per mostrare i punti in cui il processo torna sui propri passaggi. In questo modo è più facile individuare problemi di qualità o le fasi in cui il processo non viene eseguito correttamente al primo tentativo. Perché è importante Evidenzia le attività ripetute, consentendo di misurare direttamente le inefficienze del processo e individuare le attività caratterizzate da problemi di qualità o chiarezza. Dove reperirli È un attributo calcolato. La logica viene definita nello strumento di Process Mining o durante la trasformazione dei dati per rilevare le attività ripetute all’interno dello stesso caso. Esempi truefalse | |||
| Stato SLA SlaState | Stato calcolato che indica se il caso ha rispettato lo SLA, lo ha superato o rischia di superarlo. | ||
| Descrizione Questo attributo fornisce una valutazione per categoria delle prestazioni di un caso rispetto al relativo accordo sul livello di servizio. Si ottiene confrontando l’ora di completamento del caso, oppure l’ora attuale per i casi aperti, con «SlaTargetDate». L’attributo semplifica la rendicontazione degli SLA trasformando il confronto tra date in uno stato facile da interpretare. Le Dashboard possono utilizzarlo per creare visualizzazioni chiare, come grafici a torta o indicatori, che mostrano la percentuale di casi «Rispettati» rispetto a quelli «Superati». È un elemento fondamentale della Dashboard «Prestazioni SLA dell’onboarding» e contribuisce direttamente al KPI «Tasso di rispetto degli SLA dell’onboarding». Perché è importante Fornisce per ogni caso uno stato chiaro e categorizzato sul rispetto dello SLA, semplificando la rendicontazione e la visualizzazione delle prestazioni rispetto agli obiettivi. Dove reperirli È un attributo calcolato in base alla logica aziendale, che confronta la data e l’ora di completamento del caso con «SlaTargetDate». Esempi RispettatoSuperatoA rischio | |||
| Tipo di cliente CustomerType | Categoria del cliente, ad esempio persona fisica o azienda. | ||
| Descrizione Questo attributo classifica i richiedenti in categorie diverse, per esempio persone fisiche e aziende. Il processo KYC può variare notevolmente tra queste categorie: l’onboarding di un’azienda, ad esempio, è molto più complesso. Utilizzare il tipo di cliente come dimensione consente di separare e confrontare chiaramente questi processi distinti all’interno dello stesso set di dati. Gli analisti possono filtrare la mappa del processo per visualizzare solo i clienti «Azienda» e comprenderne le specifiche criticità, i colli di bottiglia e i tempi di ciclo, senza che i dati siano influenzati dal processo molto più semplice previsto per le «Persone fisiche». Perché è importante Consente di segmentare il processo in base alle diverse categorie di clienti, che spesso seguono flussi di lavoro e livelli di complessità molto diversi, rendendo l’analisi più accurata. Dove reperirli È un attributo fondamentale, registrato a livello di caso o di cliente in ACTICO. Esempi Persona fisicaAziendaPiccola impresa | |||
Attività di onboarding KYC dei clienti
| Attività | Descrizione | ||
|---|---|---|---|
| Documenti del cliente caricati | Questa attività si verifica quando il cliente invia i documenti di identità e di supporto richiesti tramite un portale o un altro canale integrato con ACTICO. In genere, ogni caricamento viene registrato nel sistema come evento distinto ed esplicito nel log della gestione documentale o del caso. | ||
| Perché è importante Segna una tappa importante che dipende dal cliente. Monitorare questo evento è fondamentale per misurare i tempi di risposta del cliente e analizzare la durata della successiva fase di revisione dei documenti. Dove reperirli Cerchi i log degli eventi relativi alla gestione dei documenti o agli allegati della pratica. Spesso sono registrati in tabelle dedicate alla gestione dei documenti o delle prove nel database ACTICO. Acquisizione Evento registrato dal sistema quando un documento viene allegato al caso. Tipo di evento explicit | |||
| Onboarding del cliente completato | È l’attività finale del processo: indica che l’onboarding del cliente è terminato e che la pratica è stata chiusa. Si deduce dall’applicazione alla pratica di uno stato finale, come «Onboarding completato» o «Chiuso - Approvato». | ||
| Perché è importante In quanto principale evento finale di esito positivo, questa attività è essenziale per calcolare il tempo di ciclo complessivo di tutti i clienti per cui l’onboarding è stato completato. Fornisce la marca temporale finale per l’analisi del percorso ottimale. Dove reperirli Si deduce dal campo dello stato finale della pratica del cliente. Cerchi la marca temporale associata al passaggio del caso a uno stato finale positivo. Acquisizione Si deduce dall’aggiornamento finale dello stato del caso a «Completato» o «Chiuso». Tipo di evento inferred | |||
| Pratica approvata | Questa attività rappresenta la decisione aziendale finale di approvare la pratica del cliente per l’onboarding. È una tappa fondamentale, in genere registrata come modifica distinta e definitiva dello stato nel ciclo di vita della pratica. | ||
| Perché è importante Questa tappa precede la creazione del conto e indica un esito positivo. Analizzare il tempo necessario per raggiungerla è fondamentale per comprendere la durata del percorso ottimale. Dove reperirli Si deduce dal campo dello stato finale nella tabella principale della pratica o del caso. Cerchi uno stato come «Approvato», «Approvazione completata» o un altro stato finale positivo. Acquisizione Lo stato finale del caso viene aggiornato a «Approvato» nei dati principali del caso. Tipo di evento inferred | |||
| Pratica inviata | Questa attività segna l’inizio del processo di onboarding KYC, quando il sistema ACTICO riceve formalmente una nuova pratica del cliente. Viene registrata come evento esplicito, in genere con una marca temporale precisa al momento della creazione di un nuovo caso o di una nuova pratica. | ||
| Perché è importante In quanto evento iniziale principale, questa attività è essenziale per calcolare il tempo complessivo del ciclo di onboarding e monitorare il volume delle pratiche. Fornisce la marca temporale di riferimento per tutte le successive misurazioni delle prestazioni del processo. Dove reperirli Di solito si tratta di una registrazione esplicita nel log di creazione della pratica o del caso in ACTICO. Cerchi le tabelle relative agli eventi di invio della pratica o la marca temporale di creazione del record principale del caso. Acquisizione Evento registrato alla creazione di una nuova istanza della pratica. Tipo di evento explicit | |||
| Pratica rifiutata | Rappresenta la decisione finale di rifiutare la pratica del cliente, concludendo il processo di onboarding. È uno stato finale importante, registrato tramite una modifica definitiva dello stato della pratica. | ||
| Perché è importante È il principale evento finale con esito negativo. Analizzare i casi che terminano con questa attività è fondamentale per comprendere i tassi e le cause di rifiuto e migliorare il rendimento complessivo del processo. Dove reperirli Si deduce dal campo dello stato finale nella tabella principale della pratica o del caso. Cerchi uno stato conclusivo come «Rifiutato», «Respinto» o «Chiuso - Rifiutato». Acquisizione Lo stato finale del caso viene aggiornato a «Rifiutato» nei dati principali del caso. Tipo di evento inferred | |||
| Revisione di conformità avviata | Segna l’inizio della fase di revisione manuale da parte del reparto conformità, spesso per le pratiche ad alto rischio o segnalate. In genere si deduce dal passaggio dello stato del caso a «In attesa di revisione di conformità» o dall’assegnazione della pratica alla coda di lavoro di un responsabile della conformità. | ||
| Perché è importante Questa attività segna l’inizio della misurazione del collo di bottiglia nella revisione di conformità. Il tempo che intercorre fino al completamento della revisione è un indicatore chiave di prestazione per individuare i ritardi in questa fase cruciale. Dove reperirli Si deduce dalla cronologia degli stati della pratica o dalla traccia di audit. Cerchi la marca temporale associata al passaggio di stato a «In revisione di conformità» o all’assegnazione a un gruppo di utenti responsabile della conformità. Acquisizione Si deduce dal passaggio dello stato del caso a «In attesa di conformità» o dall’assegnazione al team responsabile della conformità. Tipo di evento inferred | |||
| Revisione di conformità completata | Segna la fine della revisione manuale da parte del reparto conformità, con una decisione di approvazione, rifiuto o richiesta di ulteriori interventi. Si deduce dal passaggio dello stato del caso da «In attesa di revisione di conformità» a uno stato successivo, come «Conformità approvata». | ||
| Perché è importante È l’evento conclusivo della fase di revisione di conformità. È essenziale per calcolare la durata complessiva della revisione e analizzare il volume di pratiche gestite dal team. Dove reperirli Si deduce dal log della cronologia degli stati della pratica. Cerchi la marca temporale del passaggio del caso dallo stato «In revisione di conformità», che indica che è stata presa una decisione. Acquisizione Si deduce dal passaggio dello stato del caso da «In attesa di conformità» a «Conformità approvata» o a uno stato simile. Tipo di evento inferred | |||
| Valutazione del rischio eseguita | Questa attività rappresenta l’esecuzione del motore decisionale di ACTICO per calcolare il punteggio o il livello di rischio della pratica del cliente. Essendo una funzione centrale del sistema, viene registrata come evento esplicito quando viene eseguito l’insieme di regole per la valutazione del rischio. | ||
| Perché è importante La valutazione del rischio è un momento decisionale cruciale, che spesso determina il percorso successivo del processo. Analizzare questa attività aiuta a capire come i livelli di rischio incidono sulle varianti e sui tempi del processo. Dove reperirli È un evento centrale in ACTICO e dovrebbe essere registrato nei log decisionali o di esecuzione. Questi log contengono in genere l’ID del caso, le regole eseguite e il punteggio di rischio risultante. Acquisizione Evento registrato dal motore decisionale di ACTICO al termine del calcolo del punteggio di rischio. Tipo di evento explicit | |||
| Conto creato | Dopo l’approvazione, questa attività segna la creazione tecnica del conto del cliente nel sistema bancario centrale o nel sistema di gestione degli utenti. Spesso ACTICO la registra come evento esplicito dopo aver ricevuto una conferma di esito positivo dal sistema a valle. | ||
| Perché è importante Questa attività conferma che il processo ha prodotto un risultato concreto per l’azienda. Il tempo che intercorre tra «Pratica approvata» e «Conto creato» può rivelare ritardi di integrazione o inefficienze nelle fasi finali di attivazione. Dove reperirli Queste informazioni si trovano probabilmente nei log di integrazione o delle interfacce di sistema di ACTICO, che registrano l’esito delle chiamate ai sistemi esterni per la creazione del conto. Acquisizione Evento registrato alla ricezione di una risposta API positiva dal sistema centrale dei conti. Tipo di evento explicit | |||
| Controlli dei precedenti avviati | Indica l’avvio di controlli automatici o manuali dei precedenti, come le verifiche antiriciclaggio o della storia creditizia. Spesso viene registrato come evento esplicito quando il sistema avvia i controlli, che possono coinvolgere fornitori di servizi esterni. | ||
| Perché è importante L’avvio dei controlli dei precedenti è una tappa importante del processo di due diligence. Monitorarlo aiuta a comprendere le dipendenze e i tempi di attraversamento legati ai fornitori di dati esterni. Dove reperirli Cerchi nei log di sistema o nella traccia di audit le registrazioni che indicano l’avvio delle procedure di verifica dei precedenti. Spesso sono associate all’ID del caso principale della pratica. Acquisizione Evento registrato quando il motore del flusso di lavoro avvia le chiamate ai servizi di verifica dei precedenti. Tipo di evento explicit | |||
| Informazioni aggiuntive richieste | Rappresenta un evento in cui un revisore, spesso del reparto conformità o della valutazione del credito, richiede al cliente ulteriori informazioni o documenti. Di solito l’azione viene registrata esplicitamente, poiché comporta spesso l’invio di una notifica al cliente e la sospensione della pratica. | ||
| Perché è importante Questa attività è una delle principali cause di rilavorazione e di allungamento dei tempi di ciclo. Monitorarne la frequenza e l’impatto è essenziale per individuare come migliorare la raccolta iniziale dei dati. Dove reperirli È probabile che si tratti di un evento esplicito registrato nella cronologia del caso o nel log delle comunicazioni. Cerchi eventi come «Richiesta di informazioni inviata» o un cambio di stato specifico, ad esempio «In attesa di informazioni dal cliente». Acquisizione Un evento esplicito avviato dall’utente, come «Invia richiesta di informazioni», viene registrato nella traccia di audit del caso. Tipo di evento explicit | |||
| Prima revisione della pratica | Rappresenta la prima revisione della pratica inviata, eseguita da una regola automatica o da un operatore, per verificarne la completezza e i requisiti di base. Spesso si deduce da una modifica dello stato della pratica, ad esempio da «Inviata» a «In revisione». | ||
| Perché è importante Analizzare il tempo necessario per completare questa prima revisione aiuta a individuare i ritardi iniziali nell’elaborazione. Consente inoltre di capire quante pratiche superano questa prima fase senza problemi. Dove reperirli Si deduce dalle tabelle della cronologia degli stati o dai log di audit associati alla pratica del cliente. Confronti la marca temporale del passaggio da uno stato «nuovo» o «inviato» a uno stato «in revisione». Acquisizione Rilevare nel log della cronologia del caso il passaggio di stato da «Inviata» a «In revisione». Tipo di evento inferred | |||
| Revisione dei documenti completata | Questa attività indica che un operatore ha terminato la revisione dei documenti inviati dal cliente. In genere si deduce da una modifica dello stato del documento o del caso complessivo, ad esempio «Documenti verificati» o «Revisione completata». | ||
| Perché è importante È una tappa fondamentale per misurare l’efficienza del processo di gestione dei documenti. Il tempo che intercorre tra «Documenti del cliente caricati» e questa attività è un indicatore chiave di prestazione per individuare i ritardi nell’elaborazione manuale. Dove reperirli Si deduce dai log della cronologia degli stati della pratica o dei singoli documenti. Il passaggio dello stato di un documento da «In attesa di revisione» ad «Approvato» o «Esaminato» indica che l’attività è stata completata. Acquisizione Si deduce dal passaggio dello stato del documento a «Verificato» o «Esaminato». Tipo di evento inferred | |||
| Verifica dell’identità eseguita | Rappresenta un controllo automatico o manuale che verifica l’identità del cliente confrontandola con fonti di dati interne o esterne. Spesso viene registrato come evento esplicito quando si effettua una chiamata API a un servizio di verifica di terze parti e se ne riceve la risposta. | ||
| Perché è importante Questa attività è un passaggio fondamentale per la conformità. Analizzarne la durata e i risultati aiuta a individuare le dipendenze dai servizi esterni e i possibili colli di bottiglia nel processo di verifica. Dove reperirli Queste informazioni si trovano in genere nei log di integrazione o in tabelle di eventi specifiche che registrano i risultati dei controlli automatici e delle chiamate ai servizi di terze parti associate alla pratica. Acquisizione Evento registrato a seguito di una chiamata di integrazione a un servizio di verifica dell’identità di terze parti. Tipo di evento explicit | |||
Guide all’estrazione dei dati
Passaggi
- Ottenga l’accesso amministrativo: acceda alla piattaforma ACTICO, ad esempio a Visual Modeler o a una console di amministrazione dedicata, con credenziali che Le consentano di accedere alle esportazioni dei dati e configurarle.
- Individui il modulo di esportazione: acceda all’area di amministrazione o configurazione del sistema e individui la sezione dedicata alle tracce di audit, alla registrazione degli eventi o all’esportazione dei dati. Potrebbe essere denominata 'Audit Export' o 'Business Object Export'.
- Crei una nuova configurazione di esportazione: avvii la procedura per creare una nuova definizione di esportazione e assegni alla configurazione un nome descrittivo, ad esempio 'KYC_Onboarding_ProcessMind_Export'.
- Definisca l’origine dei dati: specifichi l’oggetto aziendale principale da esportare, ovvero
CustomerApplication. È fondamentale applicare un filtro per intervallo di date, ad esempio gli ultimi 6 mesi, così da mantenere gestibili le dimensioni dei file e i tempi di elaborazione. - Configuri il file di output: imposti il formato CSV, definisca il nome del file, ad esempio
kyc_event_log.csv, e confermi il delimitatore, in genere una virgola. Verifichi che i campi di testo siano racchiusi correttamente tra virgolette per gestire i caratteri speciali. - Mappi l’identificativo del caso: indichi l’identificativo univoco dell’oggetto aziendale
CustomerApplicationcome ID del caso per l’analisi di Process Mining. In questo modo, tutti gli eventi correlati vengono associati a un’unica pratica di onboarding. - Definisca la mappatura degli attributi: per ogni colonna richiesta nell’event log, la associ all’attributo corrispondente nel modello degli oggetti aziendali ACTICO. Includa l’ID del caso, il nome dell’attività, le date e gli orari e gli altri attributi consigliati, come lo stato o il livello di rischio.
- Configuri la mappatura degli eventi: questo è il passaggio più importante. Crei una regola o una mappatura specifica per ciascuna delle 14 attività aziendali. Utilizzi trigger di sistema, come la creazione di un oggetto per 'Application Submitted', le modifiche di stato per i passaggi del flusso di lavoro come 'Application Approved' e specifici schemi dei messaggi nel registro di audit per gli eventi tecnici come 'Identity Verification Performed'.
- Salvi e convalidi la configurazione: dopo aver definito tutte le mappature, salvi il file di configurazione. Utilizzi gli strumenti di convalida disponibili in ACTICO per verificare la presenza di errori di sintassi o percorsi degli attributi non corretti.
- Esegua e monitori l’esportazione: avvii il processo di esportazione e ne controlli l’avanzamento tramite la pianificazione dei processi o l’interfaccia di monitoraggio del sistema. Al termine, verifichi nei registri la presenza di eventuali errori.
- Recuperi e prepari il file: scarichi il file CSV dalla cartella di output indicata sul server. Prima di caricarlo in ProcessMind, lo apra per verificarne la struttura e assicurarsi che i formati di date e orari siano coerenti e interpretati correttamente.
Configurazione
- Livello del registro di audit: il livello di registrazione degli audit a livello di sistema deve essere impostato su un livello dettagliato, ad esempio INFO o FINE. Un livello meno dettagliato, come WARNING o ERROR, non registrerà le modifiche di stato e le esecuzioni delle regole necessarie per il Process Mining.
- Origine dei dati da esportare: l’origine principale dei dati deve essere configurata per utilizzare l’oggetto aziendale
CustomerApplication. Potrebbe essere necessario unire o fare riferimento a oggetti correlati, comeCustomerDocument, per acquisire tutti gli eventi pertinenti. - Filtro per intervallo di date: utilizzi sempre un filtro per intervallo di date per controllare la quantità di dati estratti. Per l’analisi iniziale, si consiglia un periodo da 3 a 6 mesi. In produzione, l’intervallo può essere adeguato in base alle esigenze aziendali e alle prestazioni del sistema.
- Logica di mappatura degli eventi: l’accuratezza dell’estrazione dipende in larga misura dalla mappatura degli eventi. Le modifiche di stato (
on="StatusChange") sono spesso utilizzate per dedurre i passaggi aziendali. Le voci esplicite del registro (on="LogEntry") sono utili per gli eventi tecnici o le chiamate ai servizi. Le esecuzioni delle regole (on="RuleExecution") sono ideali per acquisire i passaggi decisionali. - Formato di output: selezioni CSV per garantire un’ampia compatibilità. Verifichi che i delimitatori e la gestione delle virgolette nei campi di testo siano configurati correttamente, così da evitare problemi nell’interpretazione dei dati.
- Prerequisiti: questo metodo richiede autorizzazioni amministrative per la piattaforma ACTICO. Per configurarlo correttamente, è essenziale conoscere a fondo il modello degli oggetti aziendali KYC, inclusi tutti i campi di stato e i nomi degli attributi pertinenti.
a Query di esempio 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> È pronto a iniziare?
Utilizzi questo template per preparare i dati in modo efficace e accelerare il percorso verso l’ottimizzazione dell’onboarding dei clienti KYC in ACTICO.
Ottimizzi l’onboarding dei clienti KYC: riduca subito i tempi a 24 ore
Riduca gli abbandoni e i falsi positivi per rendere l’onboarding più semplice.
Non è richiesta alcuna carta di credito. Inizi oggi a ottimizzare il processo.