Gestione dei casi - Casi e ciclo di vita

Case Management è il centro di indagine della Console Didit. Ogni riscontro AML, ogni verifica segnalata o ogni transazione sospetta può diventare un caso su cui il tuo team di compliance lavora dall’apertura alla risoluzione, con un registro di audit completo.

---

​

Ciclo di vita

Un caso attraversa esattamente tre stati: Per risolvere un caso è necessaria una risoluzione: Ogni caso ha inoltre una priorità (Low, Medium, High, predefinita Medium) e una data di scadenza facoltativa che guida l’ordinamento per SLA e i flag di ritardo.

​

Un soggetto per caso

Ogni caso è associato a esattamente un utente o a una sola azienda. Non puoi mescolare soggetti in un unico caso, e non puoi collegare una sessione, una sessione aziendale o una transazione che appartiene a un soggetto diverso da quello del caso: in tal caso viene restituito un errore esplicito. Questo mantiene ogni pagina del caso focalizzata: la scheda del soggetto, la panoramica del rischio, i documenti e i dati finanziari descrivono tutti la stessa persona o azienda oggetto dell’indagine. Per esaminare una seconda entità, apri (o crea) un caso separato.

​

Contesto della fonte Fraud Check

Creando un caso da una sessione Fraud Check si conservano il suo ID di controllo, l’ID della richiesta e la sezione aperta dal revisore. La scheda della fonte registra anche lo stato di analisi della sessione al momento della creazione del caso. La decisione sul caso e la decisione sulla fonte restano separate. I client API possono fornire source_context con check_id, request_id e source_section quando creano un caso. Includi tale richiesta come voce session in links. Il controllo e la sessione collegata devono appartenere all’applicazione selezionata e appartenere l’uno all’altra. L’API legge da sola lo stato di analisi e, in questo contesto, rifiuta i campi di stato, raccomandazione o tipo di fonte forniti dal chiamante.

​

Elenchi

Case Management mantiene Casi, Panoramica e Assegnazione disponibili nella navigazione superiore. Lo spazio di lavoro Casi offre le viste per stato Aperti, In attesa dell’utente, Risolti e Tutti. Aprendo un caso, la coda dei casi resta affiancata ai suoi dettagli su desktop. Su mobile, usa il breadcrumb per tornare alla coda. La ricerca corrisponde a nome o ID del soggetto, tag, numero del caso, titolo del caso, ID della sessione collegata e ID della transazione collegata, così puoi incollare un UUID di sessione o di transazione e arrivare direttamente al suo caso. Chip di filtro: Blueprint, Creata, Fonte, Assegnatario, Tag, più Aggiungi filtro per Priorità e Scadenza. Colonne: Creazione (data e autore), Dettagli del caso (titolo), Stato, Blueprint, Soggetto (nome e ID), Tag del soggetto, Assegnatario, Priorità e Data di scadenza, con altre disponibili scorrendo orizzontalmente e tramite la configurazione delle colonne.

​

Ordinamento e SLA

Ordina per Creato il (predefinito) o per Data di scadenza. Ordinando per data di scadenza, i casi in ritardo compaiono per primi: un caso è in ritardo quando la sua data di scadenza è passata mentre è ancora Aperto o In attesa dell’utente, e viene mostrato con un chip rosso di scadenza.

​

Viste salvate

Salva la combinazione corrente di filtri e colonne come vista con nome usando Salva vista, passa da una vista all’altra con Seleziona una vista e reimposta con Cancella filtri. Le viste sono personali e vengono conservate allo stesso modo delle altre preferenze delle tabelle della console.

​

Azioni di massa

Seleziona più casi per:

• Assegna a un operatore. Tutti i casi selezionati devono condividere lo stesso blueprint: la console avvisa prima dell’invio se non è così.
• Imposta stato su In attesa dell’utente, Riapri o Risolvi (con una risoluzione e una nota facoltativa). Ogni caso viene valutato in modo indipendente: un caso bloccato da una checklist incompleta o da una nota obbligatoria mancante viene segnalato singolarmente, senza far fallire il resto del batch.

​

Esportazioni

Il menu dell’elenco offre due esportazioni CSV, consegnate tramite la pagina Report:

• Report di tutti i casi, una riga per caso con stato, risoluzione, priorità, tag, transazioni collegate e l’ultimo report FIU inviato.
• Report SLA, metriche temporali per caso: ore fino all’assegnazione, ore fino alla risoluzione, flag di ritardo e flag di SLA rispettato.

​

Azioni sul soggetto e nuovi tentativi

La scheda del soggetto permette ai revisori autorizzati di modificare lo stato del soggetto, aggiungere tag, aggiungere una nota interna o inserire il soggetto nella blocklist. Queste azioni sono separate dalla risoluzione del caso. La sezione Azioni sul soggetto registra ogni azione richiesta come Applicata o Fallita e indica il suo revisore e l’orario. Usa Riprova azione per ritentare un’azione fallita dopo aver verificato lo stato attuale del soggetto. Un’azione già applicata non viene eseguita di nuovo quando la sua richiesta viene ritentata. I client API dovrebbero inviare un client_reference univoco con ogni richiesta all’endpoint entity-actions/ del caso. Mantieni lo stesso riferimento e lo stesso input quando ritenti una richiesta dopo un errore di connessione. Un input modificato con lo stesso riferimento restituisce 409. Quando un riferimento è fornito, controlla receipt.status: una risposta 200 può contenere una ricevuta fallita, il che significa che l’azione non è stata applicata. Ritentare una richiesta fallita richiede retry: true, oppure una chiamata al suo endpoint action-receipts/{receipt_uuid}/retry/. L’endpoint della cronologia restituisce al massimo 20 ricevute per pagina e fornisce next_offset per ottenere risultati aggiuntivi. I client API esistenti che omettono client_reference mantengono il loro comportamento di risposta precedente.

​

Tag

Aggiungi tag a un caso dalla sua intestazione (Aggiungi tag) per raggruppare indagini correlate, oppure filtra e cerca per tag dall’elenco. Le modifiche ai tag vengono registrate nella cronologia del caso.

​

Pagine correlate

​

Messaggi al cliente

Usa Invia messaggio per visualizzare in anteprima una richiesta predefinita o un aggiornamento della revisione destinato a un contatto verificato. Consulta Messaggi al cliente per gli stati di consegna, le risposte sicure e il workflow API.

​

Discussione e note fissate

Apri la discussione tramite il pulsante accanto allo stato del caso per consultare le note senza interrompere l’indagine. Usa il menu di una nota per rispondere o fissarla. Le note fissate compaiono per prime, e le risposte mostrano un breve estratto della nota originale. Le modifiche relative al fissaggio delle note vengono registrate nell’attività del caso e non modificano le decisioni della fonte. La conferma dell’eliminazione rimuove in modo permanente la nota e l’estratto della nota citato nelle risposte. Le risposte restano disponibili. Gli allegati vengono eliminati, a meno che un’altra nota ne faccia ancora uso. I client API possono fornire un UUID client_reference quando aggiungono una nota. Un nuovo tentativo senza modifiche restituisce la nota esistente senza duplicare le notifiche. Riutilizzare quel riferimento per contenuti modificati o per una nota eliminata restituisce 409. Fornisci reply_to per fare riferimento a una nota attiva nello stesso caso, e aggiorna is_pinned tramite l’endpoint PATCH della nota.

​

Verifica di un’indagine esistente

La finestra di dialogo condivisa Crea caso verifica la presenza di indagini esistenti per l’utente, l’azienda o la fonte collegata selezionata. Apri un caso esistente per continuare a esaminarlo. I casi chiusi restano visibili, così puoi aprirli e decidere se riaprirli. Per creare un’indagine separata, inserisci un motivo per trattarla come un incidente diverso. Il motivo viene salvato con il nuovo caso e mostrato nella sua panoramica. La console ricontrolla i duplicati quando invii, inclusi i casi creati da un altro revisore mentre la finestra di dialogo era aperta. Le integrazioni API possono consultare POST .../cases/duplicates/ e impostare review_duplicates=true alla creazione del caso. Quando viene trovata un’indagine esistente, la creazione restituisce 409, a meno che non sia fornito separate_incident_reason. L’endpoint di revisione dei duplicati restituisce fino a 20 casi per pagina, con next_offset per ottenere altri risultati. Le integrazioni API esistenti che omettono l’opzione mantengono il comportamento attuale di creazione.