Gestió de casos - Casos i cicle de vida

La Gestió de casos és el centre d’investigació de la Didit Console. Qualsevol coincidència AML, verificació marcada o transacció sospitosa pot convertir-se en un cas amb el qual el teu equip de compliment treballa des de l’obertura fins a la resolució, amb un registre d’auditoria complet.

---

​

Cicle de vida

Un cas passa per exactament tres estats: Per resoldre un cas cal una resolució: Cada cas també té una prioritat (Low, Medium, High, per defecte Medium) i una data de venciment opcional que determina l’ordenació per SLA i els indicadors de retard.

​

Un subjecte per cas

Cada cas està vinculat a exactament un usuari o a una empresa. No pots barrejar subjectes en un mateix cas, i no pots adjuntar una sessió, una sessió empresarial o una transacció que pertanyi a un subjecte diferent del cas; si ho intentes, es retorna un error clar. Així cada pàgina de cas es manté centrada: la targeta del subjecte, el resum de risc, els documents i les dades financeres descriuen la mateixa persona o empresa que investiga el cas. Per revisar una segona entitat, obre (o crea) un cas separat.

​

Context d’origen de Fraud Check

En crear un cas des d’una sessió de Fraud Check, es conserven el seu ID de comprovació, l’ID de sol·licitud i la secció que el revisor ha obert. La targeta d’origen també registra l’estat d’analista de la sessió en el moment de crear el cas. La decisió del cas i la decisió d’origen continuen sent independents. Els clients de l’API poden subministrar source_context amb check_id, request_id i source_section en crear un cas. Inclou aquesta sol·licitud com a entrada session a links. La comprovació i la sessió vinculada han de pertànyer a l’aplicació seleccionada i estar vinculades entre si. L’API llegeix ella mateixa l’estat d’analista i rebutja en aquest context els camps d’estat, recomanació o tipus d’origen que envia el client.

​

Llistes

La Gestió de casos manté Casos, Resum i Assignació disponibles a la navegació superior. L’espai de treball de Casos ofereix les vistes d’estat Oberts, En espera de l’usuari, Resolts i Tots. En obrir un cas, la cua de casos es manté al costat dels detalls a l’escriptori. En mòbil, fes servir la ruta de navegació (fil d’Ariadna) per tornar a la cua. La cerca coincideix amb el nom o l’ID del subjecte, l’etiqueta, el número de cas, el títol del cas, l’ID de la sessió vinculada i l’ID de la transacció vinculada, de manera que pots enganxar un UUID de sessió o de transacció i anar directament al seu cas. Xips de filtre: Plantilla, Creada, Origen, Assignat, Etiqueta, més Afegeix un filtre per a Prioritat i Venciment. Columnes: Creada (data i creador), Detalls del cas (títol), Estat, Plantilla, Subjecte (nom i ID), Etiquetes del subjecte, Assignat, Prioritat i Data de venciment, amb més columnes disponibles mitjançant desplaçament horitzontal i la configuració de columnes.

​

Ordenació i SLA

Ordena per Data de creació (per defecte) o per Data de venciment. Ordenar per data de venciment mostra primer els casos vençuts: un cas està vençut quan la seva data de venciment ja ha passat mentre continua Obert o En espera de l’usuari, i es mostra amb una etiqueta vermella de venciment.

​

Vistes desades

Desa la combinació actual de filtres i columnes com a vista amb nom mitjançant Desa la vista, canvia entre vistes amb Selecciona una vista i restableix els filtres amb Esborra els filtres. Les vistes són personals i es conserven de la mateixa manera que les altres preferències de les taules de la consola.

​

Accions en lot

Selecciona diversos casos per:

• Assigna a un oficial. Tots els casos seleccionats han de compartir la mateixa plantilla; la consola avisa abans d’enviar si no és així.
• Estableix l’estat a En espera de l’usuari, Reobrir o Resoldre (amb una resolució i una nota opcional). Cada cas s’avalua de manera independent, de manera que un cas bloquejat per una llista de comprovació incompleta o per la falta d’una nota obligatòria es notifica individualment sense fer fallar la resta del lot.

​

Exportacions

El menú de la llista ofereix dues exportacions CSV, lliurades a través de la pàgina d’Informes:

