Il Suo Template Dati di Onboarding Clienti KYC

LexisNexis Risk Solutions
Il Suo `Template` `Dati` di Onboarding Clienti KYC

Il Suo Template Dati di Onboarding Clienti KYC

Questo `template` fornisce una guida completa per la raccolta dei `dati` necessari all'analisi del Suo processo di Onboarding Clienti KYC. Delinea gli attributi essenziali da raccogliere, le attività chiave da tracciare e fornisce indicazioni su how to extract this information from your source systems. Utilizzi questa risorsa per costruire un `event log` robusto, enabling deep insights into your onboarding journey.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di Onboarding Clienti KYC

Questi sono i campi `dati` raccomandati da includere nel Suo `event log` per un'analisi completa dell'Onboarding Clienti KYC e la scoperta del processo.
3 Obbligatorio 6 Consigliato 12 Facoltativo
Nome Descrizione
Domanda Cliente
CustomerApplication
L'identificatore unico per ogni domanda di onboarding cliente, che funge da ID caso primario.
Descrizione

La Domanda Cliente è l'identificatore centrale che collega tutte le attività e i punti dati correlati per il percorso di onboarding di un singolo cliente. Inizia quando una domanda viene presentata e segue il caso fino a quando non viene completata o rifiutata.

Nel Process Mining, questo attributo è essenziale per raggruppare tutti gli eventi in un caso coeso, consentendo un'analisi end-to-end del ciclo di vita dell'onboarding. Permette la ricostruzione dell'intero flusso di processo per ogni richiedente, il che è fondamentale per calcolare i tempi di ciclo, analizzare le varianti di processo e tracciare lo stato di una domanda nel tempo.

Perché è importante

Questo è l'ID Caso fondamentale. Senza di esso, non è possibile tracciare il percorso end-to-end di una domanda cliente, rendendo impossibile l'analisi del processo.

Dove trovare

Questo è l'identificatore di caso primario all'interno del modulo di gestione dei casi di LexisNexis Risk Solutions.

Esempi
APP-2023-001234APP-2023-005678APP-2024-009101
Nome attività
ActivityName
Il nome dell'attività o dell'evento specifico che si è verificato in un determinato momento durante il processo di onboarding.
Descrizione

Il Nome Attività descrive un passaggio nel workflow di onboarding KYC, come 'Domanda Inviata', 'Revisione Documenti Eseguita' o 'Domanda Approvata'. Ogni attività rappresenta un'azione o una pietra miliare distinta nel processo.

Questo attributo è fondamentale per la costruzione della mappa del processo, che rappresenta visivamente il flusso delle attività. Consente l'analisi delle varianti di processo, dei bottleneck tra passaggi specifici e della frequenza dei loop di rilavorazione. L'analisi delle attività è fondamentale per capire cosa sta accadendo nel processo.

Perché è importante

Questo attributo costituisce la spina dorsale della mappa del processo, consentendo di visualizzare e analizzare la sequenza degli eventi nel percorso di onboarding del cliente.

Dove trovare

Tipicamente presente in un event log o nella tabella di audit trail all'interno di LexisNexis Risk Solutions che traccia i passaggi del processo.

Esempi
Domanda InviataScreening Iniziale EseguitoDocumenti richiestiRevisione Conformità Completata
Timestamp Evento
EventTimestamp
La `data` e l'ora precise in cui è iniziata un'attività specifica.
Descrizione

Questo timestamp segna l'inizio di un'attività, fornendo l'ordine cronologico per tutti gli eventi all'interno di un caso. È la base per tutte le analisi basate sul tempo nel Process Mining.

Utilizzando il timestamp dell'Evento, è possibile calcolare la durata delle attività, il tempo di attesa tra di esse e il tempo di ciclo end-to-end totale del processo di onboarding. Questi dati sono essenziali per identificare i bottleneck, monitorare l'aderenza SLA e comprendere l'efficienza del processo.

Perché è importante

Questo timestamp è essenziale per ordinare gli eventi cronologicamente e calcolare tutte le metriche basate sul tempo, come i tempi di ciclo e i bottleneck.

Dove trovare

Si trova nelle tabelle del event log o di audit trail accanto al Nome dell'Attività.

Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
Data Obiettivo SLA
SlaTargetDate
La `data` entro la quale si prevede il completamento del processo di onboarding del cliente.
Descrizione

