Comment les graphes de décision transforment les vérifications en approbation, examen ou refus

Un flux de travail détermine un résultat en deux étapes. Dans un premier temps, les vérifications s'exécutent et consignent les faits : le document a été lu, la référence au registre gouvernemental a été trouvée, le selfie a obtenu un score de 71 par rapport à la photo du registre, et la liste de surveillance a détecté une correspondance potentielle. Ensuite, le graphe de décision du flux de travail analyse ces faits, suit les branches que vous avez tracées et aboutit à l'approbation , à la vérification ou au refus . Les vérifications ne décident jamais de l'intégration d'une personne ; c'est le graphe qui prend cette décision.

Le fait de séparer ces étapes est utile. Les faits restent fixes et vérifiables, et la politique qui les interprète est centralisée et modifiable par simple publication. Cet article explique le fonctionnement d'une exécution. Toden Flux de travail et comment concevoir un graphe qui envoie les cas appropriés à une personne.

Que se passe-t-il lorsqu'une vérification est terminée ?

Lorsqu'une vérification atteint un état terminal, le moteur lance une exécution . Selon la documentation de décision (s’ouvre dans un nouvel onglet) , une exécution comprend quatre actions :

1. Collecte les données : le résultat de la vérification, l’entité du client et son identité liée, tous les résultats de filtrage et les signaux d’intelligence de l’appareil.

2. Parcourt le graphe à partir du nœud de départ, en évaluant chaque branche et en exécutant chaque action.

3. Atterrit sur un nœud d'état terminal, qui détermine le résultat.

4. Enregistre le chemin parcouru, la trace, et envoie leworkflow.run.completedwebhook.

Il y a une exécution par vérification, et les exécutions sont idempotentes, donc une vérification qui est réessayée ou retraitée n'est jamais décidée deux fois.

Les quatre types de nœuds

Vous pouvez créer le graphique sous forme de simple liste de règles ordonnées ou sur un canevas plus avancé. La liste de règles convient à la plupart des politiques d'intégration, qui consistent en une séquence d'instructions « si ceci, alors cela » avec une valeur par défaut à la fin.

Ce qu'une branche peut lire

Les conditions lisent un espace de noms fermé de champs, regroupés selon la provenance du fait :

• verification.*: le résultat du contrôle, tel questatus,reasonCode,assuranceLevel(chip,gov_dboudocument),facialMatch,facialConfidence,facialMatchSource,ageetdocumentExpired.

• entity.*etidentity.*: le niveau de risque et la disposition du client, ainsi que l'état de confiance de l'identité liée.

• screening.*: si une correspondance a été trouvée dans une liste de surveillance, si une correspondance est confirmée, le statut de chaque type de filtre et le score de correspondance le plus élevé.

• device.*etip.*: Informations sur l'appareil, comme le nombre d'autres personnes ayant utilisé le même appareil et si l'adresse IP appartient à un centre de données.

• email.*etphone.*: résultats de la vérification des contacts.

• business.*etkeyPeople.*: vérification de l'entreprise et diligence raisonnable concernant ses principaux collaborateurs.

• questionnaire.<key>: réponses à tout questionnaire du flux.

Les opérateurs sonteq,neq,gt,gte,lt,lte,in,nin,containsetexists, combiné avecall,anyetnot.

Deux règles régissent la rédaction des conditions. Premièrement, un champ inexistant dans l'espace de noms est rejeté lors de la publication ; une faute de frappe est donc immédiatement détectée, contrairement à une règle qui ne serait jamais appliquée silencieusement. Deuxièmement, une valeur nulle entraîne l'échec de la comparaison. Si une vérification n'est pas fiable car aucune comparaison n'a été effectuée,verification.facialConfidence gte 80est faux, pas vrai. Lorsque l'absence est importante, testez-la explicitement avecexists.

Ce qu'un résultat change, et ce qu'il ne change pas.

Un nœud d'état définit la disposition de l'entité , la décision de conformité concernant la personne ou l'entreprise :

Il ne remplace jamais le résultat de la vérification elle-même. Une vérification dont les contrôles ont échoué reste considérée comme ayant échoué.checkStatusmême si votre graphique l'approuve, et la ligne supérieurestatusL'approbation est consignée. C'est ainsi qu'un auditeur peut ultérieurement constater l'exception et le fait qu'elle a été levée.

