> Miglioramento continuo dei processi > Inserimento dei clienti KYC > Refinitiv World Check > Template dei dati

Il template dei dati per l’onboarding KYC dei clienti

Refinitiv World-Check

Attributi per l’onboarding KYC dei clienti (19) Attività di onboarding KYC dei clienti (14) Guide all’estrazione (2)

Il template dei dati per l’onboarding KYC dei clienti

Questo template La guida nella raccolta dei dati essenziali per analizzare il processo di onboarding KYC dei clienti. Indica gli attributi fondamentali da acquisire e le attività principali da monitorare, oltre a fornire indicazioni su come estrarre queste informazioni dai sistemi di origine. Utilizzi questa risorsa per assicurarsi di disporre di tutti i dati necessari a un’analisi e a un miglioramento efficaci del processo.

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.

Scarica il template

Attributi per l’onboarding KYC dei clienti

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa dell’onboarding KYC dei clienti.

3 Obbligatorio 5 Consigliato 11 Facoltativo

	Nome	Descrizione
	Domanda del cliente CustomerApplication	Identificativo univoco della domanda di onboarding di un singolo cliente, utilizzato come identificativo principale del caso.
Descrizione La domanda del cliente è l’identificativo centrale del caso, che raggruppa tutti gli eventi e le attività relativi al percorso di onboarding di un singolo cliente. Consente di seguire in ordine cronologico l’avanzamento di ogni cliente nell’intero processo Know Your Customer (KYC), dall’invio iniziale alla decisione finale. Nell’analisi di Process Mining, questo attributo è fondamentale per ricostruire il percorso completo di ogni domanda. Consente di visualizzare i flussi di processo, calcolare i tempi di ciclo complessivi e individuare le varianti. Raggruppando i casi in base a questo identificativo, le organizzazioni possono capire quali percorsi può seguire una domanda, individuare i colli di bottiglia e confrontare l’efficienza dei diversi processi di onboarding. Perché è importante È l’identificativo essenziale del caso che collega tutte le attività correlate e consente di analizzare il processo di onboarding del cliente dall’inizio alla fine. Dove reperirli Questo identificativo è in genere la chiave primaria della tabella principale delle domande o della gestione dei casi nel sistema Refinitiv World-Check o in un CRM integrato. Esempi APP-2023-00123APP-2023-00124APP-2023-00125
	Nome dell’attività ActivityName	Nome di uno specifico evento aziendale o di un’attività che si è verificata durante il processo di onboarding KYC.
Descrizione Il nome dell’attività descrive un singolo passaggio o evento del percorso di onboarding del cliente, ad esempio «Domanda inviata», «Revisione dell’analista avviata» o «Screening completato: esito senza corrispondenze». Queste attività costituiscono i nodi della mappa del processo e ne descrivono in dettaglio il flusso di lavoro dall’inizio alla fine. L’analisi delle attività è alla base del Process Mining. Monitorando la sequenza e la frequenza delle diverse attività, gli analisti possono individuare il flusso effettivo del processo, riconoscere i percorsi più comuni, rilevare gli scostamenti dalla procedura standard e identificare i passaggi che causano ritardi o rilavorazioni. Questo attributo è essenziale per creare mappe di processo e calcolare le metriche relative alle singole attività. Perché è importante Questo attributo definisce i singoli passaggi del processo ed è essenziale per individuare e visualizzare il flusso del processo e i relativi colli di bottiglia. Dove reperirli Queste informazioni si trovano in genere nei log degli eventi o nelle tabelle del registro di audit, spesso associate alle modifiche di stato dell’entità di gestione dei casi. Esempi Potenziale corrispondenza individuataRevisione dell’analista avviataFalso positivo confermatoDomanda approvata
	Ora dell’evento EventTime	La marca temporale che indica quando si è verificata una specifica attività o un evento.
Descrizione L’ora dell’evento indica la data e l’ora precise in cui è stata registrata un’attività. Questa marca temporale costituisce la base cronologica del processo e permette di ordinare correttamente gli eventi per ricostruire la cronologia del caso. Questo attributo è fondamentale per tutte le analisi temporali di Process Mining. Serve a calcolare la durata tra le attività, inclusi i tempi di ciclo e di attesa, misurare la durata complessiva del caso, analizzare nel tempo le prestazioni del processo e verificare il rispetto degli accordi sul livello di servizio (SLA). Senza marche temporali precise, è impossibile comprendere le prestazioni del processo e individuare i colli di bottiglia temporali. Perché è importante La marca temporale di ogni attività è essenziale per calcolare tutte le metriche basate sulla durata, ricostruire la sequenza del processo e analizzare i colli di bottiglia. Dove reperirli È un campo standard in qualsiasi log degli eventi o tabella del registro di audit, spesso denominato «Timestamp», «EventDate» o «CreationDate». Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Data obiettivo SLA SlaTargetDate	La data entro cui dovrebbe essere completato il processo di onboarding del cliente.
Descrizione La data obiettivo SLA è la scadenza entro cui completare l’intero caso di onboarding, definita dall’accordo sul livello di servizio con il cliente o dalle politiche interne. È il riferimento con cui confrontare i tempi effettivi di completamento. Questo attributo è fondamentale per la Dashboard «Rispetto degli SLA e analisi delle violazioni». Serve a calcolare se un caso è stato completato entro la scadenza. Analizzare le violazioni degli SLA aiuta a individuare problemi sistemici del processo che causano ritardi e permette all’organizzazione di intervenire per migliorare la puntualità e rispettare i requisiti di conformità. Perché è importante È il riferimento per misurare il rispetto delle scadenze ed è fondamentale per calcolare il tasso di rispetto degli SLA e analizzarne le violazioni. Dove reperirli Questa data viene spesso calcolata in base alla data di invio della domanda e alle regole aziendali. Può essere memorizzata in un campo del record del caso. Esempi 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	ID del revisore ReviewerId	Identificativo dell’utente, dell’analista o dell’agente automatizzato che ha eseguito l’attività.
Descrizione L’ID del revisore, o dell’utente, indica chi ha eseguito una determinata attività nel processo KYC. Può trattarsi di un analista della conformità, di uno specialista dell’onboarding o di un account di sistema per le attività automatizzate. Monitorare queste informazioni permette di conoscere la distribuzione del carico di lavoro e le prestazioni individuali. Questo attributo è essenziale per l’analisi delle risorse. Aiuta a comprendere le differenze di prestazioni tra utenti o team, individuare le esigenze di formazione e bilanciare meglio il carico di lavoro. È inoltre importante per analizzare i passaggi di consegne, le reti di collaborazione e l’impiego delle risorse dedicate alla conformità. Perché è importante Consente di analizzare la distribuzione del carico di lavoro, le prestazioni degli utenti e i passaggi di consegne tra reparti, aspetti fondamentali per ottimizzare le risorse. Dove reperirli Si trova in genere nei log degli eventi o nei registri di audit, spesso con nomi quali «UserID», «PerformedBy» o «Owner». Esempi analyst_jdoesystem_auto_screenermanager_bsmith
	Livello di rischio RiskLevel	Classificazione del rischio calcolata per la domanda del cliente, ad esempio basso, medio o alto.