La data target SLA definisce l'agreement di livello di servizio per il completamento di un'applicazione. Questa data è spesso determinata in base a fattori come il tipo di applicazione, il segmento di clientela o la giurisdizione.

Questo attributo è essenziale per la dashboard 'Monitoraggio Aderenza Obiettivi SLA' e il KPI 'Tasso di Aderenza SLA'. Confrontando la data di completamento effettiva con la data target SLA, le organizzazioni possono misurare le loro prestazioni rispetto agli impegni, identificare i casi a rischio di violazione degli SLA e indagare le cause alla radice dei ritardi.

Perché è importante

Consente la misurazione delle prestazioni rispetto agli accordi sui livelli di servizio (SLA), evidenziando le inefficienze di processo che causano violazioni degli SLA.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo può essere memorizzato nel caso o calcolato in base a regole di business.

Esempi
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
Dipartimento
Department
Il dipartimento o team aziendale a cui appartiene l'utente assegnato.
Descrizione

L'attributo Dipartimento specifica il gruppo funzionale responsabile di un'attività, come 'Conformità', 'Operazioni di Onboarding' o 'Prevenzione Frodi'.

Questo attributo viene utilizzato per analizzare il processo da una prospettiva dipartimentale, consentendo l'analisi dei passaggi di consegne tra i diversi team. È una dimensione primaria nella dashboard 'Allocazione Risorse e Carico di Lavoro' e aiuta a identificare inefficienze interfunzionali o ritardi nella comunicazione tra i dipartimenti.

Perché è importante

Consente l'analisi dei passaggi di processo e delle prestazioni per area funzionale, aiutando a identificare i colli di bottiglia inter-dipartimentali.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Potrebbe essere necessario unirla da una tabella di dati anagrafici utente o HR.

Esempi
ComplianceTeam di OnboardingAnalisti KYCSupporto Clienti
Livello di Rischio
RiskLevel
Il livello di rischio calcolato dell'applicazione del cliente, come Basso, Medio o Alto.
Descrizione

LexisNexis Risk Solutions è specializzata nella valutazione del rischio. Questo attributo rappresenta l'output di tale valutazione, categorizzando ogni applicazione in base al suo potenziale profilo di rischio. Il livello di rischio spesso determina l'intensità e la durata richieste del processo di due diligence.

Questo attributo è la dimensione fondamentale per la dashboard 'Livello di Rischio vs. Durata Onboarding'. L'analisi del processo per livello di rischio può rivelare se le applicazioni ad alto rischio richiedono tempi significativamente più lunghi, come previsto, o se le applicazioni a basso rischio subiscono ritardi non necessari. Aiuta a convalidare e affinare le strategie di onboarding basate sul rischio.

Perché è importante

Cruciale per l'analisi basata sul rischio, aiuta a capire come i profili di rischio del cliente influenzano la complessità, la durata e i percorsi del processo.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo è un output fondamentale dei moduli di valutazione del rischio.

Esempi
BassoMedioElevatoSanzionato
Ora di Fine
EndTime
La data e l'ora esatte in cui un'attività è stata completata.
Descrizione

Questo timestamp segna il completamento di un'attività. La differenza tra l'End Time e lo Start Time per un evento rappresenta il suo tempo di elaborazione.

L'End Time è cruciale per calcolare accuratamente quanto tempo richiede ogni passaggio, ed è un input primario per la dashboard 'Tempi di Elaborazione e Attesa Attività'. Aiuta a differenziare tra il tempo in cui una risorsa ha lavorato attivamente su un'attività e il tempo in cui il caso era in attesa che iniziasse il passaggio successivo.

Perché è importante

Consente il calcolo preciso del tempo di elaborazione delle attività, essenziale per identificare i passaggi inefficienti e analizzare il carico di lavoro delle risorse.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Spesso disponibile negli event logs che registrano sia gli eventi di inizio che di fine.

Esempi
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
Stato Applicazione
ApplicationStatus
Lo stato attuale o finale della domanda del cliente.
Descrizione

Questo attributo riflette lo stato complessivo del caso in un dato momento o il suo esito finale. Gli stati comuni includono 'In Corso', 'Approvato', 'Rifiutato' o 'In Attesa di Informazioni'.