Votre serveur reçoit le résultat surworkflow.run.completedet surverification.status_updatedavecsource: "workflow"Chaque fois que le verdict modifie le statut de la vérification, les actions que vous entreprenez (accorder l'accès, gérer le compte, etc.) relèvent de votre code.

Un graphique détaillé pour un organisme de crédit à la consommation

Prenons l'exemple d'un organisme de prêt hypothétique qui recrute des particuliers au Nigéria avec un processus qui se déroule comme suit : AML sélection. Sa politique, formulée sous forme de liste de règles ordonnées, pourrait se présenter ainsi :

1. Attendez la fin du contrôle, dans la limite d'un délai imparti.

2. Siscreening.confirmedc'est vrai, déclin .

3. Siscreening.anyMatchC'est vrai, ouvrez un dossier , puis examinez-le .

4. Siverification.statusn'est pasVERIFIED, déclin .

5. Sidevice.matchedEntitiesest 2 ou plus, révision .

6. Siverification.facialMatchSourceestdocument, revoir .

7. Siverification.assuranceLevelest danschipougov_db, approuver .

8. Sinon, révisez .

L'arrêté contient la politique en vigueur. La vérification préalable est la première étape, car une correspondance confirmée avec une liste de surveillance devrait entraîner le refus d'une personne dont les documents sont irréprochables. La vérification de l'appareil intervient avant l'approbation, car un téléphone utilisé par plusieurs autres demandeurs mérite d'être examiné, même si la vérification individuelle est concluante. La règle 6 existe car un selfie correspondant uniquement à la photo imprimée sur un document constitue une preuve moins probante qu'une correspondance avec les fichiers gouvernementaux ou qu'une photo de puce vérifiée.

Maintenant, faites-le passer par trois candidats :

Le candidat C explique pourquoi le graphique affiche des faits plutôt que de les remplacer. Si votre politique envoie les selfies présentant des incohérences pour vérification, modifiez la règle 4 pour qu'elle achemine les données.verification.reasonCode eq selfie_mismatchun examen préalable est nécessaire avant tout refus. Un examinateur, après avoir examiné les photos, produit une vérification qui donne son accord.approvedaveccheckStatus: "failed"et les deux affirmations sont vraies.

Toden modèles de navires, tels que KYC plus AML Le processus de sélection et d'intégration par niveau de risque s'appuie sur un organigramme décisionnel préétabli. Il s'agit d'une première ébauche raisonnable, et non d'une politique à publier sans l'avoir lue.

Comportements à connaître avant de publier

Les exécutions sont figées. Une exécution utilise la version du flux de travail et l'instantané du graphique avec lesquels elle a été lancée. La republication d'un graphique plus restrictif ne modifie pas une décision déjà en cours, ce qui est crucial lorsqu'une exécution est en attente de plusieurs jours de la part des dirigeants de l'entreprise.

Le processus de présélection attend uniquement la première réponse. L'attente se poursuit jusqu'à la résolution du problème. Les présélections ultérieures sont gérées par une surveillance continue, et non par une nouvelle décision concernant l'intégration.

Les personnes priment sur le système. La décision d'un réviseur prévaut sur celle du processus. Si un membre de votre équipe prend une décision pendant que l'exécution est en cours, sa décision est maintenue et la décision ultérieure du processus n'a aucune incidence sur le statut.

Les pannes moteur ne sont pas des déclins. workflow.run.failedCela signifie que le moteur n'a pas pu terminer son cycle. Il s'agit d'un incident à analyser, et non d'un refus de la part du client.

Les actions ont des effets secondaires. Ouvrir un ticket ou envoyer un webhook n'interrompt pas l'exécution. Le graphe continue de s'exécuter jusqu'à atteindre un nœud d'état ; assurez-vous donc que chaque chemin aboutisse.

Liste de contrôle pour votre premier graphique

1. Rédigez la politique en phrases claires avant de réaliser tout dessin, y compris le résultat par défaut.

2. Mettez en premier les blocages stricts (correspondances confirmées avec la liste de surveillance) et en dernier les approbations.

3. Pour chaque échec de contrôle, décidez s'il est refusé ou s'il fait l'objet d'un examen, et notez-le comme règle.

4. Utiliserexistspartout où une valeur manquante devrait avoir une signification.

5. Ouvrez un dossier sur les voies qui nécessitent un enquêteur, et non pas seulement un examen.

6. Testez chaque chemin dans un environnement de test (sandbox) avec les identifiants de test publiés avant de le déployer en production.

7. Stockez leworkflowVersionavec chaque résultat, afin de pouvoir ensuite montrer quelles règles un client a suivies.