Concevoir une politique de risque

Ce que cela permet de faire

Le concepteur de politiques de workflow vous permet de décider comment une vérification est approuvée, rejetée ou envoyée à un examen manuel — visuellement, sans code. Vous faites glisser des blocs de règles sur un canevas, définissez des conditions sur les signaux produits par chaque vérification (score de confiance, correspondance avec les sanctions, contrôles de documents, pays du demandeur, risque réseau, preuve de caméra en direct, et plus encore), puis reliez-les aux issues Approuver, Rejeter, Escalader ou Exiger une vérification en direct.

Chaque organisation démarre avec une politique par défaut intégrée, qui reproduit exactement la décision standard fondée sur le score de confiance à 17 facteurs de Certivant. Activer la fonctionnalité ne change donc rien tant que vous ne choisissez pas de la personnaliser : vos résultats existants restent identiques.

Avant de commencer

• Votre forfait doit inclure le concepteur de politiques de workflow (Pro ou supérieur). Si l'élément Politiques de workflow du menu Développeur affiche un badge « Requiert Pro », demandez au propriétaire de votre compte de passer à un forfait supérieur — voir Facturation et crédits.
• Vous devez comprendre comment une vérification est notée, afin de savoir sur quels signaux écrire vos règles. Voir Examiner les demandes de vérification.
• Publier une politique modifie la manière dont les futures vérifications sont décidées pour toute votre organisation. Cela ne re-décide pas les demandes passées.

Concepts clés

• Nœuds — les blocs du canevas. Un nœud Début lance le flux ; les nœuds Condition contiennent les règles ; les nœuds Fin sont les issues (Approuvée / Rejetée / Escaladée / Examen manuel / Exiger une vérification en direct / Transmettre à une autre politique). Les nœuds d'action (Formulaire, Validation d'identité, Courriel, SMS, Webhook, Conférence en direct) documentent les étapes d'orchestration autour de la décision — pour exécuter des étapes, utilisez les Workflows d'automatisation.
• Conditions — un nœud Condition teste les signaux de la vérification, par exemple overallScore >= 75, sanctions.isMatch = true, applicant.country IN ["IR","KP","SY"] ou redFlags CONTAINS "network_vpn_detected". Vous pouvez combiner les tests avec AND / OR / NOT et imbriquer des groupes — y compris des conditions enchaînées derrière d'autres conditions sur le canevas.
• La première correspondance l'emporte — les règles sont évaluées de haut en bas à partir du Début ; la première Condition dont le test est vrai fournit la décision. Un repli final capte tout le reste (il bascule en sécurité vers Escalader, jamais vers une approbation silencieuse).
• Motifs — attribuez à une condition un motif (par exemple « Pays à haut risque »). Il est enregistré avec la décision : l'examinateur voit pourquoi la demande a été escaladée, et pas seulement quelle règle s'est déclenchée.
• Versions — chaque politique enregistrée est un brouillon tant que vous ne l'avez pas publiée. La publication fige cette version (elle devient immuable) et la rend active ; la version précédemment active de cette politique est archivée. Pour modifier une politique publiée, cliquez sur Nouvelle version — vous disposez ainsi toujours d'un historique complet et vérifiable.
• Champ d'application — une politique publiée décide des demandes de chaque formulaire qui lui est rattaché. Faites d'une politique la politique par défaut de l'organisation pour qu'elle décide aussi de toutes les autres demandes, y compris celles créées via l'API. Sans aucune des deux, la politique intégrée de Certivant décide.

Étapes

Ce qui déclenche votre politique

Une politique de workflow s'exécute automatiquement : il n'existe pas de bouton « exécuter » séparé, et vous ne la déclenchez pas à la main. Deux éléments l'arment et la font fonctionner :

1. La publication l'arme. Lorsque vous publiez une politique, cette version devient active (une seule version active par politique ; la publication archive la précédente). Elle décide des demandes de chaque formulaire qui lui est rattaché — et de toutes les autres demandes, une fois que vous en faites la politique par défaut de l'organisation.
2. Chaque nouvelle vérification la déclenche. Chaque fois qu'une vérification s'exécute — un demandeur soumet ses documents, vous envoyez une demande de vérification, ou un examinateur clique sur Revérifier —, Certivant exécute l'ensemble du pipeline de contrôles (OCR, biométrie, sanctions, fraude, contrôles réseau et de capture, score de confiance à 17 facteurs), puis transmet les résultats à la politique décisionnelle. Le verdict de la politique (Approuver / Rejeter / Escalader / Exiger une vérification en direct) devient le statut final de la demande.