Descrizione Il livello di rischio è un’informazione fondamentale nei processi KYC, perché determina il livello di verifica richiesto. Spesso viene definito in base a fattori quali il tipo di cliente, l’area geografica e la natura dell’attività svolta. Questa classificazione può influire in modo significativo sul percorso seguito dalla domanda. Nell’analisi dei processi è essenziale segmentare i casi per livello di rischio. Ciò aiuta a spiegare le differenze nei tempi di ciclo e nei flussi di processo: per esempio, le domande ad alto rischio possono richiedere più passaggi e tempi più lunghi. Questo attributo è fondamentale per le Dashboard «Tasso e motivi di rifiuto delle domande» e «Tempo di avvio del controllo dei precedenti», che permettono di capire come il rischio influisce sugli esiti e sull’efficienza. Perché è importante Segmentare il processo per livello di rischio è fondamentale per capire perché alcuni casi richiedono più tempo o seguono percorsi diversi e per analizzare i tassi di rifiuto. Dove reperirli È un dato essenziale della domanda del cliente o del record del caso. Consultare il modulo di gestione dei casi in Refinitiv World-Check. Esempi BassoMedioAlto
	Ora di fine dell’evento EventEndTime	La marca temporale che indica quando è stata completata una specifica attività o un evento.
Descrizione L’ora di fine dell’evento indica il completamento di un’attività. Molti eventi possono essere modellati come istantanei, con ora di inizio e ora di fine coincidenti, mentre altre attività hanno una durata misurabile, come «Revisione dell’analista avviata» e «Revisione dell’analista completata». Disporre sia dell’ora di inizio sia di quella di fine consente di misurare con precisione il tempo di elaborazione. Nell’analisi dei processi, l’ora di fine è indispensabile per calcolare il tempo di elaborazione esatto di un’attività, distinto dal tempo di ciclo, che include anche l’attesa. In questo modo è possibile distinguere il tempo in cui il caso viene effettivamente gestito da quello in cui resta inattivo in coda. È un elemento fondamentale per ottimizzare le risorse e analizzare l’efficienza. Perché è importante Consente di calcolare con precisione il tempo di elaborazione delle attività, distinguendo il tempo di lavoro effettivo dall’attesa inattiva per un’analisi più accurata delle prestazioni. Dove reperirli Per le attività che hanno una durata, il dato può essere memorizzato in un campo separato, ad esempio «CompletionDate» o «EndDate», nelle tabelle del log degli eventi o del registro di audit. Esempi 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Reparto DepartmentName	Il reparto o il team funzionale responsabile dell’attività.
Descrizione Questo attributo specifica l’unità aziendale o il team di appartenenza dell’utente, ad esempio «Onboarding», «Conformità» o «Controllo qualità». Consente di analizzare il processo a un livello organizzativo più ampio rispetto al singolo utente. L’analisi per reparto è fondamentale per individuare i colli di bottiglia tra reparti e misurare i tempi dei passaggi di consegne. Aiuta a visualizzare il flusso di lavoro tra i diversi team e a capire dove si verificano ritardi durante queste transizioni. Questa prospettiva è preziosa per semplificare la collaborazione tra funzioni e migliorare l’efficienza complessiva del processo. Perché è importante Consente di analizzare le prestazioni del processo per reparto ed è essenziale per individuare i ritardi nei passaggi di consegne tra team. Dove reperirli Queste informazioni possono essere memorizzate nel profilo dell’utente nel sistema o in un sistema HR associato. Potrebbe essere necessario unirle ai dati degli eventi tramite l’ID utente. Esempi Team di onboardingRevisione di conformitàDirigenza
	Canale di invio della domanda ApplicationChannel	Il canale attraverso cui è stata inviata la domanda del cliente, ad esempio portale online, filiale o applicazione mobile.