Lo Stato Applicazione è vitale per tracciare gli esiti del processo di onboarding. Viene utilizzato nelle dashboard 'Motivi e Fasi di Rifiuto Applicazione' e 'Produttività Giornaliera e Stato Applicazione' per monitorare i tassi di successo e il flusso operativo. Analizzare how status changes over time provides insight into the case lifecycle.

Perché è importante

Traccia l'esito di ogni domanda, il che è essenziale per calcolare KPI chiave come il Tasso di Rifiuto delle Applicazioni e monitorare il throughput.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo è tipicamente un campo chiave sull'oggetto caso o applicazione principale.

Esempi
In CorsoApprovatoRifiutatoInformazioni Cliente in Sospeso
Utente Assegnato
AssignedUser
L'identificatore unico dell'utente o agente responsabile dell'esecuzione dell'attività.
Descrizione

Questo attributo identifica l'individuo specifico che ha eseguito un'attività, come un ufficiale di conformità che esegue una revisione dei documenti. Aiuta nell'analisi della distribuzione del carico di lavoro e delle prestazioni individuali.

Nell'analisi, l'Utente Assegnato è fondamentale per la dashboard 'Allocazione Risorse e Carico di Lavoro'. Consente di filtrare la mappa del processo per utente, confrontare le prestazioni tra i membri del team e identificare opportunità di formazione o riequilibrio del carico di lavoro. Può anche aiutare a individuare i bottleneck causati da specifici gruppi di utenti.

Perché è importante

Questo attributo è cruciale per analizzare le prestazioni delle risorse, la distribuzione del carico di lavoro e identificare opportunità di automazione o ottimizzazione delle risorse.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Solitamente si trova nei registri di audit o nelle tabelle di gestione delle attività.

Esempi
j.doem.smithk.chen
Canale
Channel
Il canale attraverso il quale è stata presentata la domanda, come 'Web', 'Mobile' o 'In-filiale'.
Descrizione

L'attributo Canale identifica la fonte di invio dell'applicazione. Il canale può influenzare la qualità dei dati, il comportamento del cliente e i tipi di problemi riscontrati durante l'onboarding.

Questo attributo viene utilizzato per confrontare le prestazioni del processo tra diversi canali. Ad esempio, la dashboard 'Tassi di Conversione Funnel Onboarding' può essere filtrata per canale per vedere se i candidati mobile abbandonano a un tasso più elevato rispetto ai candidati web, informando sui miglioramenti del processo specifici del canale.

Perché è importante

Aiuta ad analizzare le prestazioni del processo per canale di invio, identificando variazioni che possono informare la strategia del canale e i miglioramenti dell'esperienza utente.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questa informazione viene tipicamente acquisita all'inizio del processo di applicazione.

Esempi
Portale WebApp MobileIn FilialeAPI
È Automatizzato
IsAutomated
Un indicatore che segnala se un'attività è stata eseguita automaticamente dal sistema o manualmente da un utente.
Descrizione

Questo attributo booleano distingue tra le attività eseguite dall'automazione del sistema (ad esempio, un controllo di screening iniziale) e quelle che richiedono l'intervento umano (ad esempio, una revisione manuale dei documenti).

'È Automatizzato' viene utilizzato per calcolare il KPI 'Proporzione Attività Manuali' e per analizzare l'efficacia delle iniziative di automazione. Nella mappa del processo, può evidenziare l'interfaccia tra passaggi automatizzati e manuali, helping to identify opportunities for further automation to reduce costs and processing times.

Perché è importante

Distingue tra attività manuali e automatizzate, il che è fondamentale per identificare le opportunità di automazione e misurarne l'impatto.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo potrebbe essere un flag nell'event log o dedotto in base all''AssignedUser' (ad esempio, un utente 'system').

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

Questo flag booleano è impostato su true quando un'attività viene ripetuta all'interno dello stesso caso, such as a 'Document Review Performed' occurring a second time after 'Additional Information Requested'. It signifies that the process has moved backward.

'È Rilavorazione' è cruciale per la dashboard 'Analisi Rilavorazione e Ripetizione' e il KPI 'Percentuale Loop di Rilavorazione'. Consente la quantificazione dello sforzo sprecato e helps identify the root causes of rework, such as unclear instructions or poor data quality, enabling targeted process improvements.

