Sessions bloquées en révision, et comment en réduire le nombre
En révision signifie que les contrôles automatiques sont terminés mais ont signalé quelque chose qu'une personne doit trancher. Cela ne se résout jamais tout seul. Voici comment vider la file d'attente et réduire le taux.
En révision ne se résout jamais tout seul. Cela signifie qu'un contrôle a signalé quelque chose et attend qu'une personne de votre équipe approuve, refuse, ou demande une resoumission. Si votre taux de révision est élevé, la cause est presque toujours un seuil réglé trop serré, pas de la fraude.
Didit ne relit pas les sessions. Une session En révision attend une personne de votre équipe, dans votre Console Business, et personne chez Didit ne la regarde. Il n'y a ni file d'attente côté Didit ni estimation de délai : elle reste En révision jusqu'à ce que quelqu'un de votre équipe décide.
De tous les statuts, En révision est celui qui génère le plus de demandes de support, pour une raison simple : cela donne l'impression que la plateforme travaille encore, alors qu'en réalité la plateforme a terminé et attend votre action.
#Ce que signifie réellement En révision
Tous les contrôles automatiques se sont exécutés. Au moins un a levé un avertissement que votre workflow oriente vers la révision plutôt que vers une décision automatique. La session se trouve maintenant dans votre file d'attente jusqu'à ce qu'un humain la résolve. Il n'y a pas de délai qui finit par trancher à votre place, et aucun moyen de faire réexécuter les contrôles par le système pour qu'il change d'avis lui-même.
#Résoudre une session
- Ouvrez la file d'attente de révision
Dans la Console Business, allez dans Vérifications et filtrez par statut En révision.
- Lisez les avertissements, pas seulement le statut
Ouvrez la session et regardez quel contrôle l'a signalée et ce que dit l'avertissement. C'est ce qui détermine ce que vous décidez réellement. Voir comment lire un résultat de vérification.
- Décidez
Approuvez, refusez, ou demandez une resoumission de la seule étape en échec. Ajoutez une note : elle intègre la piste d'audit.
- Informez votre backend
La décision déclenche un webhook
status.updated, si bien que votre système récupère l'état final sans que vous ayez à faire la réconciliation à la main.

- Filtrez sur Statut : En révision pour ne voir que ce qui attend une décision de votre part.
- La colonne Statut est là où apparaît En révision ; rien ne bouge tant que personne ne décide.
- Sélectionnez des lignes, puis Changer le statut pour approuver ou refuser en masse.
#Pourquoi votre taux de révision pourrait être élevé
Par ordre de probabilité approximatif :
- Seuils de correspondance faciale trop rapprochés. Si votre bande de révision est large, une variation d'éclairage ordinaire y tombe. Voir scores de correspondance faciale et seuils.
- Seuil de révision AML réglé sur un score de correspondance bas. Les noms courants génèrent des alertes candidates à des scores de correspondance faibles. Régler le seuil de révision trop bas envoie presque tout le monde en révision. Voir résoudre les alertes AML.
- Correspondances partielles de justificatif de domicile. Les formats d'adresse varient énormément selon le pays ; une différence d'abréviation se lit comme une correspondance partielle. Décidez délibérément si une correspondance partielle doit passer en révision ou être acceptée.
- Correspondances partielles de validation de base de données. Même cause : un nom enregistré différemment dans une source faisant autorité.
- Signalements de visage en double sur des utilisateurs récurrents légitimes. Si la même personne réelle se vérifie plus d'une fois, elle correspondra avec elle-même. Voir détection des doublons.
- Chaque avertissement orienté vers la révision « par précaution ». Tout réviser revient à ne rien réviser, car la file d'attente cesse d'être traitée. Choisissez les avertissements qui exigent réellement un jugement.
#Réorganiser le workflow pour réviser plus tôt et à moindre coût
Si votre flux est coûteux et que beaucoup de sessions finissent quand même en révision, déplacer les contrôles de risque bon marché en tête de flux fait que le flux s'arrête avant que les contrôles coûteux ne s'exécutent. L'analyse de l'appareil et de l'IP à 0,03 $, placée devant un flux KYC complet, réduira les dépenses sur un trafic qui n'allait jamais réussir.
Le compromis porte sur l'expérience utilisateur : une personne arrêtée dès la première étape n'a rien investi, mais elle n'apprend rien non plus sur les raisons. Décidez ce qui compte le plus pour votre entonnoir.
#Révision à quatre yeux
Si votre processus de conformité exige que deux personnes valident une décision, Didit prend en charge un flux à quatre yeux où un second réviseur doit confirmer. Voir révision à quatre yeux.
#Ce qu'En révision n'est pas
- Ce n'est pas « encore en traitement ». Si vous attendez que la plateforme termine, le statut que vous cherchez est En cours.
- Ce n'est pas un refus déguisé. Une session En révision n'a encore aucun verdict, donc ne la mappez pas à « rejetée » dans votre propre système : mappez-la à son propre statut en attente.
- Ce n'est pas quelque chose que le support peut décider à votre place. Seule votre équipe a l'autorité d'approuver ou de refuser votre propre client. Le support peut expliquer pourquoi une session a été signalée, et aura besoin du
session_idpour le faire.
#La surveillance continue peut renvoyer une session approuvée en révision
Si vous avez activé la surveillance AML, une session précédemment approuvée peut passer En révision plus tard, quand un rebalayage quotidien trouve une nouvelle alerte qui franchit votre seuil de révision. C'est un comportement attendu, pas une régression, et c'est tout l'intérêt de la surveillance. Voir surveillance AML continue.