Descrizione Il canale di invio della domanda indica da dove proviene la domanda del cliente. I diversi canali possono presentare livelli differenti di completezza e qualità dei dati e raggiungere tipologie diverse di clienti, con possibili effetti sulle fasi successive del processo. Questo attributo è essenziale per la Dashboard «Volume delle domande per canale». Analizzando il volume, i tempi di ciclo e gli esiti delle domande provenienti dai diversi canali, un’organizzazione può individuare quelli più efficienti e quelli che richiedono miglioramenti. L’analisi supporta le decisioni strategiche sull’allocazione delle risorse e sugli investimenti nei canali. Perché è importante Aiuta ad analizzare le prestazioni e l’efficienza dei diversi canali di invio e supporta le decisioni strategiche sulla tecnologia e sull’esperienza dei clienti. Dove reperirli Queste informazioni vengono in genere acquisite all’inizio del processo e memorizzate come attributo nel record della domanda. Esempi Portale onlineApplicazione mobileFilialeGestore delle relazioni con i clienti
	È automatizzata IsAutomated	Indicatore che specifica se l’attività è stata eseguita da un sistema (true) o da una persona (false).
Descrizione Questo attributo booleano distingue le attività automatizzate eseguite dal sistema da quelle manuali svolte dagli utenti. Ad esempio, «Screening automatizzato eseguito» viene contrassegnata come automatizzata, mentre «Revisione dell’analista avviata» viene indicata come manuale. Questa distinzione è fondamentale per l’analisi dell’automazione. Aiuta a misurare l’impatto dell’automazione sull’efficienza del processo, a individuare le attività manuali che potrebbero essere automatizzate in futuro e a comprendere l’interazione tra le persone e i sistemi. Consente inoltre di distinguere chiaramente il tempo di elaborazione del sistema da quello dedicato alla gestione manuale. Perché è importante Distingue le attività svolte dal sistema da quelle svolte dalle persone, un aspetto essenziale per misurare l’impatto dell’automazione e individuare nuove opportunità di automazione. Dove reperirli In genere, il valore si ricava dal nome dell’attività o dall’ID utente associato all’evento, ad esempio quando l’utente è un account di sistema. Esempi truefalse
	È una rilavorazione IsRework	Indicatore che segnala se un’attività viene eseguita una seconda volta o più volte nella stessa pratica.
Descrizione IsRework è un attributo booleano calcolato che individua le attività ripetute nella stessa pratica di richiesta del cliente. Ad esempio, se «Valutazione del rischio eseguita» si verifica più di una volta per una singola richiesta, le occorrenze successive vengono contrassegnate come rilavorazioni. Questo attributo è fondamentale per individuare inefficienze, cicli e ripetizioni non necessarie nel processo. Supporta direttamente la Dashboard «Rilavorazioni ed efficienza della valutazione del rischio» e il KPI «Tasso di rilavorazione della valutazione del rischio». L’analisi delle rilavorazioni aiuta a far emergere problemi di qualità, chiarezza delle informazioni o processo decisionale, che comportano sprechi di lavoro e tempi di ciclo più lunghi. Perché è importante Evidenzia le inefficienze del processo segnalando le attività ripetute e consente di analizzare i cicli di rilavorazione per migliorare la qualità e ridurre i tempi di ciclo. Dove reperirli Il valore viene calcolato durante la trasformazione dei dati analizzando la sequenza delle attività in ogni pratica e segnalando tutte le occorrenze successive alla prima. Esempi truefalse
	ID cliente CustomerId	Identificativo univoco dell’entità cliente sottoposta a onboarding.
Descrizione L’ID cliente è l’identificativo univoco del profilo del cliente. È distinto dall’ID della domanda del cliente, perché uno stesso cliente può inviare più domande nel tempo. Questo attributo collega il processo di onboarding al record principale del cliente. Nell’analisi, l’ID cliente permette di monitorare le domande ripetute dello stesso cliente e può essere utilizzato per arricchire i dati del processo con altri attributi del cliente provenienti da un CRM o da un sistema di dati anagrafici. Consente così di ottenere una visione più completa del percorso del cliente, oltre la singola esperienza di onboarding. Perché è importante Collega il caso di onboarding a un cliente specifico, consentendo di analizzare le domande ripetute e arricchire i dati con le informazioni anagrafiche principali. Dove reperirli È un campo essenziale del record della domanda o del caso, che lo collega ai dati anagrafici principali del cliente. Esempi CUST-98765CUST-98766CUST-98767
	ID corrispondenza MatchId	Identificativo univoco di una potenziale corrispondenza individuata durante uno screening World-Check.
Descrizione Quando il processo di screening automatizzato rileva una possibile corrispondenza con gli elenchi di sanzioni, le liste PEP o le notizie negative, spesso viene generato un ID corrispondenza per identificare il risultato specifico. Questo ID collega la pratica di richiesta al record specifico nel database World-Check che ha generato l’avviso. Questo attributo è utile per un’analisi dettagliata della conformità. Consente agli analisti di approfondire la natura delle corrispondenze, seguire la risoluzione di singoli avvisi, ad esempio confermando un falso positivo o una corrispondenza effettiva, e capire quali tipi di avviso sono più frequenti o richiedono più tempo per essere risolti. Offre un livello di dettaglio maggiore sull’attività «Possibile corrispondenza identificata». Perché è importante Collega in modo puntuale i risultati specifici dello screening, consentendo di analizzare più a fondo i tempi di risoluzione delle corrispondenze e le tipologie di avviso. Dove reperirli Questo ID viene generato dal motore di screening World-Check e registrato nella pratica di richiesta quando viene rilevata una possibile corrispondenza. Esempi WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Motivo del rifiuto RejectionReason	Motivo specificato per il rifiuto della domanda di un cliente.
Descrizione Quando una domanda viene rifiutata, il motivo del rifiuto indica la ragione della decisione. Tra i possibili motivi figurano «Corrispondenza con un soggetto sanzionato», «Documentazione incompleta» o «Profilo ad alto rischio». Queste informazioni forniscono riscontri strutturati e preziosi sulla qualità delle domande ricevute e sull’efficacia del processo di screening. Questo attributo è il principale riferimento per la Dashboard «Tasso e motivi di rifiuto delle domande». Analizzare i motivi aiuta a individuare le cause profonde dei rifiuti e può portare a miglioramenti del processo, comunicazioni più chiare con i richiedenti e una possibile riduzione dei rifiuti non necessari. Aggiunge un contesto qualitativo all’indicatore quantitativo del tasso di rifiuto. Perché è importante Indica le cause profonde dei rifiuti delle domande ed è essenziale per individuare gli aspetti del processo di onboarding da migliorare e ridurre il tasso di rifiuto. Dove reperirli Viene registrato al verificarsi dell’evento «Domanda rifiutata», probabilmente in un campo del record del caso o della domanda. Esempi Corrispondenza con una persona politicamente esposta (PEP)Corrispondenza con un elenco di sanzioniVerifica dei documenti non superataNotizie negative
	Paese del cliente CustomerCountry	Paese di residenza o di costituzione del cliente.