Perché è importante

Quantifica direttamente l'inefficienza e lo sforzo sprecato nel processo, evidenziando le attività che vengono frequentemente ripetute e che aumentano i costi e i cycle time.

Dove trovare

Questo è un attributo calcolato, tipicamente derivato all'interno dello strumento di Process Mining rilevando sequenze ripetute di attività all'interno di un caso.

Esempi
truefalse
Motivo del Rigetto
RejectionReason
Un codice o una descrizione che spiega perché un'applicazione è stata rifiutata.
Descrizione

Quando lo stato finale di un'applicazione è 'Rifiutato', questo attributo fornisce la ragione specifica. Esempi includono 'Verifica Identità Fallita', 'Corrispondenza Sanzioni' o 'Documentazione Incompleta'.

Questi dati sono l'input primario per la dashboard 'Motivi e Fasi di Rifiuto Applicazione'. Analizzare i motivi di rifiuto aiuta a identificare i punti di fallimento comuni nel processo, che possono informare i miglioramenti alle linee guida dell'applicazione, alla comunicazione con il cliente o ai criteri di revisione interna. Comprendere why applications are rejected is key to improving the overall approval rate.

Perché è importante

Fornisce insight diretti sul perché l'onboarding fallisce, consentendo miglioramenti mirati per aumentare il tasso di approvazione delle applicazioni.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Spesso si trova in un campo che viene popolato quando lo Stato dell'Applicazione è impostato su 'Rifiutata'.

Esempi
Corrispondenza Lista SanzioniDocumentazione IncompletaVerifica ID&V FallitaProfilo ad Alto Rischio
Paese Cliente
CustomerCountry
Il paese di residenza o di costituzione per il cliente.
Descrizione

Questo attributo specifica il paese del cliente, un fattore critico nel KYC a causa delle diverse normative internazionali e dei livelli di rischio associati a diverse giurisdizioni.

L'analisi del processo per Paese del Cliente can reveal significant differences in cycle times and process complexity. For example, applications from high-risk jurisdictions may require additional compliance checks, leading to longer durations. This analysis helps in resource planning and setting realistic SLAs for different regions.

Perché è importante

Consente l'analisi giurisdizionale, cruciale per comprendere come le normative regionali e i fattori di rischio influenzano le prestazioni del processo.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo è un campo standard nei dati anagrafici del cliente.

Esempi
Stati UnitiGBRDEUSGP
Revisore Conformità
ComplianceReviewer
L'utente o agente specificamente assegnato alle attività di revisione della `conformità`.
Descrizione

Mentre 'AssignedUser' cattura l'utente per qualsiasi attività, questo attributo identifica specificamente lo specialista di conformità coinvolto nelle fasi di revisione critiche. Ciò consente un'analisi più mirata della funzione di conformità.

Questo attributo è fondamentale per la dashboard 'Durata Revisione Conformità e Backlog'. Aiuta ad analizzare il carico di lavoro e le prestazioni del team di conformità, identifying if specific reviewers are bottlenecks or if the overall team is under-resourced.

Perché è importante

Fornisce insight mirati sulla funzione di conformità, consentendo un'analisi dettagliata del carico di lavoro e delle prestazioni dei revisori in questa fase critica e spesso ritardata del processo.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo può essere derivato filtrando 'AssignedUser' per le attività correlate alla conformità.

Esempi
c.joness.patelsystem_escalation
Sistema di Origine
SourceSystem
Il sistema o l'applicazione da cui hanno avuto origine i `dati` dell'evento.
Descrizione

Questo attributo identifica il sistema sorgente che ha generato i dati dell'evento, come LexisNexis Risk Solutions o uno strumento di terze parti integrato. In ambienti complessi, i dati per un singolo processo possono provenire da più sistemi.

Comprendere il sistema sorgente è utile per la convalida dei dati, la risoluzione dei problemi e l'analisi delle variazioni di processo che possono essere specifiche di un particolare sistema. Aiuta a garantire l'integrità dei dati e fornisce contesto su how and where an activity was recorded.

Perché è importante

Identifica l'origine dei dati, che è cruciale per la governance dei dati, la validazione e la comprensione dell'esecuzione del processo attraverso diversi sistemi IT.

Dove trovare

