> Miglioramento Continuo dei Processi > KYC Customer Onboarding > Refinitiv World Check > Template Dati

Il Suo Template Dati di Onboarding Clienti KYC

Refinitiv World-Check

Attributi del KYC Customer Onboarding (20) KYC Customer Onboarding Activities (14) Guide all'Estrazione (2)

Il Suo Template Dati di Onboarding Clienti KYC

Questo `template` La guida nella raccolta dei `data` essenziali per analizzare il Suo processo di `KYC Customer Onboarding`. Delinea gli `attribute` cruciali da acquisire, le `activity` chiave da tracciare e fornisce indicazioni su come estrarre queste informazioni dai Suoi sistemi di origine. Utilizzi questa risorsa per assicurarsi di avere tutti i `data` necessari per un'efficace analisi e miglioramento del processo.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

Attributi del KYC Customer Onboarding

Questi sono i `data fields` raccomandati da includere nel Suo `event log` per un'analisi completa del `KYC Customer Onboarding`.

3 Obbligatorio 5 Consigliato 12 Facoltativo

	Nome	Descrizione
	Nome attività ActivityName	Il nome di uno specifico `event` o `task` aziendale che si è verificato all'interno del processo di `onboarding KYC`.
Descrizione L'`Activity` Name descrive un singolo passaggio o `event` nel percorso di `onboarding` del cliente, come 'Domanda Presentata', 'Revisione dell'`Analyst` Avviata' o 'Screening Completato - Approvato'. Queste `activity` formano i nodi della mappa di processo, fornendo una ripartizione dettagliata del `workflow` end-to-end. Analizzare le `activity` è il cuore del `Process Mining`. Tracciando la sequenza e la frequenza delle diverse `activity`, gli `analyst` possono scoprire il flusso di processo effettivo, identificare percorsi comuni, rilevare deviazioni dalla procedura standard e individuare passaggi specifici che causano ritardi o rilavorazioni. Questo `attribute` è cruciale per la costruzione di mappe di processo e il calcolo delle `metrics` a livello di `activity`. Perché è importante Questo `attribute` definisce i singoli passaggi del processo, il che è essenziale per scoprire e visualizzare il flusso del processo e identificare i `bottleneck`. Dove trovare Questa informazione si trova tipicamente negli `event logs` o nelle tabelle della traccia di audit, spesso associata a cambiamenti di stato nell'entità di gestione del `case`. Esempi Potenziale Corrispondenza IdentificataRevisione Analista IniziataFalso Positivo ConfermatoRichiesta Approvata
	Richiesta Cliente CustomerApplication	L'identificatore unico per l'applicazione di `onboarding` di un singolo cliente, che funge da identificatore primario del `case`.
Descrizione La Domanda Cliente è l'identificatore centrale del `case` che raggruppa tutti gli `event` e le `activity` relative al percorso di `onboarding` di un singolo cliente. Consente il tracciamento completo e cronologico del progresso di ogni cliente attraverso l'intero processo `Know Your Customer` (`KYC`), dalla presentazione iniziale alla decisione finale. Nell'analisi di `Process Mining`, questo `attribute` è fondamentale per ricostruire il percorso end-to-end di ogni applicazione. Consente la visualizzazione dei flussi di processo, il calcolo dei tempi di ciclo totali e l'identificazione delle varianti. Analizzando i `case` raggruppati da questo identificatore, le organizzazioni possono comprendere i diversi percorsi che un'applicazione può intraprendere, identificare i `bottleneck` e confrontare l'efficienza dei vari processi di `onboarding`. Perché è importante Questo è l'identificatore `case` essenziale che collega tutte le `activity` correlate, rendendo possibile analizzare il processo di `onboarding` del cliente end-to-end. Dove trovare Questo identificatore è tipicamente la chiave primaria nella tabella principale dell'applicazione o di gestione dei `case` all'interno del sistema `Refinitiv World-Check` o di un `CRM` integrato. Esempi APP-2023-00123APP-2023-00124APP-2023-00125
	Timestamp Evento EventTime	Il timestamp che indica quando una specifica attività o un evento si è verificato.
Descrizione Event Time fornisce la data e l'ora precise in cui un'attività è stata registrata. Questo timestamp è la spina dorsale cronologica del processo, consentendo di ordinare correttamente gli eventi per ricostruire la cronologia del caso. Questo attributo è fondamentale per tutte le analisi basate sul tempo nel Process Mining. Viene utilizzato per calcolare le durate tra le attività (tempi di ciclo e tempi di attesa), misurare la durata complessiva del caso, analizzare le prestazioni del processo nel tempo e verificare la conformità agli Accordi sul Livello di Servizio (SLA). Senza timestamp accurati, è impossibile comprendere le prestazioni del processo e identificare i colli di bottiglia temporali. Perché è importante Il `timestamp` per ogni `activity` è essenziale per calcolare tutte le `metrics` basate sulla durata, scoprire la sequenza del processo ed eseguire l'analisi dei `bottleneck`. Dove trovare Questo è un campo standard in qualsiasi `event log` o tabella della traccia di audit, spesso chiamato '`Timestamp`', '`EventDate`' o '`CreationDate`'. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Data Obiettivo SLA SlaTargetDate	La data obiettivo entro la quale il processo di `onboarding` del cliente dovrebbe essere completato.
Descrizione La Data Obiettivo `SLA` è la scadenza per il completamento dell'intero `onboarding case`, come definito dall'accordo sul livello di servizio con il cliente o dalle politiche interne. Questa data è il benchmark rispetto al quale vengono misurati i tempi di completamento effettivi. Questo `attribute` è fondamentale per la `dashboard` 'Analisi di Aderenza e Violazione `SLA`'. Viene utilizzato per calcolare se un `case` è stato completato in tempo o meno. L'analisi delle violazioni `SLA` aiuta a identificare problemi sistemici nel processo che causano ritardi e consente all'organizzazione di intraprendere azioni correttive per migliorare la tempestività e soddisfare i requisiti di `conformità`. Perché è importante Questo è il benchmark per misurare le prestazioni in tempo e cruciale per calcolare il tasso di aderenza agli `SLA` e analizzare le violazioni. Dove trovare Questa data è spesso calcolata in base alla data di presentazione dell'applicazione e alle regole aziendali. Può essere archiviata come campo nel record del `case`. Esempi 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Dipartimento DepartmentName	Il dipartimento o il team funzionale responsabile dell'esecuzione dell'`activity`.
Descrizione Questo `attribute` specifica l'unità aziendale o il team, come 'Onboarding', 'Conformità' o 'Controllo Qualità', a cui l'utente appartiene. Consente un'analisi a un livello organizzativo superiore rispetto al singolo utente. L'analisi per dipartimento è critica per identificare i `bottleneck` interdipartimentali e misurare i tempi di passaggio. Aiuta a visualizzare come il lavoro fluisce tra i diversi team e dove si verificano ritardi in queste transizioni. Questa visione è inestimabile per snellire la collaborazione interfunzionale e migliorare l'efficienza complessiva del processo. Perché è importante Consente l'analisi delle prestazioni del processo per dipartimento ed è essenziale per identificare i ritardi nei trasferimenti tra i diversi team. Dove trovare Questa informazione può essere archiviata con il profilo dell'utente nel sistema o in un sistema `HR` associato. Potrebbe essere necessario unirla con gli `event data` utilizzando l'ID utente. Esempi Team di OnboardingRevisione di ConformitàDirezione Superiore
	Livello di Rischio RiskLevel	La classificazione del rischio calcolata dell'applicazione del cliente, come Basso, Medio o Alto.