Descrizione Questo attributo indica la posizione geografica del cliente. Il paese è un fattore importante nella valutazione del rischio e nei requisiti normativi dei processi KYC. Le diverse giurisdizioni applicano regole diverse, che possono influire sul flusso e sulla durata del processo. Analizzare il processo per paese consente alle organizzazioni di confrontare le prestazioni tra regioni, individuare i colli di bottiglia specifici di una determinata area e garantire il rispetto delle normative locali. Aggiunge una dimensione geografica all’analisi del processo e può rivelare differenze operative importanti. Perché è importante Consente di analizzare il processo su base geografica e aiuta a individuare differenze regionali nelle prestazioni, nei rischi e nei requisiti di conformità. Dove reperirli È un campo standard del profilo del cliente o del modulo di domanda. Esempi USAGBRSGPDEU
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati degli eventi, in questo caso Refinitiv World-Check.
Descrizione Questo attributo identifica l’origine dei dati del processo. In un’estrazione da un’unica fonte può avere un valore costante, ma diventa fondamentale quando si combinano dati provenienti da più sistemi, ad esempio un CRM e World-Check, per ottenere una visione completa del processo. Nell’analisi, aiuta a gestire i dati, risolvere i problemi e comprenderne il contesto. Per esempio, le attività registrate nel sistema principale di screening possono avere caratteristiche o livelli di dettaglio diversi da quelli delle attività provenienti da un sistema periferico. Consente inoltre di mantenere chiara e verificabile la provenienza dei dati. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la gestione e la convalida dei dati e per l’unione di dati provenienti da più fonti. Dove reperirli Spesso è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per identificare il set di dati. Esempi Refinitiv World-CheckWorldCheckOne
	SLA non rispettato SlaBreached	Indicatore booleano che segnala se la pratica di onboarding è stata completata dopo la data obiettivo dello SLA.
Descrizione Questo attributo calcolato indica se una pratica non ha rispettato il proprio accordo sul livello di servizio. Il valore si determina confrontando la data e l’ora dell’attività finale di completamento, ad esempio «Richiesta approvata» o «Richiesta respinta», con il campo «SlaTargetDate» della pratica. Questo indicatore costituisce la base della Dashboard «Analisi del rispetto e delle violazioni degli SLA» e del KPI «Tasso di rispetto degli SLA». Semplifica l’analisi perché consente agli utenti di filtrare rapidamente tutte le pratiche con SLA non rispettato. Analizzando le caratteristiche del processo per queste pratiche, le organizzazioni possono individuare le cause profonde dei ritardi e concentrare in modo efficace gli interventi di miglioramento. Perché è importante Misura direttamente il rispetto degli accordi sul livello di servizio e consente di filtrare facilmente le pratiche in ritardo e analizzarne le cause profonde. Dove reperirli Il valore viene calcolato durante la trasformazione dei dati, confrontando la data e l’ora dell’attività finale di una pratica con il campo SlaTargetDate. Esempi truefalse
	Tipo di cliente CustomerType	Classificazione del cliente, ad esempio persona fisica, società o trust.
Descrizione Il tipo di cliente identifica la categoria dell’entità sottoposta a onboarding. Le diverse categorie di clienti hanno spesso requisiti di onboarding, profili di rischio e obblighi normativi differenti. Per esempio, l’onboarding di una società è in genere più complesso di quello di una persona fisica. Questo attributo viene utilizzato per le analisi per segmento, in particolare nella Dashboard «Prestazioni KYC per tipo di cliente». Consente di confrontare l’efficienza del processo, i tempi di ciclo e i tassi di rifiuto tra diversi segmenti di clientela. In questo modo le organizzazioni possono adattare e ottimizzare l’esperienza di onboarding per ogni tipo di cliente. Perché è importante Consente di confrontare le prestazioni tra diversi segmenti di clientela e di adattare e ottimizzare il processo di onboarding per ciascuno di essi. Dove reperirli È un attributo fondamentale memorizzato nel record del cliente o della domanda nel sistema di origine. Esempi Persona fisicaSocietàOrganizzazione senza scopo di lucroTrust
	Ultimo aggiornamento dei dati LastDataUpdate	La marca temporale dell’ultimo aggiornamento o dell’ultima estrazione dei dati dell’evento dal sistema di origine.
