Tous les passages ne se valent pas : l’utilisation des niveaux d’assurance dans les décisions d’enregistrement et de vérification des clients

Considérez les trois passes comme trois niveaux de preuve différents et décidez avant le lancement ce que chacune est autorisée à faire.chipLe laissez-passer repose sur les données signées par l'État émetteur.gov_dbLe succès de cette décision repose sur les propres déclarations du gouvernement.documentLe passage dépend de l'apparence du document sur la photographie. Les trois personnes peuvent être de véritables clients et devraient être inscrites, mais elles ne devraient pas se voir appliquer les mêmes limites par défaut.

La règle pratique est la suivante : orienter le client selon le niveau d’assurance en l’associant à la photo de comparaison du visage, définir une politique explicite pour chaque niveau et offrir aux clients la possibilité de passer au niveau supérieur au lieu de les faire échouer.

Que signifie chaque niveau d'assurance ?

Dans Toden Vérification d'identité : chaque vérification réussie entraîne uneassuranceLevel, décrits dans la documentation « Pays et types de pièces d'identité » (s’ouvre dans un nouvel onglet) :

Le classement reflète la provenance des preuves. Les directives du NIST sur la vérification d’identité, SP 800-63A-4 (s’ouvre dans un nouvel onglet) (juillet 2025), utilise une approche similaire : sa catégorie de preuve la plus exigeante requiert une validation « par la vérification cryptographique du contenu de la preuve et de la source émettrice », incluant « une chaîne de confiance remontant à une ancre de confiance ». C'est précisément le rôle d'une vérification de puce. NIST Il s'agit d'un cadre de référence américain et ses catégories ne correspondent pas directement à ces niveaux, mais la logique est la même.

Pourquoi le laissez-passer n'est-il pas suffisant pour poursuivre la route ?

Car deux vérifications aboutissant au même verdict peuvent présenter des niveaux de preuve très différents.

Prenons l'exemple de deux candidats utilisant la même application d'investissement. Le premier est un client kenyan, vérifié auprès du registre gouvernemental grâce à un selfie correspondant à la photo figurant dans ce registre. Le second est un candidat originaire d'un pays sans base de données accessible, vérifié à partir de la photo de son permis de conduire, son selfie correspondant à la photo imprimée sur ce permis. Les deux candidats sont validés. Or, seul le premier a été vérifié auprès d'une source qu'il n'aurait pas pu fournir.

Le deuxième domaine qui compte estfacialMatchSource, qui indique avec quelle photo le selfie a été comparé :gov_record,chipoudocumentUne comparaison avec la photo imprimée constitue une preuve moins convaincante, car un faussaire y appose son propre visage ; Toden elle n'augmente jamais le niveau d'assurance. Une politique qui examineassuranceLevelmais ignorefacialMatchSourceIl manque la moitié du tableau.

Comment chaque niveau doit-il être traité ?

Voici une politique de base pour une application de gestion et de transfert d'argent. Elle est donnée à titre indicatif ; vos propres limites dépendent de votre produit, de votre licence et de votre tolérance au risque.

Trois principes siègent derrière la table.

1. Le niveau fixe le plafond, pas le plancher .documentUn client de niveau inférieur n'est pas suspect. C'est un client que vous connaissez moins, ce qui justifie des limites plus basses, et non un refus.

2. L'assurance concerne l'identité, pas le risque .chipLe laissez-passer atteste que la personne est bien celle indiquée sur le passeport. Il ne mentionne en aucun cas si elle fait l'objet de sanctions, est politiquement exposée ou sur le point de commettre une fraude. Un contrôle et une surveillance sont effectués à tous les niveaux.

3. Laissez les clients grimper. Un client àdocumentLes utilisateurs qui s'authentifient ultérieurement avec un passeport à puce via votre application mobile, ou avec une seconde pièce d'identité, devraient pouvoir accéder au niveau supérieur. Privilégiez la possibilité d'une mise à niveau plutôt qu'un plafond permanent.

À quoi cela ressemble-t-il sous forme de graphe de décision ?

Dans Toden Les flux de travail , un graphe de décision qui s'exécute après la fin des vérifications, se ramifient en fonction de champs tels que :verification.assuranceLeveletverification.facialMatchSourceet aboutit à l'approbation, à la révision ou au refus. Une action de balise peut marquer le niveau afin que votre système dorsal définisse des limites à partir duworkflow.run.completedWebhook. Graphique illustratif de la politique ci-dessus :

1. Wait for screening
2. If screening.anyMatch            -> open case, then REVIEW
3. If verification.status != VERIFIED -> DECLINE
4. If assuranceLevel in [chip, gov_db]
     and facialMatchSource in [chip, gov_record] -> tag "tier-full", APPROVE
5. If assuranceLevel == document    -> tag "tier-reduced", APPROVE
6. Otherwise                        -> REVIEW

Votre système dorsal lit le résultat et les étiquettes du webhook et applique les limites. Chaque exécution étant liée à la version du workflow initial, toute modification ultérieure de la politique ne remet pas en cause une décision déjà prise. La documentation relative à la prise de décision (s’ouvre dans un nouvel onglet) répertorie les champs et les types de nœuds.

Quels sont les cas limites ?

Une puce sur le chemin de la base de données gouvernementale. Dans Toden Lorsqu'une pièce d'identité est également vérifiée auprès d'une base de données gouvernementale (un passeport nigérian, par exemple), le selfie est comparé à la photo du gouvernement plutôt qu'à celle de la puce. À ce stade, la puce parvient au système.chipLe niveau est validé uniquement si l'authentification active prouve qu'il ne s'agit pas d'une copie ; sinon, la vérification réussit tout de même au niveau supérieur.gov_dbEn pratique, cela ne constitue pas une régression : les deux niveaux bénéficient du même traitement dans la politique mentionnée ci-dessus.

Une puce non authentifiée. Une puce dont le pays d'émission ne figure pas sur la liste des certificats de confiance, ou qui est illisible, ne présente jamais d'échec à la vérification. Elle ne contribue simplement pas à l'assurance de la puce, et la vérification est alors basée sur ses autres contrôles. Voir la NFC Consultez la documentation de la puce (s’ouvre dans un nouvel onglet) pour plus de détails.

Approbation malgré un contrôle non concluant. Des niveaux d'assurance sont associés à la réussite des vérifications. Lorsqu'un examinateur approuve une personne dont le contrôle a échoué, le dossier conserve la mention de l'échec.checkStatuset sonreasonCodeConsidérez ces approbations comme une catégorie à part entière dans votre politique de limites, et non comme un laissez-passer à quelque niveau que ce soit.

Liste de vérification avant le lancement

• MagasinassuranceLeveletfacialMatchSourceavec chaque dossier client, en plus du résultat.

• Rédigez une politique d'une page associant à chaque combinaison un résultat et une limite.

• Implémentez-le sous forme de graphe de décision pour une application cohérente et étiquetez le niveau pour votre backend.

• Offrir aux clients des niveaux inférieurs la possibilité d'accéder à un niveau supérieur.

• Maintenez le dépistage et la surveillance à chaque niveau.

• Revoyez la politique lorsque vous ajoutez des marchés, car le niveau auquel vos nouveaux clients peuvent accéder dépend du pays.

Les exigences en matière de vérification de l'identité des clients varient selon la juridiction et la licence. Cet article fournit des informations générales et ne constitue pas un avis juridique. Le principe reste le même : évaluez la fiabilité de chaque identité et basez votre décision sur ce critère.