Descrizione Il Livello di Rischio è un'informazione critica nei processi `KYC`, che determina il livello di `due diligence` richiesto. È spesso determinato in base a fattori come il tipo di cliente, la geografia e la natura della loro attività. Questa classificazione può influenzare significativamente il percorso di processo che un'applicazione intraprende. Nell'analisi dei processi, la segmentazione dei `case` per Livello di Rischio è essenziale. Aiuta a spiegare le variazioni nei tempi di ciclo e nei flussi di processo; ad esempio, le applicazioni ad alto rischio possono richiedere più passaggi e più tempo. Questo `attribute` è fondamentale per le `dashboard` 'Tasso di Rifiuto dell'Applicazione e Motivi' e 'Tempo di Ciclo di Avvio del Controllo in Background' per comprendere come il rischio influisce sui risultati e sull'efficienza. Perché è importante Segmentare il processo per livello di rischio è cruciale per comprendere perché certi `case` richiedono più tempo o seguono percorsi diversi, e per analizzare i tassi di rifiuto. Dove trovare Questo è un punto `data` `core` sul record dell'applicazione cliente o del `case`. Consultare il modulo di gestione dei `case` in `Refinitiv World-Check`. Esempi BassoMedioElevato
	Ora Fine Evento EventEndTime	Il timestamp che indica quando una specifica attività o un evento è stato completato.
Descrizione L'`Event End Time` segna il completamento di un'`activity`. Mentre molti `event` possono essere modellati come istantanei (dove `StartTime` è uguale a `EndTime`), alcune `activity` hanno una durata misurabile, come 'Revisione dell'`Analyst` Avviata' e 'Revisione dell'`Analyst` Completata'. Avere sia i tempi di inizio che di fine consente una misurazione precisa del tempo di elaborazione. Nell'analisi dei processi, avere un tempo di fine è vitale per calcolare il tempo di elaborazione esatto di un'`activity`, a differenza del tempo di ciclo che include il tempo di attesa. Questo aiuta a distinguere tra il tempo che un `case` trascorre lavorando attivamente e il tempo in cui rimane inattivo in una coda. Questo è fondamentale per l'ottimizzazione delle risorse e l'analisi dell'efficienza. Perché è importante Consente il calcolo preciso del tempo di elaborazione delle attività, separando il tempo di lavoro attivo dal tempo di attesa inattivo per un'analisi delle prestazioni più accurata. Dove trovare Per le attività con una durata, questo potrebbe essere memorizzato in un campo separato come 'CompletionDate' o 'EndDate' nelle tabelle del log degli eventi o della traccia di audit. Esempi 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Reviewer ID ReviewerId	L'identificatore dell'utente, dell'`analyst` o dell'agente automatizzato che ha eseguito l'`activity`.
Descrizione Il `Reviewer ID`, o utente, indica chi ha eseguito un particolare `task` nel processo `KYC`. Questo potrebbe essere un `compliance analyst`, uno specialista di `onboarding`, o un account di sistema per `activity` automatizzate. Tracciare queste informazioni fornisce visibilità sulla distribuzione del carico di lavoro e sulle prestazioni individuali. Questo `attribute` è essenziale per l'analisi basata sulle risorse. Aiuta a comprendere le differenze di prestazioni tra utenti o team, identificando le esigenze di formazione e ottimizzando il bilanciamento del carico di lavoro. È anche un componente chiave per l'analisi dei passaggi di consegna, delle reti sociali e dell'utilizzo delle risorse di `conformità`. Perché è importante Consente l'analisi della distribuzione del carico di lavoro, delle prestazioni degli utenti e dei trasferimenti tra dipartimenti, il che è cruciale per l'ottimizzazione delle risorse. Dove trovare Tipicamente presente nei log degli eventi o nei registri di controllo, spesso denominato 'UserID', 'PerformedBy' o 'Owner'. Esempi analyst_jdoesystem_auto_screenermanager_bsmith
	Canale della Richiesta ApplicationChannel	Il canale attraverso il quale è stata presentata la domanda del cliente, come Portale Online, In Filiale o App Mobile.