Descrizione Questo attributo indica quanto sono aggiornati i dati. Registra la data e l’ora dell’ultima estrazione da Refinitiv World-Check. È importante per capire quanto siano aggiornate le Dashboard e le analisi di Process Mining. Ai fini dell’analisi, permette di sapere se si stanno consultando dati quasi in tempo reale o un’istantanea riferita a un momento specifico. È essenziale per la gestione dei dati e per definire aspettative corrette sull’attualità delle informazioni fornite. Perché è importante Fornisce un contesto essenziale sull’aggiornamento dei dati, aiutando a capire quanto sia aggiornata l’analisi del processo. Dove reperirli Questa marca temporale viene generata e aggiunta durante il processo di estrazione dei dati (ETL). Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z

Obbligatorio Consigliato Facoltativo

Attività di onboarding KYC dei clienti

Questi sono i passaggi e le tappe principali del processo da acquisire nell’Event Log per individuare il processo con precisione.

8 Consigliato 6 Facoltativo

	Attività	Descrizione
	Conto attivato	Il conto del cliente viene creato e attivato nel sistema principale, completando il percorso di onboarding. L’attivazione segue l’approvazione finale della domanda e rende il conto disponibile all’uso.
Perché è importante È l’ultimo passaggio del processo, quello che genera valore. Il tempo che intercorre tra l’invio della domanda e l’attivazione del conto è una metrica importante per valutare l’efficienza operativa e la soddisfazione dei clienti. Dove reperirli Questo evento non viene acquisito in World-Check. È registrato nel sistema bancario principale o nel sistema dei conti cliente e va associato tramite l’ID della domanda del cliente. Acquisizione Evento registrato nel sistema principale dei conti al momento dell’attivazione. Tipo di evento explicit
	Corrispondenza effettiva confermata	L’analista conferma che la potenziale corrispondenza riguarda effettivamente il cliente sottoposto a screening, individuando un possibile rischio. È una tappa cruciale che in genere avvia ulteriori verifiche o porta al rifiuto della domanda.
Perché è importante È un esito fondamentale per la mitigazione dei rischi e un momento decisivo del processo. Influisce direttamente sulla decisione finale relativa alla domanda del cliente ed è essenziale per la rendicontazione e l’analisi della conformità. Dove reperirli È un’azione esplicita dell’utente: l’analista classifica una specifica corrispondenza come «Corrispondenza effettiva» o «Corrispondenza confermata». L’evento viene registrato nel registro di audit del caso. Acquisizione Registrato quando un analista conferma formalmente una corrispondenza nel sistema. Tipo di evento explicit
	Domanda rifiutata	La domanda del cliente viene rifiutata formalmente, spesso in seguito a una «Corrispondenza individuata» in World-Check o ad altri fattori di rischio. È l’esito negativo finale del processo di onboarding.
Perché è importante È il principale esito negativo del processo. Analizzare i rifiuti, in particolare le motivazioni e le attività che li precedono, è essenziale per migliorare il processo e ridurre i rifiuti non necessari. Dove reperirli Questa decisione aziendale finale viene registrata nel CRM a monte o nel sistema applicativo principale, non in World-Check. I dati devono quindi essere acquisiti da quel sistema. Acquisizione Evento registrato nel sistema applicativo di origine, spesso con il relativo codice del motivo del rifiuto. Tipo di evento explicit
	Revisione dell’analista avviata	Un analista della conformità avvia l’indagine manuale sulle potenziali corrispondenze relative alla domanda di un cliente. L’attività consiste nel confrontare i dettagli delle potenziali corrispondenze con le informazioni del cliente per determinarne la rilevanza.
Perché è importante Segna l’inizio della revisione manuale di conformità, spesso un collo di bottiglia. Misurare il tempo tra «Potenziale corrispondenza individuata» e questa attività permette di rilevare i ritardi in coda, mentre la durata della revisione indica l’efficienza degli analisti. Dove reperirli Si può dedurre quando un analista prende in carico o apre un caso dalla coda di revisione. Il sistema può registrare esplicitamente l’evento nel registro di audit quando lo stato del caso passa a «In revisione» o il caso viene assegnato a un utente specifico. Acquisizione Si deduce dal passaggio dello stato del caso a «In revisione» o dall’assegnazione del caso a un analista. Tipo di evento inferred
	Richiesta di controllo creata	Nel sistema Refinitiv World-Check viene creato formalmente un nuovo caso di controllo per una richiesta del cliente. L’operazione è avviata da una chiamata API o da un inserimento manuale proveniente da un sistema a monte e segna l’inizio della verifica delle informazioni sui rischi.
Perché è importante Segna l’avvio ufficiale del sottoprocesso di screening. Il tempo che intercorre tra l’invio della domanda e questa attività evidenzia eventuali ritardi nei passaggi di consegne tra il sistema aziendale e la funzione di conformità. Dove reperirli Registrato nei log di gestione dei casi o nel registro di audit di World-Check. Si utilizza l’evento di creazione e la relativa marca temporale per l’ID del caso o dell’entità. Acquisizione Registrato automaticamente alla creazione di un nuovo caso di screening nel sistema. Tipo di evento explicit
	Richiesta inviata	Questa attività segna l’avvio del processo di inserimento KYC, quando il cliente invia la propria richiesta. L’evento viene in genere registrato in un sistema CRM o in un sistema applicativo centrale, che avvia poi il controllo in Refinitiv World-Check.