Queste informazioni possono essere memorizzate come valore statico o in un campo specifico all'interno dell'esportazione dei dati o della risposta API.

Esempi
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
Stato SLA
SlaStatus
Indica se l'applicazione completata ha rispettato il suo obiettivo SLA.
Descrizione

Questo attributo categorizza ogni caso completato in base alla sua aderenza allo 'SlaTargetDate'. I valori tipici sono 'Rispettato' o 'Violato'.

Questo campo calcolato è la base della dashboard 'Monitoraggio Aderenza Obiettivi SLA' e del KPI 'Tasso di Aderenza SLA'. Fornisce una visione chiara e di alto livello delle prestazioni rispetto agli impegni di servizio e consente un'analisi approfondita per comprendere le caratteristiche comuni dei casi che violano i loro SLA.

Perché è importante

Fornisce un risultato chiaro e binario per le prestazioni SLA, rendendo facile tracciare, riportare e analizzare la conformità con gli obiettivi di livello di servizio.

Dove trovare

Questo è un attributo calcolato, derivato confrontando il timestamp dell'attività finale con lo 'SlaTargetDate' per ogni caso.

Esempi
RaggiuntoViolatoA Rischio
Tempo di Ciclo
CycleTime
La durata totale `end-to-end` di una domanda cliente, dall'invio alla decisione finale.
Descrizione

Il Cycle Time misura il tempo totale trascorso dal primissimo evento (ad esempio, 'Domanda Inviata') all'ultimissimo evento (ad esempio, 'Onboarding Cliente Completato' o 'Domanda Rifiutata') per un singolo caso.

Questo è un KPI primario per misurare lo stato di salute generale del processo ed è visualizzato nella dashboard 'Onboarding End-to-End Cycle Time'. Il monitoraggio del tempo medio del ciclo consente alle organizzazioni di monitorare l'impatto dei miglioramenti di processo e di identificare come diversi fattori, come il livello di rischio o il tipo di applicazione, influenzano l'esperienza complessiva del cliente.

Perché è importante

Questo è un indicatore chiave di performance che misura il tempo totale per il time-to-value per il cliente, influenzando direttamente la soddisfazione del cliente e l'efficienza operativa.

Dove trovare

Questa è una metrica calcolata, derivata sottraendo il timestamp del primo evento dal timestamp dell'ultimo evento per ogni caso.

Esempi
5 giorni 4 ore22 giorni 8 ore1 giorno 2 ore
Tempo di Elaborazione
ProcessingTime
La durata del tempo trascorso lavorando attivamente su un'attività.
Descrizione

Il Tempo di Elaborazione è la durata calcolata dai timestamp di inizio e fine di un'attività (EndTime - StartTime). Rappresenta il tempo in cui una risorsa è stata attivamente impegnata in un compito, in contrapposizione al tempo di attesa.

Questa metrica calcolata è un caposaldo dell'analisi delle prestazioni e alimenta direttamente la dashboard 'Tempi di Elaborazione e Attesa Attività'. Aiuta a individuare quali attività specifiche sono le più dispendiose in termini di tempo, indicando obiettivi per il miglioramento del processo, la formazione o l'automazione. Ad esempio, aiuta a calcolare il KPI 'Tempo medio di elaborazione della revisione documenti'.

Perché è importante

Misura il tempo di lavoro attivo per le attività, aiutando a distinguere tra tempo a valore aggiunto e tempo di attesa improduttivo per identificare i veri bottleneck.

Dove trovare

Questo è un campo calcolato, derivato dalla differenza tra gli attributi 'EndTime' e 'EventTimestamp' (StartTime).

Esempi
25 minuti1 ora 15 minuti3 giorni
Tipo Applicazione
ApplicationType
Il tipo di domanda cliente, come 'Individuale' o 'Aziendale'.
Descrizione

Questo attributo categorizza le applicazioni in base al tipo di entità in fase di onboarding. Diversi tipi di applicazioni spesso seguono percorsi di processo distinti e hanno diversi profili di rischio e obiettivi SLA.

L'analisi del processo per Tipo di Applicazione consente la segmentazione dei dati per confrontare l'efficienza e la complessità dell'onboarding di diversi tipi di clienti. È un filtro comune utilizzato nella maggior parte delle dashboard per fornire una visione più granulare delle prestazioni.