Politique qui décide d'une demande, dans l'ordre :

1. la politique rattachée au formulaire ;
2. sinon, la politique par défaut de l'organisation ;
3. sinon, la politique intégrée de Certivant.

Une politique rattachée ou par défaut sans version active (par exemple, si vous l'avez archivée) revient à la politique intégrée — jamais à une autre politique.

flowchart LR
    A[Applicant submits<br/>verification] --> B[Checks run:<br/>OCR · biometrics ·<br/>sanctions · fraud]
    B --> C[17-factor<br/>trust score]
    C --> D{Active policy<br/>evaluates the<br/>score + signals}
    D -->|first matching rule| E[Approve]
    D --> F[Reject]
    D --> G[Escalate to<br/>manual review]

Comment cela modifie vos vérifications

Après publication, chaque nouvelle vérification est décidée par votre politique active plutôt que par la politique par défaut intégrée. Pour chaque demande, Certivant enregistre :

• l'identifiant, le nom et la version de la politique qui l'a décidée, et
• la liste des règles déclenchées —

le tout dans le journal d'audit de la demande et dans la charge utile du webhook (data.policy sur kyc.request.approved / rejected / escalated). Vos systèmes en aval peuvent ainsi voir quelle politique et quelles règles ont guidé chaque décision. Voir Webhooks.

Lorsqu'une mesure de sécurité ultérieure modifie l'issue de la politique — une demande KYB encore en attente de son contrôle au registre, ou une demande en mode test —, le journal d'audit enregistre ce remplacement et le statut final, de sorte que la piste ne montre jamais une décision qui n'a pas été retenue.

Exiger une vérification en direct

Choisissez Exiger une vérification en direct comme issue d'un nœud Fin pour envoyer une demande vers un appel vidéo au lieu de la décider sur les seuls documents — par exemple lorsque le score est limite, que le demandeur utilise un VPN, ou que le selfie n'a pas pu être prouvé comme provenant de la caméra en direct :

overallScore >= 60 AND overallScore < 80 → Require live verification
network.vpn = true OR capture.tokenMismatch = true → Require live verification

La demande passe à Escaladée, et sa page affiche une bannière Vérification Live ID requise accompagnée du motif de la règle, afin que votre équipe sache qu'elle doit réserver l'appel. Le webhook transporte data.policy.decision = "live_verification" et liveVerificationRequired: true.

Pour réserver l'appel automatiquement, ajoutez un Workflow d'automatisation sur le déclencheur Vérification en direct requise avec l'action Planifier une vérification d'identité en direct. Une fois que l'hôte a enregistré une décision pendant l'appel, la demande est approuvée ou rejetée, et les événements habituels approuvée / rejetée sont déclenchés. Lors d'une revérification ultérieure, la politique peut lire le résultat de l'appel — par exemple liveVerification.hostDecision = "approved" — de sorte qu'une règle puisse approuver une demande ayant réussi son contrôle en direct.

Signaux que vous pouvez tester

Outre le score de confiance et les résultats par contrôle (checks.*, sanctions.*, document.*, applicant.*), une condition peut lire :

Un champ absent de la demande (aucun appel tenu, aucun code-barres lu…) ne correspond jamais — pas même à !=, NOT IN ou NOT CONTAINS. Ainsi, document.issuingCountry != "US" est faux lorsqu'aucun document n'a été lu, au lieu d'être silencieusement vrai.

Options et champs

Dépannage

Je ne vois pas « Politiques de workflow » dans le menu

Cet élément se trouve dans le menu Développeur et constitue une fonctionnalité Pro. Si l'élément Politiques de workflow affiche un badge « Requiert Pro », votre forfait ne l'inclut pas : demandez à votre propriétaire de passer à un forfait supérieur sur Facturation et crédits. Si le menu Développeur est totalement absent, vous n'êtes peut-être pas administrateur ou propriétaire ; si l'élément a simplement disparu, actualisez la page — la vérification du forfait est mise en cache pendant quelques minutes.

Je ne peux pas modifier une politique — les champs sont verrouillés

Les versions publiées sont immuables par conception. Ouvrez la version et cliquez sur Nouvelle version dans la barre d'outils : elle copie la politique dans le brouillon modifiable suivant. Effectuez vos modifications et publiez — la version précédente continue de décider jusqu'à ce que vous le fassiez.

Le bouton Simuler est désactivé

La simulation exige que la politique ait été enregistrée au moins une fois. Cliquez sur Enregistrer le brouillon ; ensuite, la simulation exécute ce qui figure sur le canevas, y compris les modifications non enregistrées.

Ma politique publiée ne décide de rien

Une politique publiée ne décide que des demandes des formulaires qui lui sont rattachés. Rattachez-la au formulaire (paramètres du formulaire → Politique de décision), ou cliquez sur Utiliser pour toutes les demandes dans l'éditeur pour en faire la politique par défaut de l'organisation.

Une demande a été escaladée avec « Vérification Live ID requise »

Votre politique a correspondu à une règle Exiger une vérification en direct — la bannière de la demande indique le motif de la règle. Réservez un appel en direct depuis la page de la demande, ou automatisez-le avec un workflow (voir Exiger une vérification en direct).

Une condition affiche un badge rouge « invalide »

L'expression n'a pas pu être analysée. Ouvrez la condition, vérifiez le nom du champ et l'opérateur, et assurez-vous que les valeurs de liste sont séparées par des virgules. L'onglet DSL brut affiche le message exact de l'analyseur.

Comment déclencher mon workflow ? Quand s'exécute-t-il ?

Vous ne le déclenchez pas manuellement. Une fois publiée et rattachée à un formulaire (ou définie comme politique par défaut de l'organisation), elle s'exécute automatiquement sur chaque nouvelle vérification qu'elle couvre — lorsqu'un demandeur soumet ses documents, lorsque vous envoyez une demande de vérification, ou lorsqu'un examinateur clique sur Revérifier. Voir Ce qui déclenche votre politique.

J'ai publié, mais rien ne semble se produire

Trois causes fréquentes. D'abord, une politique ne décide que des vérifications qui s'exécutent après son activation : les demandes existantes et déjà terminées ne sont pas touchées (voir plus bas). Lancez une nouvelle vérification (ou Revérifiez une vérification existante) pour voir votre politique la décider. Ensuite, vérifiez que la version que vous avez modifiée affiche bien le statut actif dans le tableau de bord — enregistrer un brouillon ne l'active pas ; vous devez Publier. Enfin, vérifiez que le formulaire de la demande rattache la politique, ou que celle-ci est la politique par défaut de l'organisation.

La publication n'a rien changé pour une demande en cours

Les politiques ne décident que des nouvelles vérifications. Une demande déjà soumise conserve la décision prise par la politique active à l'époque. Ne la relancez que si vous voulez la re-décider : ouvrez la demande et utilisez Revérifier.

Historique des versions, restauration et tests A/B

Chaque enregistrement d'une politique publiée crée une nouvelle version brouillon ; Publier la fige en version immuable et archive celle qu'elle remplace. Chaque décision enregistre l'identifiant et la version exacts de la politique qui l'a prise (sur la demande, dans le journal d'audit et dans le bloc policy de la charge utile du webhook) : vous voyez donc toujours quelle version a décidé une vérification.

Cliquez sur Versions et test A/B dans l'en-tête de l'éditeur pour :

• Voir chaque version de la politique — brouillon, active et archivée — et en ouvrir une en lecture seule.
• Restaurer comme nouveau brouillon — copie une version antérieure dans un nouveau brouillon du même nom. Publiez-la lorsque vous voulez la mettre en service. Rien de ce qui a été publié n'est jamais modifié.
• Lancer un test A/B — compare la version active (variante A) avec un challenger (variante B, un brouillon ou une ancienne version de la même politique). Choisissez la part des nouvelles vérifications acheminée vers B (0 à 100 %) ; le reste reste sur A. La répartition est automatique et stable : une vérification tombe toujours sur la même variante, même si elle est relancée.

Pendant qu'un test est en cours, le brouillon challenger est figé (le modifier invaliderait la comparaison). Le tableau Résultats indique, par variante, le nombre de vérifications acheminées, la part approuvée, rejetée et escaladée, et le nombre ayant abouti à une décision. La comparaison des taux d'approbation n'est déclarée « significative » qu'à partir de 30 vérifications décidées par variante. Pour adopter B, publiez le challenger : le test se termine automatiquement. Pour l'abandonner, cliquez sur Arrêter le test ; chaque nouvelle vérification revient à la version active.

Voir aussi

• Examiner les demandes de vérification — les signaux que vos règles testent proviennent de là.
• Webhooks — le bloc policy ajouté aux événements de décision.
• Workflows d'automatisation — réagir à la décision : réserver l'appel en direct, notifier, acheminer.
• Vérification d'identité en direct — l'appel vidéo qu'une règle Exiger une vérification en direct réclame.
• Facturation et crédits — passez à un forfait supérieur pour débloquer le concepteur de politiques.