Perché è importante È l’evento di inizio principale del percorso completo di inserimento del cliente. Analizzare il tempo che intercorre da questo momento al completamento consente di calcolare il tempo di ciclo complessivo, un indicatore fondamentale per misurare l’esperienza dei clienti e il rispetto degli SLA. Dove reperirli Questo evento non è nativo di World-Check. Deve essere recuperato da un sistema a monte, come un CRM o una piattaforma di gestione dei conti dei clienti, e associato tramite l’ID della richiesta del cliente. Acquisizione Evento registrato nel sistema applicativo di origine al momento dell’invio iniziale. Tipo di evento explicit
	Screening completato: corrispondenza individuata	Il caso di screening viene chiuso ufficialmente con esito «Corrispondenza individuata», che indica l’identificazione di un rischio confermato. La decisione avvia un processo successivo diverso, ad esempio verifiche rafforzate o il rifiuto della domanda.
Perché è importante È il principale esito negativo del processo di screening. Analizzare questi casi aiuta a comprendere i profili di rischio e l’efficacia dei controlli di screening. Dove reperirli Si deduce dal passaggio dello stato finale del caso a «Corrispondenza individuata», «Rischio identificato» o «Chiuso: esito positivo». Si utilizza la marca temporale dell’ultima modifica di stato. Acquisizione Si ricava dalla marca temporale dello stato finale del caso che indica una corrispondenza confermata. Tipo di evento inferred
	Screening completato: esito senza corrispondenze	Il caso di screening viene chiuso ufficialmente con esito «Nessuna corrispondenza», ossia senza che siano state individuate corrispondenze effettive. La decisione viene comunicata al sistema di origine, consentendo di proseguire con l’onboarding.
Perché è importante Questa attività rappresenta il completamento regolare del processo di screening. È un punto di arrivo importante per misurare i tempi di ciclo delle domande standard a basso rischio. Dove reperirli Si deduce dal passaggio dello stato finale del caso a «Nessuna corrispondenza», «Completato» o «Chiuso: nessuna corrispondenza». Si utilizza la marca temporale dell’ultima modifica di stato. Acquisizione Si ricava dalla marca temporale dello stato finale del caso che indica un esito senza corrispondenze. Tipo di evento inferred
	Caso inoltrato per la revisione	Un analista di primo livello inoltra un caso complesso o ad alto rischio a un analista senior o a un responsabile per la decisione finale. È un passaggio di consegne importante all’interno del team di conformità.
Perché è importante Le escalation spesso creano colli di bottiglia e allungano i tempi di ciclo. Analizzarne la frequenza e le motivazioni può mettere in luce esigenze di formazione per gli analisti junior o ambiguità nelle procedure di revisione. Dove reperirli Registrato come azione esplicita nel flusso di lavoro del caso o nel registro di audit. Si può anche dedurre da una modifica dell’utente assegnato al caso, soprattutto se viene assegnato a un utente con autorizzazioni più ampie. Acquisizione Registrato tramite il pulsante dedicato «Inoltra» o un’azione del flusso di lavoro all’interno del caso. Tipo di evento explicit
	Domanda approvata	La domanda del cliente è stata approvata dopo il completamento dello screening KYC e degli eventuali altri controlli richiesti. L’evento si verifica in genere nel sistema di origine dopo aver ricevuto da World-Check un esito senza corrispondenze.
Perché è importante Segna il buon esito dell’onboarding. Misurare il tempo trascorso dall’invio della domanda fino a questo momento permette di calcolare il tempo complessivo necessario per accettare un nuovo cliente. Dove reperirli Questo evento non è nativo di World-Check. Va acquisito dal CRM a monte o dal sistema applicativo principale, che prende la decisione aziendale finale. Acquisizione Evento registrato nel sistema applicativo di origine al momento dell’approvazione finale. Tipo di evento explicit
	Falso positivo confermato	L’analista conclude che la potenziale corrispondenza non riguarda il cliente sottoposto a screening. La corrispondenza viene respinta e lo screening per la specifica segnalazione si considera risolto.
Perché è importante È uno degli esiti più comuni del processo di revisione. Sapere quanto tempo occorre per classificare i falsi positivi aiuta a misurare l’efficienza degli analisti e la precisione dei criteri di screening automatizzato. Dove reperirli È un’azione esplicita dell’utente: l’analista classifica una specifica corrispondenza come «Falso positivo» o «Nessuna corrispondenza». L’azione viene in genere registrata nella cronologia del caso. Acquisizione Registrato quando un analista respinge formalmente una potenziale corrispondenza nel sistema. Tipo di evento explicit
	Informazioni aggiuntive richieste	L’analista stabilisce che servono altre informazioni per risolvere la potenziale corrispondenza e le richiede all’unità aziendale. Il caso resta in sospeso finché le informazioni non vengono fornite.
Perché è importante Il frequente ricorso a questa attività può indicare problemi nella qualità dei dati iniziali forniti per lo screening. L’attività causa ritardi significativi perché dipende da team esterni ed è una delle principali cause di tempi di ciclo lunghi. Dove reperirli Può trattarsi di un’azione esplicita dell’utente, registrata nelle note del caso o nel registro di audit. In alternativa, si può dedurre dal passaggio dello stato del caso a «Informazioni in attesa» o «Richiesta di informazioni». Acquisizione Registrato quando un analista utilizza la funzione per segnalare che il caso richiede ulteriori informazioni. Tipo di evento explicit
	Potenziale corrispondenza individuata	Il processo di screening automatizzato ha individuato una o più potenziali corrispondenze che richiedono la revisione manuale di un analista. A questo punto il caso passa dallo stato automatizzato alla coda delle verifiche manuali.