Perché è importante

Consente una potente segmentazione del processo, rivelando come vengono gestiti i diversi tipi di applicazioni e dove esistono colli di bottiglia specifici per ciascun tipo.

Dove trovare

Consultare la documentazione di LexisNexis Risk Solutions o l'amministratore di sistema. Questo è tipicamente un campo chiave sull'oggetto applicazione o caso.

Esempi
IndividualeAziendaleIndividuo ad Alto PatrimonioFiducia
Ultimo `Data Update`
LastDataUpdate
Il `timestamp` che indica l'ultima volta che i `dati` sono stati aggiornati o estratti dal sistema sorgente.
Descrizione

Questo attributo fornisce un timestamp per l'ultimo aggiornamento del dataset. Viene tipicamente applicato all'intero dataset durante il processo di estrazione e caricamento dei dati.

Queste informazioni sono fondamentali per gli utenti della dashboard per comprendere la freschezza dei dati che stanno analizzando. Garantisce che le decisioni siano basate su dati attuali quanto richiesto e aiuta a gestire le aspettative sulla tempestività degli insight.

Perché è importante

Fornisce un contesto cruciale sulla freschezza dei dati, assicurando che le analisi siano pertinenti e che le decisioni non siano basate su informazioni obsolete.

Dove trovare

Questo viene solitamente generato e stampato sul dataset durante il processo ETL (Extract, Transform, Load).

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

Attività di Onboarding Clienti KYC

Questi sono i passaggi chiave del processo e le pietre miliari da catturare nel Suo `event log` per un'accurata scoperta del processo e analisi delle prestazioni.
8 Consigliato 6 Facoltativo
Activity Descrizione
Documenti Ricevuti
Conferma che il cliente ha caricato o fornito i documenti richiesti al sistema. Questo è tipicamente un evento esplicito generato dal portale di invio documenti o un'inserimento manuale da parte di un agente.
Perché è importante

Questa attività conclude un periodo di attesa e innesca successive attività di revisione. È una pietra miliare chiave nella fase di raccolta dei dati.

Dove trovare

Catturato dai log del sistema di gestione documentale o da una voce con timestamp nel fascicolo del caso di applicazione quando vengono allegati nuovi documenti.

Acquisisci

L'evento viene registrato quando un documento viene caricato con successo o contrassegnato manualmente come ricevuto nel sistema.

Tipo di evento explicit
Domanda Approvata
La decisione finale di approvare la domanda del cliente viene presa e registrata nel sistema. Questo è un risultato aziendale critico ed è quasi sempre catturato come un cambiamento di stato esplicito.
Perché è importante

Questa pietra miliare segna la conclusione positiva del processo decisionale. L'analisi dei percorsi che portano all'approvazione aiuta a identificare le migliori pratiche.

Dove trovare

Cercare un aggiornamento di stato finale nel record del caso dell'applicazione in cui lo stato è impostato su 'Approvato' o uno stato terminale simile.

Acquisisci

Registrato come un cambiamento di stato finale e definitivo nella tabella principale dell'applicazione o del caso.

Tipo di evento explicit
Domanda Inviata
Segna l'inizio del processo di onboarding KYC quando la domanda di un cliente viene ricevuta per la prima volta dal sistema. Questo evento viene tipicamente catturato esplicitamente quando il modulo di domanda viene inviato tramite un portale clienti o un sistema di inserimento `dati` interno integrato con LexisNexis.
Perché è importante

Questo è l'evento di inizio primario per il processo. Analizzare il tempo da questa attività al completamento è cruciale per misurare il tempo di ciclo end-to-end e l'aderenza SLA.

Dove trovare

Catturato dai log di sistema o da una tabella di applicazioni che registra il timestamp di creazione iniziale di un nuovo record di domanda cliente.

Acquisisci

L'evento viene registrato al momento della creazione di un nuovo caso di applicazione o di una voce nella tabella principale dell'applicazione.

Tipo di evento explicit
Domanda Rifiutata
La decisione finale di rifiutare la domanda del cliente viene registrata. Questo è un evento terminale e viene catturato tramite un cambiamento di stato definitivo nel sistema.
Perché è importante

Questo è l'evento finale primario di stato di fallimento. Analizzare le fasi in cui si verificano i rifiuti e le ragioni associate è cruciale per il miglioramento del processo.