• Informe de tots els casos, una fila per cas amb estat, resolució, prioritat, etiquetes, transaccions vinculades i l’últim informe FIU presentat.
• Informe de SLA, mètriques de temps per cas: hores fins a l’assignació, hores fins a la resolució, i indicadors de casos vençuts i de compliment de l’SLA.

​

Accions sobre el subjecte i reintents

La targeta del subjecte permet als revisors autoritzats canviar l’estat del subjecte, afegir etiquetes, afegir una nota interna o afegir el subjecte a la llista de bloqueig. Aquestes accions són independents de resoldre el cas. La secció Accions sobre el subjecte registra cada acció sol·licitada com a Aplicada o Fallida i n’identifica el revisor i l’hora. Fes servir Reintentar acció per reintentar una acció fallida després de revisar l’estat actual del subjecte. Una acció aplicada no s’executa de nou quan se’n reintenta la sol·licitud. Els clients de l’API han d’enviar un client_reference únic amb cada sol·licitud a l’endpoint entity-actions/ del cas. Mantén la mateixa referència i les mateixes dades d’entrada en reintentar una sol·licitud després d’un error de connexió. Unes dades d’entrada modificades amb la mateixa referència retornen 409. Quan se subministra una referència, revisa receipt.status: una resposta 200 pot contenir un rebut fallat, és a dir, que l’acció no s’ha aplicat. Per reintentar una sol·licitud fallida cal retry: true o una crida al seu endpoint action-receipts/{receipt_uuid}/retry/. L’endpoint d’historial retorna com a màxim 20 rebuts per pàgina i proporciona next_offset per obtenir més resultats. Els clients d’API existents que no envien client_reference mantenen el seu comportament de resposta anterior.

​

Etiquetes

Afegeix etiquetes a un cas des de la seva capçalera (Afegeix etiqueta) per agrupar investigacions relacionades, o filtra i cerca per etiqueta des de la llista. Els canvis d’etiqueta es registren a la línia de temps del cas.

​

Pàgines relacionades

​

Missatges al client

Utilitza Enviar un missatge al client per previsualitzar una sol·licitud fixa o una actualització de revisió per a un contacte verificat. Consulta Missatges al client per als estats de lliurament, les respostes segures i el flux de treball de l’API.

​

Discussió i notes fixades

Obre el botó de discussió al costat de l’estat del cas per revisar les notes sense interrompre la investigació. Utilitza el menú d’una nota per respondre-hi o fixar-la. Les notes fixades apareixen primer, i les respostes mostren un fragment breu de la nota original. Els canvis de fixació es registren a l’activitat del cas i no modifiquen les decisions d’origen. Confirmar l’eliminació elimina de manera permanent la nota i el fragment citat d’aquesta a les respostes. Les respostes continuen disponibles. Els adjunts s’eliminen tret que una altra nota encara els utilitzi. Els clients de l’API poden proporcionar un UUID client_reference en afegir una nota. Un reintent sense canvis retorna la nota existent sense duplicar les notificacions. Reutilitzar aquesta referència per a contingut modificat o per a una nota eliminada retorna 409. Proporciona reply_to per referenciar una nota vigent del mateix cas, i actualitza is_pinned mitjançant l’endpoint PATCH de la nota.

​

Comprovar si hi ha una investigació existent

El diàleg compartit de Crear cas comprova si hi ha investigacions existents per a l’usuari, l’empresa o la font enllaçada que hagis seleccionat. Obre un cas existent per continuar revisant-lo. Els casos tancats segueixen visibles perquè puguis obrir-los i decidir si els reobres. Per crear una investigació separada, introdueix un motiu per tractar-la com un incident diferent. El motiu es desa amb el nou cas i es mostra al seu resum. La consola torna a comprovar si hi ha duplicats en enviar el formulari, inclosos els casos creats per un altre revisor mentre el diàleg estava obert. Les integracions de l’API poden revisar POST .../cases/duplicates/ i establir review_duplicates=true en crear el cas. Quan es troba una investigació existent, la creació retorna 409 tret que es proporcioni separate_incident_reason. L’endpoint de revisió de duplicats retorna fins a 20 casos per pàgina, amb next_offset per obtenir més resultats. Les integracions d’API existents que no incloguin aquesta opció mantenen el comportament de creació actual.