Perché è importante Questa attività è un punto di diramazione cruciale del processo. I casi con potenziali corrispondenze seguono un percorso più lungo e complesso; monitorarli aiuta a pianificare le risorse e ad analizzare i colli di bottiglia nel team di revisione. Dove reperirli Si deduce dal passaggio dello stato del caso a «Revisione necessaria», «Potenziale corrispondenza» o a uno stato analogo nel modulo di gestione dei casi di World-Check. Acquisizione Si ricava da una modifica dello stato del caso che indica la necessità di una revisione manuale. Tipo di evento inferred
	Screening automatizzato eseguito	Il sistema World-Check confronta automaticamente i dati del cliente con il proprio database di informazioni sui rischi. Questa attività, eseguita dal sistema, genera un primo insieme di risultati, ad esempio potenziali corrispondenze o un esito senza corrispondenze.
Perché è importante Questa attività è il primo passaggio del processo di screening che genera valore. I ritardi che la precedono possono indicare problemi di disponibilità del sistema o dei dati, mentre il risultato determina il successivo carico di lavoro manuale. Dove reperirli L’evento può essere registrato esplicitamente nel registro di audit del caso oppure dedotto dalla marca temporale in cui i risultati iniziali dello screening diventano disponibili. Acquisizione Voce del registro di sistema generata al termine della scansione automatizzata del database. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da World-Check di Refinitiv

Passaggi

Acceda a World-Check One: acceda al portale Refinitiv World-Check One con le Sue credenziali.
Apra la gestione dei casi: acceda alla sezione di gestione dei casi, dove vengono archiviati e gestiti tutti i casi di screening.
Prepari l’esportazione del report dei casi: apra la funzione di report o esportazione nella sezione di gestione dei casi. Potrebbe chiamarsi «Esporta casi» o «Report dei casi».
Configuri il report dei casi: selezioni le colonne da includere nell’esportazione. Includa i campi corrispondenti all’ID del caso (CustomerApplication), alla data di creazione, alla data di risoluzione, allo stato del caso, ad esempio «Nessuna corrispondenza» o «Corrispondenza rilevata», e al livello di rischio.
Esporti i dati di gestione dei casi: definisca l’intervallo di date, che in genere copre gli ultimi 3-6 mesi di attività. Applichi gli eventuali filtri necessari, ad esempio per gruppo di utenti o tipo di caso. Esporti i dati in formato CSV e assegni al file il nome case_report.csv.
Prepari l’esportazione del registro di audit: acceda alla sezione del registro o del report di audit di World-Check One. Qui sono disponibili le cronologie dettagliate degli eventi per ciascun caso.
Configuri ed esporti il registro di audit: selezioni tutte le colonne pertinenti, tra cui l’ID del caso, il nome o la descrizione dell’evento, la data e l’ora dell’evento e l’utente che ha eseguito l’azione. Esporti i dati per lo stesso intervallo di date del report dei casi e salvi il file come audit_trail.csv.
Recuperi i passaggi del processo esterni: acquisisca i dati delle attività che si svolgono al di fuori di World-Check, come Application Submitted, Application Approved, Account Activated e Application Rejected. In genere, questi dati provengono da un CRM o da un sistema bancario centrale. Li esporti includendo l’ID CustomerApplication e le date e ore pertinenti.
Combini e trasformi i dati: carichi i file CSV esportati (case_report.csv, audit_trail.csv e i dati del sistema esterno) in uno strumento o script di preparazione dei dati.
Mappi gli eventi di audit alle attività: elabori il file audit_trail.csv e associ le descrizioni originali degli eventi del registro di audit ai valori standardizzati di ActivityName. Ad esempio, una voce come «Caso assegnato all’analista» diventa «Revisione dell’analista avviata».
Mappi le variazioni dello stato del caso alle attività: elabori il file case_report.csv per generare attività in base alle variazioni di stato. Utilizzi la data di risoluzione e lo stato finale del caso per creare gli eventi «Screening completato: nessuna corrispondenza» o «Screening completato: corrispondenza rilevata».
Crei l’Event Log finale: unisca in un unico file CSV tutti i dati elaborati provenienti dai diversi file di origine. Verifichi che il file finale contenga le colonne obbligatorie CustomerApplication, ActivityName ed EventTime, oltre agli eventuali attributi consigliati. Salvi il file per caricarlo nello strumento di Process Mining.

Configurazione

Tipi di report: dovrà generare almeno due report distinti: un report riepilogativo della gestione dei casi e un report dettagliato del registro di audit.
Intervallo di date: per un’analisi iniziale, selezioni un intervallo di almeno 3-6 mesi, così da includere un numero sufficiente di casi completati e in corso. Verifichi che l’intervallo di date sia lo stesso per tutti i file esportati.
Formato di esportazione: scelga CSV (valori separati da virgole), un formato facile da elaborare.
Colonne principali (report dei casi): verifichi che l’esportazione dei casi includa l’ID del caso, la data e l’ora di creazione, la data e l’ora di risoluzione, lo stato finale, l’analista assegnato e il livello di rischio.
Colonne principali (report del registro di audit): verifichi che l’esportazione del registro di audit includa l’ID del caso, la descrizione dell’evento, la data e l’ora dell’evento e l’ID utente.
Prerequisiti: è necessario poter accedere al portale World-Check One con autorizzazioni che consentano di visualizzare ed esportare i dati di gestione dei casi e del registro di audit. Potrebbero essere necessari privilegi superiori a quelli previsti per il ruolo standard di analista.

a Query di esempio sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Passaggi

