Gestion des dossiers - Dossiers et cycle de vie

Gestion des dossiers est le centre d’investigation de la console Didit. Chaque alerte AML, chaque vérification signalée ou chaque transaction suspecte peut devenir un dossier sur lequel votre équipe de conformité travaille, de l’ouverture à la résolution, avec une piste d’audit complète.

---

​

Cycle de vie

Un dossier passe par exactement trois statuts : Résoudre un dossier nécessite une résolution : Chaque dossier porte également une priorité (Low, Medium, High, valeur par défaut Medium) et une date d’échéance facultative qui pilote le tri par SLA et les indicateurs de retard.

​

Un seul sujet par dossier

Chaque dossier est rattaché à exactement un utilisateur ou à une seule entreprise. Vous ne pouvez pas mélanger des sujets sur un même dossier, et vous ne pouvez pas associer une session, une session d’entreprise ou une transaction qui appartient à un sujet différent de celui du dossier : une erreur explicite est alors renvoyée. Cela garantit que chaque page de dossier reste centrée : la fiche du sujet, la vue d’ensemble des risques, les documents et les données financières décrivent tous la même personne ou la même entreprise que celle étudiée dans le dossier. Pour examiner une deuxième entité, ouvrez un dossier distinct (ou créez-en un).

​

Contexte source Fraud Check

La création d’un dossier à partir d’une session Fraud Check conserve son identifiant de contrôle, son identifiant de requête et la section que le réviseur a ouverte. La fiche source enregistre également le statut d’analyste de la session au moment de la création du dossier. La décision du dossier et la décision source restent distinctes. Les clients API peuvent fournir source_context avec check_id, request_id et source_section lors de la création d’un dossier. Incluez cette requête sous forme d’entrée session dans links. Le contrôle et la session liée doivent appartenir à l’application sélectionnée et appartenir l’un à l’autre. L’API lit elle-même le statut d’analyste et rejette, dans ce contexte, les champs de statut, de recommandation ou de type de source fournis par l’appelant.

​

Listes

La gestion des dossiers conserve Dossiers, Vue d’ensemble et Attribution disponibles dans sa navigation supérieure. L’espace Dossiers propose les vues par statut Ouverts, En attente d’utilisateur, Résolus et Tous. Lorsque vous ouvrez un dossier, la file des dossiers reste affichée à côté de ses détails sur ordinateur. Sur mobile, utilisez le fil d’Ariane pour revenir à la file. La recherche porte sur le nom ou l’identifiant du sujet, le tag, le numéro de dossier, le titre du dossier, l’identifiant de la session liée et l’identifiant de la transaction liée. Vous pouvez donc coller un UUID de session ou de transaction et accéder directement au dossier correspondant. Puces de filtre : Modèle, Créée, Source, Assigné, Étiquette, ainsi que Ajouter un filtre pour Priorité et Échéance. Colonnes : Créé (date et créateur), Détails du dossier (titre), Statut, Modèle, Sujet (nom et identifiant), Tags du sujet, Assigné, Priorité et Date d’échéance, avec d’autres colonnes accessibles par défilement horizontal et par la configuration des colonnes.

​

Tri et SLA

Triez par Créé le (par défaut) ou par Date d’échéance. Le tri par date d’échéance fait remonter en premier les dossiers en retard : un dossier est en retard dès que sa date d’échéance est dépassée alors qu’il est encore Ouvert ou En attente d’utilisateur, et il est alors signalé par une puce d’échéance rouge.

​

Vues enregistrées

Enregistrez la combinaison actuelle de filtres et de colonnes sous forme de vue nommée avec Enregistrer la vue, passez d’une vue à l’autre avec Sélectionner une vue, et réinitialisez avec Effacer les filtres. Les vues sont personnelles et sont conservées de la même manière que les autres préférences de tableau de la console.

​

Actions groupées

Sélectionnez plusieurs dossiers pour :

• Assigner à un responsable. Tous les dossiers sélectionnés doivent partager le même modèle ; la console affiche un avertissement avant l’envoi si ce n’est pas le cas.
• Définir le statut sur En attente d’utilisateur, Rouvrir ou Résoudre (avec une résolution et une note facultative). Chaque dossier est évalué indépendamment : un dossier bloqué par une liste de contrôle incomplète ou par une note obligatoire manquante est signalé individuellement, sans faire échouer le reste du lot.

​

Exports

Le menu de la liste propose deux exports CSV, livrés via la page Rapports :