Descrizione Il Canale di Applicazione indica la fonte di presentazione della domanda del cliente. Canali diversi possono avere livelli variabili di completezza dei `data`, qualità e dati demografici dei clienti, il che può influenzare il processo a valle. Questo `attribute` è essenziale per la `dashboard` 'Produttività delle Applicazioni per Canale'. Analizzando il volume, il tempo di ciclo e i risultati delle applicazioni da diversi canali, un'organizzazione può identificare quali canali sono più efficienti e quali potrebbero richiedere miglioramenti di processo. Questa analisi supporta le decisioni strategiche sull'allocazione delle risorse e l'investimento nei canali. Perché è importante Aiuta ad analizzare le prestazioni e l'efficienza dei diversi canali di presentazione, fornendo informazioni per decisioni strategiche sulla tecnologia e l'esperienza del cliente. Dove trovare Questa informazione è tipicamente acquisita all'inizio del processo e archiviata come `attribute` nel record dell'applicazione. Esempi Portale OnlineApp MobileIn FilialeRelationship Manager
	È Automatizzato IsAutomated	Un flag che indica se l'attività è stata eseguita da un sistema (true) o da un essere umano (false).
Descrizione Questo `boolean attribute` distingue tra `task` di sistema automatizzati e `activity` manuali eseguite dagli utenti. Ad esempio, 'Screening Automatizzato Eseguito' sarebbe contrassegnato come automatizzato, mentre 'Revisione dell'`Analyst` Avviata' sarebbe manuale. Questa distinzione è cruciale per l'analisi dell'automazione. Aiuta a misurare l'impatto dell'automazione sull'efficienza del processo, identificare quali `task` manuali sono candidati per future automazioni e comprendere l'interazione tra attori umani e di sistema. Consente una chiara separazione del tempo di elaborazione del sistema dal tempo di gestione manuale. Perché è importante Differenzia tra attività di sistema e umane, il che è fondamentale per misurare l'impatto dell'automazione e identificare nuove opportunità di automazione. Dove trovare Questo è tipicamente derivato in base al nome dell'`activity` o all'ID utente associato all'`event` (ad es., se l'utente è un account 'di sistema'). Esempi truefalse
	È una Rilavorazione IsRework	Un flag che indica se un'attività viene eseguita per una seconda o successiva volta all'interno dello stesso caso.
Descrizione `IsRework` è un `boolean attribute` calcolato che identifica quando un'`activity` viene ripetuta all'interno dello stesso `case` di domanda cliente. Ad esempio, se 'Valutazione del Rischio Eseguita' si verifica più di una volta per una singola applicazione, le occorrenze successive vengono contrassegnate come rilavorazione. Questo `attribute` è fondamentale per identificare inefficienze di processo, `loop` e ripetizioni non necessarie. Supporta direttamente la `dashboard` 'Rilavorazione e Efficienza della Valutazione del Rischio' e il `KPI` 'Tasso di Rilavorazione della Valutazione del Rischio'. L'analisi della rilavorazione aiuta a scoprire problemi di qualità, chiarezza delle informazioni o processo decisionale, che portano a sprechi di sforzi e tempi di ciclo più lunghi. Perché è importante Evidenzia le inefficienze di processo segnalando `activity` ripetute, consentendo l'analisi dei cicli di rilavorazione per migliorare la qualità e ridurre i tempi di ciclo. Dove trovare Questo viene calcolato durante la `data transformation` analizzando la sequenza di `activity` all'interno di ogni `case` e contrassegnando eventuali occorrenze non iniziali di un'`activity`. Esempi truefalse
	ID Cliente CustomerId	Un identificatore unico per l'entità cliente in fase di onboarding.
Descrizione Il `Customer ID` è l'identificatore unico per il profilo del cliente. Questo è distinto dal `Customer Application ID`, poiché un cliente può presentare più applicazioni nel tempo. Questo `attribute` collega il processo di `onboarding` al record principale del cliente. Nell'analisi, il `Customer ID` consente di tracciare le domande ripetute dello stesso cliente e può essere utilizzato per arricchire i `data` di processo con altri `attribute` del cliente da un `CRM` o da un sistema di `master data`. Ciò consente una visione più olistica del percorso del cliente oltre una singola istanza di `onboarding`. Perché è importante Collega il `case` di `onboarding` a un cliente specifico, consentendo l'analisi delle domande ripetute e l'arricchimento con i `data` anagrafici del cliente. Dove trovare Questo sarebbe un campo chiave sul record dell'applicazione o del caso, che lo collega ai dati anagrafici del cliente. Esempi CUST-98765CUST-98766CUST-98767
	Match ID MatchId	L'identificatore unico per una potenziale corrispondenza trovata durante uno screening `World-Check`.
Descrizione Quando il processo di screening automatizzato rileva una potenziale corrispondenza con liste di sanzioni, liste PEP o media avversi, viene spesso generato un ID Corrispondenza per tracciare il ritrovamento specifico. Questo ID collega il caso dell'applicazione al record specifico nel database World-Check che ha attivato l'avviso. Questo attributo è utile per un'analisi dettagliata della conformità. Permette agli analisti di indagare la natura delle corrispondenze, tracciare la risoluzione di avvisi specifici (ad esempio, confermando un falso positivo o una corrispondenza reale) e comprendere quali tipi di avvisi sono più comuni o richiedono più tempo per essere risolti. Fornisce un livello di dettaglio più profondo nell'attività 'Potenziale Corrispondenza Identificata'. Perché è importante Fornisce un link granulare ai risultati specifici dello screening, consentendo un'analisi più approfondita dei tempi di risoluzione delle corrispondenze e dei tipi di avvisi. Dove trovare Questo ID sarebbe generato dal motore di screening di `World-Check` e registrato nel `case` dell'applicazione quando viene trovata una potenziale corrispondenza. Esempi WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Motivo del Rigetto RejectionReason	Il motivo specifico fornito quando una domanda cliente viene respinta.
Descrizione Quando una richiesta viene rifiutata, la Causa di Rifiuto indica il motivo di tale decisione. Le ragioni possono includere 'Corrispondenza Sanzioni', 'Documentazione Incompleta' o 'Profilo ad Alto Rischio'. Ciò fornisce un feedback prezioso e strutturato sulla qualità delle richieste in arrivo e sull'efficacia del processo di screening. Questo attributo è il driver principale per la dashboard 'Tasso e Cause di Rifiuto delle Richieste'. L'analisi di queste ragioni aiuta a identificare le cause profonde dei rifiuti, che possono portare a miglioramenti del processo, una comunicazione più chiara con i richiedenti e potenzialmente una riduzione dei rifiuti non necessari. Fornisce un contesto qualitativo al KPI quantitativo del tasso di rifiuto. Perché è importante Fornisce la causa principale dei rifiuti di applicazione, il che è essenziale per identificare le aree da migliorare nel processo di `onboarding` per ridurre il tasso di rifiuto. Dove trovare Questo verrebbe registrato quando si verifica l'evento 'Richiesta Rifiutata', probabilmente come campo sul record del caso o della richiesta. Esempi Corrispondenza PEPCorrispondenza Lista SanzioniVerifica Documenti FallitaMedia Avversa
	Paese Cliente CustomerCountry	Il paese di residenza o costituzione per il cliente.
Descrizione Questo `attribute` indica la posizione geografica del cliente. Il paese è un fattore significativo nella valutazione del rischio e nei requisiti normativi per i processi `KYC`. Diverse giurisdizioni hanno regole diverse, che possono influenzare il flusso e la durata del processo. Analizzare il processo per paese consente alle organizzazioni di confrontare le prestazioni tra diverse regioni, identificare i `bottleneck` specifici della località e garantire la `conformità` con le normative locali. Fornisce una dimensione geografica all'analisi del processo, che può rivelare importanti differenze operative. Perché è importante Consente l'analisi geografica del processo, aiutando a identificare le variazioni regionali in termini di prestazioni, rischio e requisiti di conformità. Dove trovare Questo è un campo standard sul profilo del cliente o sul modulo di domanda. Esempi Stati UnitiGBRSGPDEU
	Sistema di Origine SourceSystem	Il sistema da cui sono stati estratti gli `event data`, in questo `case`, `Refinitiv World-Check`.
Descrizione Questo `attribute` identifica l'origine dei `data` di processo. Sebbene possa essere un valore costante in un'estrazione da singola fonte, diventa cruciale quando i `data` da più sistemi (come un `CRM` e `World-Check`) vengono combinati per creare una visione olistica del processo. Nell'analisi, questo aiuta nella `data governance`, nel `troubleshooting` e nella comprensione del contesto dei `data`. Ad esempio, le `activity` registrate in un sistema di screening `core` possono avere proprietà o livelli di dettaglio diversi rispetto a quelli di un sistema periferico. Assicura che la `data lineage` sia chiara e auditabile. Perché è importante Identifica l'origine dei `data`, il che è cruciale per la `data governance`, la validazione e l'unione di `data` provenienti da più fonti. Dove trovare Questo è spesso un valore statico aggiunto durante il processo di `data extraction`, `transformation` e `loading` (`ETL`) per etichettare il `dataset`. Esempi Refinitiv World-CheckWorldCheckOne
	SLA Violato SlaBreached	Un flag booleano che indica se il caso di onboarding è stato completato dopo la Data Obiettivo SLA.
Descrizione Questo `attribute` è un `flag` calcolato che indica se un `case` ha violato il suo `Service Level Agreement`. È determinato confrontando il `timestamp` dell'`activity` di completamento finale (ad es. 'Applicazione Approvata' o 'Applicazione Rifiutata') con il '`SlaTargetDate`' per il `case`. Questo `flag` è la base per la `dashboard` 'Analisi di Aderenza e Violazione `SLA`' e il `KPI` 'Tasso di Aderenza `SLA`'. Semplifica l'analisi consentendo agli utenti di filtrare rapidamente tutti i `case` violati. Analizzando le caratteristiche del processo dei `case` violati, le organizzazioni possono identificare le cause profonde dei ritardi e concentrare efficacemente gli sforzi di miglioramento. Perché è importante Misura direttamente la conformità agli accordi sul livello di servizio, consentendo una facile filtrazione e analisi della causa principale dei casi ritardati. Dove trovare Questo viene calcolato durante la `data transformation` confrontando il `timestamp` dell'`activity` finale per un `case` con il campo `SlaTargetDate`. Esempi truefalse
	Tempo di Elaborazione Attività ActivityProcessingTime	La durata del tempo trascorso lavorando attivamente su un'attività.
Descrizione Questa `metric` calcola il tempo effettivo impiegato per completare un'`activity`, dal suo inizio alla sua fine. È calcolata come la differenza tra l'`EventEndTime` e l'`EventTime`. Questo misura il 'tempo di contatto' o il tempo di lavoro attivo per un `task`. Questo `attribute` calcolato è essenziale per l'analisi delle prestazioni ed è utilizzato in molti `KPI`, inclusi 'Tempo di Ciclo Medio di Revisione Documentale' e 'Tempo di Ciclo Medio di Revisione di `Conformità`'. Aiuta a distinguere tra il tempo in cui un `task` viene elaborato attivamente e il tempo in cui è in attesa in una coda. Questo è fondamentale per identificare le vere inefficienze di elaborazione e per la pianificazione della capacità. Perché è importante Misura il tempo di lavoro effettivo per un'`activity`, aiutando a individuare quali `task` specifici richiedono più tempo per essere completati, separatamente dal tempo di attesa. Dove trovare Questo viene calcolato durante la `data transformation` sottraendo il `timestamp` di inizio dal `timestamp` di fine di un'`activity` (ad es., `EndTime` - `StartTime`). Esempi PT1H30MP2DT4H15MPT25M
	Tipo cliente CustomerType	La classificazione del cliente, come Individuale, Azienda o Trust.
Descrizione Il Tipo di Cliente categorizza l'entità in fase di onboarding. Diversi tipi di clienti hanno spesso requisiti di onboarding, profili di rischio e obblighi normativi diversi. Ad esempio, l'onboarding di un'azienda è tipicamente più complesso di quello di un individuo. Questo attributo viene utilizzato per l'analisi di segmentazione, in particolare per la dashboard 'Performance per Tipo di Cliente KYC'. Consente di confrontare l'efficienza del processo, i tempi di ciclo e i tassi di rifiuto tra diversi segmenti di clientela. Questo aiuta le organizzazioni a personalizzare e ottimizzare l'esperienza di onboarding per specifici tipi di clienti. Perché è importante Consente il confronto delle prestazioni tra diversi segmenti di clientela, aiutando a personalizzare e ottimizzare il processo di onboarding per ogni tipo. Dove trovare Questo è un `attribute` fondamentale archiviato nel record del cliente o dell'applicazione all'interno del sistema di origine. Esempi IndividualeAziendaNon-ProfitFiducia
	Ultimo `Data Update` LastDataUpdate	Il `timestamp` di quando i `data` per questo `event` sono stati aggiornati o estratti l'ultima volta dal sistema di origine.
Descrizione Questo `attribute` indica la freschezza dei `data`. Registra la data e l'ora dell'ultimo prelievo di `data` da `Refinitiv World-Check`. Questo è importante per comprendere la tempestività delle `dashboard` e delle analisi di `Process Mining`. Ai fini analitici, questo consente agli utenti di sapere se stanno visualizzando `data` quasi in tempo reale o uno snapshot da un momento specifico. È essenziale per la `data governance` e per la gestione delle aspettative degli utenti riguardo all'attualità degli `insights` forniti. Perché è importante Fornisce un contesto cruciale sulla freschezza dei `data`, assicurando che gli utenti comprendano quanto sia aggiornata l'analisi del processo. Dove trovare Questo `timestamp` è generato e aggiunto durante il processo di `data extraction` (`ETL`). Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z

Obbligatorio Consigliato Facoltativo

KYC Customer Onboarding Activities

Questi sono i `passi di processo` e le `milestone` chiave da catturare nel suo `Event Log` per una `scoperta dei processi` accurata.

8 Consigliato 6 Facoltativo

	Activity	Descrizione
	Account Attivato	L'account del cliente viene creato e attivato nel sistema centrale, completando il percorso di `onboarding`. Questo segue l'approvazione finale dell'applicazione e rende l'account pronto per l'uso.
Perché è importante Questo è il passaggio finale che genera valore nel processo. La durata dalla presentazione della domanda all'attivazione dell'account è una `metric` chiave per l'efficienza operativa e la soddisfazione del cliente. Dove trovare Questo `event` non viene acquisito in `World-Check`. È registrato nel sistema bancario `core` o nel sistema di account cliente e deve essere correlato tramite il `Customer Application ID`. Acquisisci Evento registrato nel sistema account principale al momento dell'attivazione dell'account. Tipo di evento explicit
	Corrispondenza Reale Confermata	Un analista conferma che una potenziale corrispondenza è effettivamente il cliente sottoposto a screening, identificando un potenziale rischio. Questo è un momento cruciale che tipicamente innesca ulteriori verifiche di due diligence o il rifiuto della richiesta.
Perché è importante Questo è un risultato chiave per la mitigazione del rischio e un momento cruciale nel processo. Influisce direttamente sulla decisione finale relativa all'applicazione del cliente ed è cruciale per la rendicontazione e l'analisi della `conformità`. Dove trovare Questa è un'`action` utente esplicita in cui l'`analyst` dispone una specifica corrispondenza come 'Vera Corrispondenza' o 'Corrispondenza Confermata'. Questo `event` viene registrato nella traccia di audit del `case`. Acquisisci Registrato quando un `analyst` conferma formalmente una corrispondenza nel sistema. Tipo di evento explicit
	Domanda Inviata	Questa `activity` segna l'inizio del processo di `onboarding KYC` quando un cliente presenta la propria domanda. Questo `event` è tipicamente acquisito in un `CRM` o in un sistema di applicazioni `core`, che poi innesca il processo di screening in `Refinitiv World-Check`.
Perché è importante Questo è l'`event` di inizio primario per il percorso di `onboarding` del cliente end-to-end. L'analisi del tempo da questo punto al completamento fornisce il tempo di ciclo complessivo dell'`onboarding`, che è fondamentale per misurare l'esperienza del cliente e l'aderenza agli `SLA`. Dove trovare Questo `event` non è nativo di `World-Check`. Deve essere ottenuto da un sistema a monte, come un `CRM` o una piattaforma di gestione degli account clienti, e correlato tramite il `Customer Application ID`. Acquisisci Evento registrato nel sistema applicativo sorgente al momento dell'invio iniziale. Tipo di evento explicit
	Revisione Analista Iniziata	Un analista di conformità avvia l'indagine manuale di potenziali corrispondenze per una richiesta cliente. Ciò implica la valutazione dei dettagli delle potenziali corrispondenze rispetto alle informazioni del cliente per determinarne la rilevanza.
Perché è importante Questo segna l'inizio della revisione manuale della `conformità`, un comune `bottleneck`. Misurare il tempo da 'Potenziale Corrispondenza Identificata' a questa `activity` rivela ritardi di accodamento, mentre la durata della revisione indica l'efficienza dell'`analyst`. Dove trovare Questo può essere dedotto quando un `analyst` 'prende in carico' o apre un `case` dalla coda di revisione. Il sistema può registrare questo `event` esplicitamente in una traccia di audit quando lo stato del `case` cambia a 'In Revisione' o viene assegnato a un utente specifico. Acquisisci Dedotto da un cambiamento dello stato del `case` a 'In Revisione' o dall'assegnazione del `case` a un `analyst`. Tipo di evento inferred
	Richiesta di Screening Creata	Un nuovo caso di screening viene formalmente creato per una richiesta cliente all'interno del sistema Refinitiv World-Check. Questo viene attivato da una chiamata API o da un'immissione manuale da un sistema a monte e rappresenta l'inizio del controllo di intelligence sul rischio.
Perché è importante Questo segna l'inizio ufficiale del sub-processo di screening. Il tempo tra 'Applicazione Presentata' e questa `activity` rivela ritardi nei passaggi di consegna tra il sistema della linea di business e la funzione di `conformità`. Dove trovare Registrato nei log di gestione dei `case` di `World-Check` o nella traccia di audit. Verrebbe utilizzato l'`event` di creazione e il suo `timestamp` per lo specifico `case` o ID entità. Acquisisci Registrato automaticamente quando viene creato un nuovo `case` di screening nel sistema. Tipo di evento explicit
	Richiesta Rifiutata	L'applicazione del cliente viene formalmente respinta, spesso a seguito di una 'Corrispondenza Trovata' in `World-Check` o di altri fattori di rischio. Questo `event` è l'esito negativo finale del processo di `onboarding`.
Perché è importante Questo è il punto finale primario di fallimento del processo. L'analisi degli `event` di rifiuto, in particolare le ragioni e le `activity` precedenti, è cruciale per il miglioramento del processo e la riduzione dei rifiuti non necessari. Dove trovare Questa decisione aziendale finale è registrata nel `CRM` a monte o nel sistema di applicazioni `core`, non in `World-Check` stesso. I `data` devono essere ottenuti da quel sistema. Acquisisci Evento registrato nel sistema applicativo sorgente, spesso con un codice di motivo di rifiuto corrispondente. Tipo di evento explicit
	Screening Completato - Approvato	Il `case` di screening è ufficialmente chiuso con un risultato 'Approvato', il che significa che non sono state trovate corrispondenze vere. Questa decisione viene comunicata al sistema di origine, consentendo al processo di `onboarding` di procedere.
Perché è importante Questa `activity` rappresenta il completamento riuscito, il 'percorso felice', del processo di screening. Serve come punto di arrivo chiave per misurare il tempo di ciclo delle applicazioni standard a basso rischio. Dove trovare Dedotto dal cambiamento dello stato finale del `case` a 'Approvato', 'Completato' o 'Chiuso - Nessuna Corrispondenza'. Viene utilizzato il `timestamp` di questo cambiamento di stato finale. Acquisisci Derivato dal timestamp dello stato finale del caso che indica un risultato chiaro. Tipo di evento inferred
	Screening Completato - Corrispondenza Trovata	Il `case` di screening è ufficialmente chiuso con un risultato 'Corrispondenza Trovata', indicando che è stato identificato un rischio confermato. Questa decisione innesca un diverso processo a valle, come la `due diligence` rafforzata o il rifiuto.
Perché è importante Questo è il punto finale principale del 'percorso negativo' per il processo di screening. L'analisi di questi `case` aiuta a comprendere i profili di rischio e l'efficacia dei controlli di screening. Dove trovare Dedotto dal cambiamento dello stato finale del `case` a 'Corrispondenza Trovata', 'Rischio Identificato' o 'Chiuso - Positivo'. Viene utilizzato il `timestamp` di questo cambiamento di stato finale. Acquisisci Derivato dal timestamp dello stato finale del caso che indica una corrispondenza confermata. Tipo di evento inferred
	Caso Escalato per Revisione	Un analista di primo livello esacala un caso complesso o ad alto rischio a un analista senior o a un manager per una decisione finale. Questo è un punto di passaggio chiave all'interno del team di conformità.
Perché è importante Le escalation spesso creano colli di bottiglia e aumentano il tempo di ciclo. L'analisi della frequenza e delle ragioni delle escalation può evidenziare le esigenze di formazione per gli analisti junior o l'ambiguità nelle politiche di revisione. Dove trovare Registrato come un'`action` esplicita nel `workflow` del `case` o nella traccia di audit. Questo potrebbe anche essere dedotto da un cambiamento nell'utente assegnato al `case`, specialmente a un utente con permessi più elevati. Acquisisci Registrato tramite un pulsante 'Escalate' dedicato o un'`workflow action` all'interno del `case`. Tipo di evento explicit
	Falso Positivo Confermato	L'`analyst` conclude che una potenziale corrispondenza non è la stessa del cliente oggetto dello screening. La corrispondenza viene respinta e il processo di screening per quell'avviso specifico è risolto.
Perché è importante Questo rappresenta un esito comune del processo di revisione. Comprendere il tempo necessario per smaltire i falsi positivi aiuta a misurare l'efficienza dell'`analyst` e l'accuratezza della logica di screening automatizzata. Dove trovare Questa è un'`action` utente esplicita in cui l'`analyst` dispone una specifica corrispondenza come 'Falso Positivo' o 'Non Corrispondente'. Questa `action` è tipicamente registrata nella cronologia del `case`. Acquisisci Registrato quando un `analyst` respinge formalmente una potenziale corrispondenza nel sistema. Tipo di evento explicit
	Informazioni aggiuntive richieste	L'`analyst` determina che sono necessarie ulteriori informazioni per risolvere la potenziale corrispondenza e le richiede all'unità aziendale. Questo pone il `case` in stato di sospeso fino a quando le informazioni non vengono fornite.
Perché è importante Frequenti occorrenze di questa attività indicano problemi con la qualità dei dati iniziali forniti per lo screening. Questa attività introduce ritardi significativi, poiché dipende da team esterni, ed è un fattore chiave di lunghi tempi di ciclo. Dove trovare Questo potrebbe essere un'`action` utente esplicita registrata nelle note del `case` o nel `audit log`. In alternativa, potrebbe essere dedotto da un cambiamento di stato del `case` a 'Informazioni in Sospeso' o 'RFI'. Acquisisci Registrato quando un `analyst` utilizza una funzione per contrassegnare il `case` come richiedente maggiori informazioni. Tipo di evento explicit
	Potenziale Corrispondenza Identificata	Il processo di screening automatizzato ha trovato una o più potenziali corrispondenze che richiedono una revisione manuale da parte di un `analyst`. Questo `event` fa passare il `case` da uno stato automatizzato a una coda di indagine manuale.
Perché è importante Questa `activity` è un punto di diramazione critico nel processo. I `case` con potenziali corrispondenze seguono un percorso più lungo e complesso, e tracciarlo aiuta nella pianificazione delle risorse e nell'analisi dei `bottleneck` per il team di revisione. Dove trovare Dedotto da un cambiamento dello stato del `case` a 'Revisione Richiesta', 'Corrispondenza Potenziale' o uno stato simile all'interno del modulo di gestione dei `case` di `World-Check`. Acquisisci Derivato da un cambiamento di stato del caso che indica la necessità di una revisione manuale. Tipo di evento inferred
	Richiesta Approvata	La domanda del cliente è stata completamente approvata a seguito di uno screening `KYC` di successo e di qualsiasi altro controllo richiesto. Questo `event` si verifica tipicamente nel sistema di origine dopo aver ricevuto un risultato 'Approvato' da `World-Check`.
Perché è importante Questo segna l'esito aziendale positivo del processo di `onboarding`. Tracciare il tempo da questo punto alla presentazione rivela il 'tempo al sì' completo per un nuovo cliente. Dove trovare Questo `event` non è nativo di `World-Check`. Deve essere ottenuto dal `CRM` a monte o dal sistema di applicazioni `core`, che prende la decisione aziendale finale. Acquisisci Evento registrato nel sistema applicativo sorgente al momento dell'approvazione finale. Tipo di evento explicit
	Screening Automatico Eseguito	Il sistema `World-Check` esegue automaticamente lo screening dei dettagli del cliente rispetto al suo `database` di intelligence sul rischio. Questa è un'`activity` guidata dal sistema che produce una serie iniziale di risultati, come potenziali corrispondenze o uno stato `clear`.
Perché è importante Questa `activity` è il primo passaggio a valore aggiunto all'interno del processo di screening. Ritardi prima di questo punto indicano problemi di prontezza del sistema o dei `data`, mentre l'esito determina il successivo carico di lavoro manuale. Dove trovare Questo `event` può essere registrato esplicitamente nella traccia di audit del `case` o dedotto dal `timestamp` di quando i risultati iniziali dello screening diventano disponibili per il `case`. Acquisisci Voce di log di sistema generata al completamento della scansione automatizzata del database. Tipo di evento explicit

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi `data` da `Refinitiv World-Check`

Fasi

Accedere a World-Check One: Acceda al portale Refinitiv World-Check One utilizzando le Sue credenziali.
Navigare alla Gestione dei Casi: Apra la sezione di Gestione dei Casi dove tutti i casi di screening sono archiviati e gestiti.
Preparare l'Esportazione del Report dei Casi: Vada alla funzione di reporting o esportazione all'interno della Gestione dei Casi. Questa potrebbe essere etichettata come 'Esporta Casi' o 'Report Casi'.
Configurare il Report dei Casi: Selezioni le colonne da includere nell'esportazione. Si assicuri di selezionare i campi corrispondenti all'ID Caso (CustomerApplication), data di creazione, data di risoluzione, stato del caso (es. Clear, Match Found) e livello di rischio.
Esportare i Dati di Gestione dei Casi: Definisca il Suo intervallo di date, tipicamente coprendo gli ultimi 3-6 mesi di attività. Applichi eventuali filtri necessari, come per gruppo utente o tipo di caso. Esporti i dati come file CSV e lo nomini case_report.csv.
Preparare l'Esportazione della Traccia di Audit: Navighi alla sezione di reporting della traccia di audit o del log di audit di World-Check One. Questa contiene le cronologie dettagliate degli eventi per ogni caso.
Configurare ed Esportare la Traccia di Audit: Selezioni tutte le colonne pertinenti, inclusi l'ID Caso, il nome o la descrizione dell'evento, il timestamp dell'evento e l'utente che ha eseguito l'azione. Esporti questi dati per lo stesso intervallo di date del report dei casi. Salvi il file come audit_trail.csv.
Reperire Passaggi di Processo Esterni: Ottenga i dati per le attività che si verificano al di fuori di World-Check, come Richiesta Inviata, Richiesta Approvata, Account Attivato e Richiesta Rifiutata. Questi dati provengono tipicamente da un sistema CRM o di core banking. Esporti questi dati con l'ID CustomerApplication e i timestamp rilevanti.
Combinare e Trasformare 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 dati.
Mappare gli Eventi di Audit alle Attività: Elabori il file audit_trail.csv. Mappi le descrizioni degli eventi raw dal log di audit ai valori standardizzati di ActivityName. Ad esempio, una voce del log di audit come 'Caso Assegnato all'Analista' diventa 'Revisione Analista Avviata'.
Mappare i Cambiamenti di Stato del Caso alle Attività: Elabori il file case_report.csv per generare attività basate sui cambiamenti di stato. Utilizzi la data di risoluzione del caso e lo stato finale per creare gli eventi 'Screening Completato - Clear' o 'Screening Completato - Match Found'.
Creare il Log degli Eventi Finale: Riunisca tutti i dati elaborati dai diversi file sorgente in un unico file CSV. Si assicuri che il file finale contenga le colonne richieste: CustomerApplication, ActivityName e EventTime, insieme a tutti gli attributi raccomandati. Salvi questo file per il caricamento nello strumento di Process Mining.

Configurazione

Tipi di Report: Dovrà generare almeno due report separati: un report riassuntivo sulla Gestione dei Casi e un report dettagliato sulla Traccia di Audit.
Intervallo di Date: Per un'analisi iniziale, selezioni un intervallo di date di almeno 3-6 mesi per includere un numero sufficiente di casi completati e in corso. Si assicuri che l'intervallo di date sia coerente in tutti i file esportati.
Formato di Esportazione: Scelga CSV (Comma Separated Values) come formato di esportazione per facilitare l'elaborazione.
Colonne Chiave (Report Casi): Si assicuri che l'esportazione dei casi includa ID Caso, Timestamp di Creazione, Timestamp di Risoluzione, Stato Finale, Analista Assegnato e Livello di Rischio.
Colonne Chiave (Report Traccia di Audit): Si assicuri che l'esportazione del log di audit includa ID Caso, Descrizione dell'Evento, Timestamp dell'Evento e ID Utente.
Prerequisiti: È richiesto l'accesso al portale World-Check One con permessi utente che consentano la visualizzazione e l'esportazione dei dati di gestione dei casi e del log di audit. Ciò potrebbe richiedere privilegi elevati rispetto a un ruolo di analista standard.

a Query di Esempio config

/*
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'

Fasi

Prerequisiti e Configurazione: Si assicuri di avere Python 3.6+ installato insieme alle librerie requests e pandas. Ottenga la Sua API Key e il Suo API Secret di World-Check One dal Suo rappresentante Refinitiv o dal portale sviluppatori. Archivi queste credenziali in modo sicuro.
Sviluppi la Logica di Autenticazione: Nel Suo script Python, crei una funzione per inviare una richiesta POST all'endpoint di autenticazione di World-Check One. Utilizzi la Sua API Key e il Suo Secret per ottenere un token bearer temporaneo richiesto per le successive chiamate API.
Identifichi i Dati del Sistema Sorgente: Il processo inizia e finisce al di fuori di World-Check. Identifichi il sistema sorgente, come un CRM o una piattaforma di core banking, che memorizza i dati iniziali delle richieste. Dovrà estrarre eventi come Richiesta Inviata, Richiesta Approvata, Account Attivato e Richiesta Rifiutata da questa sorgente. Questo può essere fatto tramite una query di database o un'altra API.
Recuperi i Casi World-Check: Utilizzando il token autenticato, effettui una richiesta GET all'endpoint /cases della World-Check One API. Utilizzi i parametri di query per filtrare i casi per un intervallo di date specifico, ad esempio, basato sulla loro data di creazione o modifica.
Gestisca la Paginazione API: Le risposte API di World-Check sono paginate. Il Suo script deve controllare la risposta per i dettagli di paginazione e ciclare attraverso tutte le pagine per recuperare l'elenco completo dei casi per l'intervallo di date specificato.
Recuperi Dettagli e Cronologia dei Casi: Per ogni ID caso recuperato, effettui successive richieste GET a endpoint come /cases/{case_system_id} e /cases/{case_system_id}/audit-trail. Questi endpoint forniscono i dettagli sui cambiamenti di stato, i dettagli di risoluzione e le azioni dell'utente associate al caso.
Mappi i Dati Raw alle Attività: Questo è un passaggio di trasformazione critico. Scriva la logica per iterare attraverso i dati della risposta API (dettagli del caso, traccia di audit) per ogni caso. Mappi specifici cambiamenti di stato, codici di risultato ed eventi di audit alle attività aziendali richieste. Ad esempio, un evento di creazione di un caso diventa Richiesta di Screening Creata, e una risoluzione del risultato Falso Positivo diventa Falso Positivo Confermato.
Combini le Sorgenti di Dati: Unisca i dati estratti da World-Check con i dati del Suo sistema sorgente (dal passaggio 3). Utilizzi l'ID CustomerApplication come chiave comune per creare un log degli eventi end-to-end completo per ogni cliente.
Strutturi e Arricchisca i Dati: Assembli tutti gli eventi mappati in un unico elenco di record. Per ogni record, si assicuri che tutti gli attributi richiesti (CustomerApplication, ActivityName, EventTime) e gli attributi raccomandati siano popolati. Calcoli EventEndTime ove possibile, magari utilizzando il timestamp dell'evento successivo per quel caso.
Esporti in CSV: Converta l'elenco finale dei record degli eventi in un DataFrame pandas. Riordini le colonne per corrispondere al formato richiesto ed esporti il DataFrame in un file CSV. Si assicuri che il file sia salvato con codifica UTF-8 per essere compatibile con ProcessMind.

Configurazione

Credenziali API: Sono richiesti una Chiave API e un Segreto API validi per la World-Check One Screening API. Questi devono essere forniti con i permessi necessari per leggere i dati dei casi e di audit.
URL Base API: Lo script deve essere configurato con l'URL base corretto per il Suo ambiente API World-Check, ad esempio, https://api.world-check.com/v2/.
Intervallo di Date: Implementi i parametri start_date e end_date nello script per controllare il periodo di estrazione. Per un'analisi iniziale, si raccomanda un intervallo di 3-6 mesi. Per il monitoraggio continuo, esegua lo script in modo incrementale per periodi più brevi, come il giorno o la settimana precedente.
Connessione al Sistema Sorgente: Sono necessari i dettagli di connessione per i sistemi a monte e a valle (es. CRM, piattaforma di core banking) per recuperare gli eventi non di screening. Questo potrebbe essere una stringa di connessione a un database o un altro endpoint API e le relative credenziali.
Gestione della Paginazione: Lo script deve specificare una dimensione della pagina, spesso chiamata limit, quando effettua chiamate API per elencare i casi. Un valore tra 50 e 100 è tipicamente efficiente. La logica deve gestire correttamente il recupero di 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()

Il Suo Template Dati di Onboarding Clienti KYC

Il Suo Template Dati di Onboarding Clienti KYC

Attributi del KYC Customer Onboarding

KYC Customer Onboarding Activities

Guide all'Estrazione

Esportazione di `Case` e `Audit Log` di `Refinitiv World-Check One`

Fasi

Configurazione

a Query di Esempio config

Script `Python` che utilizza l'`API` di screening di `World-Check One`

Fasi

Configurazione

a Query di Esempio python

Pronto per iniziare?

Ottimizzi il `KYC Customer Onboarding` ora, aumenti la `conformità`

Il Suo Template Dati di Onboarding Clienti KYC

Il Suo Template Dati di Onboarding Clienti KYC

Attributi del KYC Customer Onboarding

KYC Customer Onboarding Activities

Guide all'Estrazione

Esportazione di `Case` e `Audit Log` di `Refinitiv World-Check One`

Fasi

Configurazione

a Query di Esempio config

Script `Python` che utilizza l'`API` di screening di `World-Check One`

Fasi

Configurazione

a Query di Esempio python

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Ottimizzi il KYC Customer Onboarding ora, aumenti la conformità

Ottimizzi il `KYC Customer Onboarding` ora, aumenti la `conformità`