Prerequisiti e configurazione: verifichi di avere installato Python 3.6 o versione successiva, insieme alle librerie requests e pandas. Richieda al referente Refinitiv o al portale per sviluppatori la chiave API e il segreto API di World-Check One. Conservi queste credenziali in modo sicuro.
Sviluppi la logica di autenticazione: nello script Python, crei una funzione che invii una richiesta POST all’endpoint di autenticazione di World-Check One. Utilizzi la chiave API e il segreto per ottenere un token bearer temporaneo, necessario per le successive chiamate API.
Individui i dati del sistema di origine: il processo inizia e termina al di fuori di World-Check. Individui il sistema di origine, ad esempio un CRM o una piattaforma bancaria centrale, in cui sono archiviati i dati iniziali delle richieste. Dovrà estrarre da questo sistema eventi come Application Submitted, Application Approved, Account Activated e Application Rejected. Può farlo tramite una query al database o un’altra API.
Recuperi i casi World-Check: utilizzando il token di autenticazione, invii una richiesta GET all’endpoint /cases dell’API World-Check One. Utilizzi i parametri di query per filtrare i casi in base a un intervallo di date specifico, ad esempio la data di creazione o di modifica.
Gestisca la paginazione dell’API: le risposte dell’API World-Check sono suddivise in pagine. Lo script deve verificare i dettagli di paginazione nella risposta e scorrere tutte le pagine per recuperare l’elenco completo dei casi nell’intervallo di date specificato.
Recuperi i dettagli e la cronologia dei casi: per ogni ID caso recuperato, invii ulteriori richieste GET a endpoint come /cases/{case_system_id} e /cases/{case_system_id}/audit-trail. Questi endpoint forniscono informazioni dettagliate sulle variazioni di stato, i dettagli della risoluzione e le azioni degli utenti associate al caso.
Mappi i dati originali alle attività: questa è una fase di trasformazione fondamentale. Scriva una logica che esamini i dati della risposta API, inclusi i dettagli del caso e il registro di audit, per ciascun caso. Mappi le variazioni di stato, i codici dei risultati e gli eventi di audit specifici alle attività aziendali richieste. Ad esempio, un evento di creazione del caso diventa Screening Request Created, mentre la risoluzione con esito False Positive diventa False Positive Confirmed.
Combini le fonti di dati: unisca i dati estratti da World-Check a quelli del sistema di origine, recuperati al passaggio 3. Utilizzi l’ID CustomerApplication come chiave comune per creare un Event Log completo, dall’inizio alla fine, per ogni cliente.
Strutturi e arricchisca i dati: raccolga tutti gli eventi mappati in un unico elenco di record. Verifichi che ogni record contenga tutti gli attributi obbligatori (CustomerApplication, ActivityName, EventTime) e quelli consigliati. Se possibile, calcoli EventEndTime, ad esempio utilizzando la data e l’ora dell’evento successivo per quel caso.
Esporti in CSV: converta l’elenco finale dei record degli eventi in un DataFrame pandas. Riordini le colonne secondo il formato richiesto ed esporti il DataFrame in un file CSV. Verifichi che il file sia salvato con codifica UTF-8, per garantirne la compatibilità con ProcessMind.

Configurazione

Credenziali API: sono necessarie una chiave API e un segreto API validi per l’API di screening World-Check One. Devono disporre delle autorizzazioni necessarie per leggere i dati dei casi e del registro di audit.
URL di base dell’API: lo script deve essere configurato con l’URL di base corretto per l’ambiente dell’API World-Check, ad esempio https://api.world-check.com/v2/.
Intervallo di date: inserisca nello script i parametri start_date ed end_date per definire il periodo di estrazione. Per l’analisi iniziale si consiglia un intervallo da 3 a 6 mesi. Per il monitoraggio continuativo, esegua lo script in modo incrementale su periodi più brevi, ad esempio il giorno o la settimana precedenti.
Connessione al sistema di origine: per recuperare gli eventi non relativi allo screening, sono necessari i dettagli di connessione ai sistemi a monte e a valle, ad esempio il CRM o la piattaforma bancaria centrale. Potrebbe trattarsi di una stringa di connessione al database o di un endpoint API con le relative credenziali.
Gestione della paginazione: quando richiede l’elenco dei casi tramite API, lo script deve specificare la dimensione della pagina, spesso indicata come limit. In genere, un valore compreso tra 50 e 100 è efficiente. La logica deve recuperare correttamente tutte le pagine.

a Query di esempio python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

È pronto a iniziare?

Utilizzi questo template dei dati per avviare il percorso di Process Mining dedicato all’onboarding KYC dei clienti. Seguendo queste indicazioni, potrà ottenere informazioni utili e migliorare in modo significativo le attività.

Torna alla guida al miglioramento Scarica il template

Ottimizzi subito l’onboarding KYC dei clienti e rafforzi la conformità

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

Inizi la prova gratuita

Non è richiesta la carta di credito. Provi il servizio gratuitamente per 14 giorni.

Il template dei dati per l’onboarding KYC dei clienti

Il template dei dati per l’onboarding KYC dei clienti

Attributi per l’onboarding KYC dei clienti

Attività di onboarding KYC dei clienti

Guide all’estrazione

Esportazione dei casi e del registro di audit di Refinitiv World-Check One

Passaggi

Configurazione

a Query di esempio sql

Script Python con l’API di screening World-Check One

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi subito l’onboarding KYC dei clienti e rafforzi la conformità

Il template dei dati per l’onboarding KYC dei clienti

Il template dei dati per l’onboarding KYC dei clienti

Attributi per l’onboarding KYC dei clienti

Attività di onboarding KYC dei clienti

Guide all’estrazione

Esportazione dei casi e del registro di audit di Refinitiv World-Check One

Passaggi

Configurazione

a Query di esempio sql

Script Python con l’API di screening World-Check One

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi subito l’onboarding KYC dei clienti e rafforzi la conformità

La Sua privacy è importante