Dove trovare

Catturato dal campo stato finale del record dell'applicazione impostato su 'Rifiutata', 'Declinata' o uno stato terminale simile.

Acquisisci

Registrato come un cambiamento di stato finale e definitivo nella tabella principale dell'applicazione o del caso.

Tipo di evento explicit
Onboarding Cliente Completato
Questo evento segna la conclusione positiva dell'intero processo di onboarding, confermando che il cliente è pienamente attivo. Può essere uno stato finale esplicito o inferito dall'evento 'Account Attivato'.
Perché è importante

Questo è l'evento finale primario di stato di successo. È essenziale per calcolare il tempo di ciclo end-to-end per tutti i clienti con onboarding completato con successo.

Dove trovare

Deducibile dal timestamp 'Account Attivato' o catturato da uno stato finale, terminale come 'Onboarding Completato' nel fascicolo del caso.

Acquisisci

Deducibile dall'ultimo evento positivo significativo, come l'attivazione dell'account, o un aggiornamento di stato finale.

Tipo di evento inferred
Revisione Conformità Avviata
Un caso viene assegnato a un responsabile della conformità o a un team per una revisione manuale, tipicamente per applicazioni ad alto rischio. Questo si deduce spesso da un cambio di stato a 'Revisione Conformità in Sospeso' o da un log di assegnazione di attività.
Perché è importante

Questo segna l'inizio di una fase di revisione manuale, spesso lunga. Misurare il tempo da questo punto al suo completamento helps quantify compliance-related bottlenecks.

Dove trovare

Catturato da un log di assegnazione attività, da un cambio di proprietà del caso a un team di conformità o da un aggiornamento di stato nella cronologia del caso.

Acquisisci

Deducibile da un cambio di stato come 'Sotto Revisione Conformità' o quando il caso viene assegnato a una coda utente correlata alla conformità.

Tipo di evento inferred
Revisione Conformità Completata
L'ufficiale di `conformità` completa la sua revisione e formula una raccomandazione, spostando il caso alla fase successiva. Questo può essere catturato esplicitamente quando un'attività viene contrassegnata come 'completa' o inferito quando lo stato cambia da 'In Attesa di Conformità' a un altro stato.
Perché è importante

Questa è una pietra miliare chiave che conclude una parte critica, e spesso manuale, del processo. È il punto finale per misurare la durata della revisione di conformità.

Dove trovare

Catturato da un timestamp di completamento di un'attività di conformità o da un cambio di stato da 'Sotto Revisione Conformità'.

Acquisisci

Deducibile da un cambio di stato che indica che la revisione è terminata, come il passaggio a 'Approvato', 'Rifiutato' o 'Decisione Finale'.

Tipo di evento inferred
Valutazione del Rischio Eseguita
Il sistema calcola un punteggio di rischio per il cliente basandosi sulle informazioni raccolte e sui controlli eseguiti. Questa è una funzionalità chiave di LexisNexis ed è tipicamente catturata come un evento esplicito e automatizzato nella cronologia del caso.
Perché è importante

L'esito di questa valutazione spesso determina il successivo percorso di processo, come la necessità di una due diligence rafforzata. È un punto decisionale critico nel workflow.

Dove trovare

Cercare un evento nel log di audit dell'applicazione o nella cronologia del workflow che registra il completamento del modulo di risk scoring o valutazione.

Acquisisci

Un evento specifico viene registrato quando il motore di rischio completa la sua analisi e assegna un profilo o un punteggio di rischio.

Tipo di evento explicit
Account Attivato
Dopo l'approvazione, l'account del cliente viene formalmente creato e attivato nella piattaforma di core banking o servizi. Questa attività è spesso registrata in un audit trail o dedotta dalla data di creazione dell'account.
Perché è importante

Questo è il passaggio finale di erogazione del valore per il cliente. I ritardi tra 'Domanda Approvata' e questo passaggio can indicate system integration issues.

Dove trovare

Catturato da un log di creazione account, una chiamata API a un altro sistema o il timestamp di creazione del record dell'account stesso.

Acquisisci

Registrato come evento separato post-approvazione o identificato dalla presenza di un timestamp di attivazione nel record del cliente.

