Règles de décision et seuils

Chaque contrôle produit des avertissements, et vous décidez ce que fait chaque avertissement - approuver, mettre en revue, ou refuser. Cette correspondance est l'endroit où votre appétit pour le risque se joue vraiment.

Rédigé par le support Didit · Mis à jour le 19 août 2026

#Où les décisions se prennent vraiment

Il est tentant de penser à un workflow comme "les contrôles que j'exécute". Les contrôles n'en représentent que la moitié. L'autre moitié, celle qui détermine votre taux d'approbation, c'est ce que les avertissements de chaque contrôle sont configurés pour faire.

123

1. Chaque nœud de fonctionnalité porte ses propres seuils et sa propre décision.
2. Un contrôle peut être obligatoire ou facultatif, ce qui est en soi une décision sur qui passe.
3. Une règle modifiée atteint les nouvelles sessions une fois le workflow enregistré.

Pour chaque étape, chaque avertissement qu'elle peut soulever correspond à l'une de ces trois actions :

Cette correspondance, c'est votre politique, exprimée en configuration.

#Un refus arrête le workflow

C'est le comportement qui surprend le plus les gens, donc il vaut la peine d'être explicite : quand une étape refuse, l'exécution s'arrête là. Les étapes suivantes ne s'exécutent jamais.

Deux conséquences :

1. Le résultat manquera de contrôles que vous attendiez. Ils n'ont pas échoué : ils ne se sont jamais exécutés. Une session refusée à la vérification d'identité n'aura ni preuve de vie, ni correspondance faciale, ni AML.
2. Vous n'êtes pas facturé pour eux. La facturation se fait par fonctionnalité complétée, donc une étape qui ne s'est jamais exécutée ne coûte rien.

#Utiliser l'ordre des règles pour contrôler le coût

Comme un refus arrête le flux, l'ordre des étapes est un levier de dépense. Placer un contrôle de risque bon marché devant un ensemble coûteux signifie que le trafic qui n'allait de toute façon jamais passer s'arrête avant que vous ne payiez pour la partie coûteuse.

L'analyse d'appareil et d'IP à 0,03 $ devant un flux KYC complet est l'exemple classique : elle filtre le trafic que vous auriez de toute façon rejeté, à moindre coût.

#Des règles qui demandent du jugement, pas de l'automatisation

Certains avertissements sont sans ambiguïté et devraient refuser : une somme de contrôle MRZ échouée, une puce dont la signature ne remonte pas jusqu'à son émetteur, un visage sur votre liste de blocage. Ce sont des échecs d'intégrité.

D'autres sont presque toujours mieux traités en revue :

• Correspondances d'adresse partielles sur un justificatif de domicile - les formats varient selon les pays.
• Correspondances de nom partielles sur la validation de base de données - les sources faisant autorité enregistrent les noms différemment.
• Correspondances AML candidates à faible confiance - les noms courants en génèrent constamment.
• Une correspondance faciale limite - voir scores et seuils de correspondance faciale.
• Un signalement de visage en double - ce qui est de la fraude pour un nouveau compte et normal pour un client qui revient.

Et certains sont des échecs d'utilisabilité qui méritent une nouvelle tentative, pas un verdict : une puce NFC non lue, une capture floue, une image de caméra perdue.

#Politiques d'âge

L'âge minimum et maximum se configurent par workflow, et l'action en cas de violation est à votre choix. MINIMUM_AGE_NOT_MET peut refuser directement, ou orienter vers la revue si votre politique permet une exception avec preuve à l'appui. Les deux sont légitimes ; choisissez délibérément.

#Règles personnalisées sur les données extraites

Au-delà de la correspondance par avertissement, vous pouvez écrire des règles portant sur les données qu'une étape a extraites - par exemple, refuser quand un champ extrait prend une valeur particulière. Deux choses à garder en tête :

• La règle ne peut agir que sur des données que l'étape a réellement produites. Si l'OCR n'a pas extrait le champ, la règle n'a rien à évaluer.
• Une règle qui refuse arrête quand même le workflow, avec les mêmes conséquences que ci-dessus.

Si vous construisez une règle qui se déclenche sur une caractéristique protégée, traitez cela comme une question juridique pour votre équipe conformité avant que ce ne soit une question technique.

#Testez les règles, pas seulement les étapes

Les étapes d'un workflow sont faciles à vérifier à l'œil. Ses règles ne le sont pas : la seule façon de savoir qu'un avertissement s'oriente là où vous le pensez est de produire cet avertissement.

Le sandbox existe pour cela. Chaque scénario force un avertissement spécifique, donc vous pouvez confirmer l'action de chaque règle de bout en bout : decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match, et ainsi de suite. Voir tester en sandbox.

#Les changements s'appliquent aux nouvelles sessions

Modifier un workflow ne change pas rétroactivement les sessions déjà créées. Une session conserve la configuration avec laquelle elle a été créée, donc après un changement de règle, testez avec une nouvelle session plutôt que de revérifier une ancienne.