• Rapport de tous les dossiers, une ligne par dossier avec le statut, la résolution, la priorité, les tags, les transactions liées et le dernier rapport FIU déposé.
• Rapport SLA, mesures de délai par dossier : heures jusqu’à l’assignation, heures jusqu’à la résolution, indicateurs de retard et indicateurs de respect du SLA.

​

Actions sur le sujet et nouvelles tentatives

La fiche du sujet permet aux réviseurs autorisés de modifier le statut du sujet, d’ajouter des tags, d’ajouter une note interne ou d’ajouter le sujet à la liste de blocage. Ces actions sont distinctes de la résolution du dossier. La section Actions sur le sujet enregistre chaque action demandée comme Appliquée ou Échouée et indique son réviseur ainsi que l’heure. Utilisez Réessayer l’action pour réessayer une action échouée après avoir examiné l’état actuel du sujet. Une action appliquée n’est pas exécutée à nouveau lorsque sa requête est réessayée. Les clients API doivent envoyer une client_reference unique avec chaque requête vers l’endpoint entity-actions/ du dossier. Conservez la même référence et la même entrée lorsque vous relancez une requête après une erreur de connexion. Une entrée modifiée avec la même référence renvoie 409. Lorsqu’une référence est fournie, vérifiez receipt.status : une réponse 200 peut contenir un reçu en échec, ce qui signifie que l’action n’a pas été appliquée. Réessayer une requête en échec exige retry: true, ou un appel à son endpoint action-receipts/{receipt_uuid}/retry/. L’endpoint d’historique renvoie au plus 20 reçus par page et fournit next_offset pour obtenir les résultats supplémentaires. Les clients API existants qui omettent client_reference conservent leur comportement de réponse précédent.

​

Tags

Ajoutez des tags à un dossier depuis son en-tête (Ajouter un tag) pour regrouper les enquêtes liées, ou filtrez et recherchez par tag depuis la liste. Les modifications de tags sont enregistrées dans la chronologie du dossier.

​

Pages connexes

​

Messages au client

Utilisez Envoyer un message pour prévisualiser une demande prédéfinie ou une mise à jour de l’examen destinée à un contact vérifié. Consultez Messages au client pour les états de livraison, les réponses sécurisées et le workflow API.

​

Discussion et notes épinglées

Cliquez sur le bouton de discussion situé à côté du statut du dossier pour consulter les notes sans interrompre l’enquête. Utilisez le menu d’une note pour y répondre ou l’épingler. Les notes épinglées apparaissent en premier, et les réponses affichent un court extrait de leur note parente. Les modifications d’épinglage sont consignées dans l’activité du dossier et ne modifient pas les décisions d’origine. La confirmation de suppression retire définitivement la note et son extrait cité dans les réponses. Les réponses elles-mêmes restent disponibles. Les pièces jointes sont supprimées, sauf si une autre note les utilise encore. Les clients API peuvent fournir un UUID client_reference lors de l’ajout d’une note. Une nouvelle tentative sans modification renvoie la note existante sans dupliquer les notifications. Réutiliser cette référence pour un contenu modifié ou pour une note supprimée renvoie 409. Indiquez reply_to pour référencer une note active dans le même dossier, et mettez à jour is_pinned via l’endpoint PATCH de la note.

​

Vérifier l’existence d’une enquête

La boîte de dialogue partagée de création de dossier vérifie l’existence d’enquêtes pour l’utilisateur, l’entreprise ou la source liée sélectionnés. Ouvrez un dossier existant pour poursuivre son examen. Les dossiers clôturés restent visibles afin que vous puissiez les ouvrir et décider s’il faut les rouvrir. Pour créer une enquête distincte, saisissez une raison expliquant pourquoi il s’agit d’un incident différent. La raison est enregistrée avec le nouveau dossier et affichée dans sa vue d’ensemble. La console vérifie à nouveau les doublons lors de la soumission, y compris les dossiers créés par un autre réviseur pendant que la boîte de dialogue était ouverte. Les intégrations API peuvent consulter POST .../cases/duplicates/ et définir review_duplicates=true lors de la création d’un dossier. Lorsqu’une enquête existante est trouvée, la création renvoie 409, sauf si separate_incident_reason est fourni. L’endpoint de revue des doublons renvoie jusqu’à 20 dossiers par page, avec next_offset pour obtenir davantage de résultats. Les intégrations API existantes qui omettent cette option conservent leur comportement de création actuel.