Tipo di evento explicit
Documenti richiesti
Il sistema o un utente richiede documentazione specifica al cliente, come una patente di guida o una bolletta di un'utenza. Questo evento può essere catturato dai `log` di comunicazione generati dal sistema o da un cambio di stato che indica che il caso è in attesa di documenti.
Perché è importante

Questa attività spesso introduce un significativo tempo di attesa nel processo. L'analisi della frequenza e della durata aiuta a identificare i ritardi causati dai tempi di risposta del cliente.

Dove trovare

Verificare la presenza di un evento nei log di comunicazione inviati al cliente o un cambio di stato sull'applicazione, ad esempio, 'Documenti Cliente in Sospeso'.

Acquisisci

Deducibile da un cambio di stato a 'In Attesa di Documenti' o da un timestamp di un log di comunicazione in uscita.

Tipo di evento inferred
Informazioni aggiuntive richieste
Un responsabile della conformità o revisore richiede ulteriori informazioni o chiarimenti al cliente. Questo evento è un fattore primario di rilavorazione ed è tipicamente catturato come un cambiamento di stato esplicito o una voce nel log di comunicazione.
Perché è importante

Questa attività crea loop di rilavorazione che prolungano il tempo di ciclo dell'onboarding. Il monitoraggio della sua frequenza aiuta a identificare requisiti poco chiari o carenze comuni nelle domande.

Dove trovare

Cercare un cambio di stato in 'In Attesa di Informazioni dal Cliente' o un event log di comunicazione in uscita. Questa è spesso un'azione attivata dall'utente.

Acquisisci

Registrato quando un agente utilizza una funzione 'Richiedi Informazioni', che modifica lo stato del caso e può registrare un evento di comunicazione.

Tipo di evento explicit
Revisione Documenti Eseguita
Un utente o uno strumento automatizzato esamina i documenti inviati per autenticità, validità e completezza. Questa attività può essere dedotta da un cambio di stato da 'Documenti Ricevuti' a 'Revisione Completata' o da una voce esplicita nel log.
Perché è importante

Questa è una fonte comune di bottleneck e rilavorazioni. Analizzare i suoi tempi di elaborazione e le ripetizioni è fondamentale per migliorare l'efficienza e identificare opportunità di automazione.

Dove trovare

Deducibile tracciando il tempo tra lo stato 'Documenti Ricevuti' e uno stato successivo come 'Verifica Superata' o 'Informazioni Aggiuntive Richieste'.

Acquisisci

Calcolato come il tempo tra l'evento di ricezione del documento e l'evento che segna il completamento della revisione.

Tipo di evento inferred
Screening Iniziale Eseguito
Un controllo automatizzato eseguito dal sistema immediatamente dopo l'invio per validare la completezza dei dati di base ed eseguire controlli preliminari. Questa attività è spesso registrata come un passaggio esplicito e automatizzato nella cronologia del workflow di processo.
Perché è importante

Identifica le applicazioni che falliscono nella fase più precoce, aiutando a comprendere i problemi di qualità dei dati. Segna anche il primo passaggio automatizzato a valore aggiunto nel processo.

Dove trovare

Cercare log di esecuzione di regole automatizzate o un cambiamento di stato nella cronologia del workflow dell'applicazione che indichi il completamento della fase di screening iniziale.

Acquisisci

Registrato come attività automatizzata completata o come specifico aggiornamento di stato nella cronologia del caso.

Tipo di evento explicit
Verifica Identità Avviata
Rappresenta il punto in cui il sistema inizia il processo di verifica dell'identità principale utilizzando i servizi LexisNexis, come il controllo rispetto ai `database`. Questo viene solitamente catturato come un `event log` esplicito quando il servizio di verifica viene chiamato.
Perché è importante

Questa attività segna l'inizio di un sub-processo critico e spesso dispendioso in termini di tempo. Il monitoraggio della sua durata aiuta a isolare i bottleneck legati ai controlli di identità.

Dove trovare

Catturato dai log delle chiamate API al modulo di verifica dell'identità o da una voce di audit trail che mostra l'inizio dell'attività di verifica.

Acquisisci

Un evento viene registrato quando il modulo di verifica dell'identità del sistema o l'API viene attivato per l'applicazione.

Tipo di evento explicit
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i suoi dati da LexisNexis Risk Solutions