Comment lire un résultat de vérification
Un résultat de session est un statut, plus un résultat par contrôle, plus une liste d'avertissements. Les avertissements sont la partie qui vous dit ce qui s'est réellement passé.
Lisez-le dans cet ordre : le statut global, puis les statuts par contrôle, puis les avertissements. Les avertissements sont la seule partie qui vous dit pourquoi, tout le reste vous dit seulement quoi.
Ouvrez n'importe quelle session depuis Vérifications dans la Console Business et vous obtenez les trois mêmes couches, que vous regardiez la console, une charge utile de webhook, ou une réponse API.
- Commencez ici : la décision, et les contrôles qui l'ont produite.
- Liveness contient le résultat du selfie et le score de correspondance faciale.
- L'onglet document montre ce qui a été extrait et quels champs correspondent.
- Events explique comment la session a atteint son statut actuel.
#Couche 1 : le statut global
Le verdict unique pour la session : Approuvée, Refusée, En révision, et ainsi de suite. C'est sur cela que la plupart des intégrations agissent. C'est un agrégat : il résulte de la combinaison du résultat de chaque contrôle selon la configuration de votre workflow, donc il ne vous dit jamais quel contrôle en est responsable.
#Couche 2 : un résultat par contrôle
Chaque contrôle exécuté a son propre statut et ses propres données. Ceux que vous verrez le plus souvent :
| Contrôle | Ce qu'il faut regarder |
|---|---|
| Vérification de document | Champs extraits (nom, numéro de document, dates), type de document et pays, et si le MRZ a été validé |
| Preuve de vie passive / active | Si un humain vivant a été détecté, et tout signal d'attaque |
| Correspondance faciale 1:1 | Le score de similarité entre le selfie et la photo du document |
| Recherche faciale 1:N | Si ce visage correspond à un utilisateur déjà vérifié ou à une entrée de liste de blocage |
| Filtrage AML | Les alertes, chacune avec un score de correspondance et un score de risque |
| Analyse de l'appareil et de l'IP | Pays, signaux de VPN ou de proxy, adresses sur liste de blocage |
| Justificatif de domicile | L'adresse extraite et sa concordance avec celle que vous avez fournie |
| NFC | Si la puce a été lue et si sa signature remonte à un émetteur de confiance |
| Téléphone / e-mail | Si l'OTP a été confirmé, plus les signaux de risque sur le numéro ou l'adresse |
Un contrôle peut être Approuvé alors que la session est Refusée, et inversement. C'est normal : le statut de session est la combinaison, pas le pire cas.
#Couche 3 : les avertissements
Les avertissements sont la couche qui explique réellement le résultat. Chacun est un code nommé précis, rattaché au contrôle qui l'a levé, par exemple :
DOCUMENT_EXPIRED: la date d'expiration de la pièce d'identité est dépassée.MRZ_VALIDATION_FAILED: la somme de contrôle de la zone de lecture optique n'a pas tenu. Un signal fort de falsification.LOW_FACE_MATCH_SIMILARITY: le selfie et la photo du document ont obtenu un score en dessous de votre seuil.LIVENESS_FACE_ATTACK: une attaque de présentation a été détectée pendant le selfie.POSSIBLE_MATCH_FOUND: l'AML a trouvé une alerte candidate à résoudre.NFC_DATA_DOES_NOT_MATCH_OCR: la puce et les données imprimées ne concordent pas.IP_ADDRESS_IN_BLOCKLIST: la connexion provient d'une adresse que vous bloquez.
Quand vous déboguez une session précise, allez directement aux avertissements. Le statut vous donne la conclusion ; les avertissements vous donnent la preuve. Chaque catalogue d'avertissements par fonctionnalité est documenté sous core technology.
#Données extraites face à ce que vous attendiez
Si vous avez transmis expected_details à la création de la session (un nom, une date de naissance, un numéro de document que vous déteniez déjà), le résultat vous indique aussi si le document correspondait. Une discordance à cet endroit est généralement un problème de saisie de votre côté plutôt qu'un document frauduleux, donc cela vaut la peine d'être vérifié avant de refuser qui que ce soit.
Les noms extraits peuvent être translittérés. Un document en cyrillique, en arabe ou en grec produit un nom en écriture latine qui peut ne pas correspondre à vos enregistrements caractère par caractère, même s'il s'agit de la même personne. Comparez aussi sur le numéro de document ou la date de naissance avant de traiter une discordance de nom comme une fraude.
#Les résultats sandbox ont une apparence légèrement différente
Dans une session sandbox, la console marque les sections de données extraites d'une puce Données simulées. Le média a réellement été capturé, mais les champs et le résultat proviennent du scénario que vous avez choisi, donc n'en tirez aucune conclusion sur les valeurs elles-mêmes. Voir tester en sandbox.
#Obtenir la même chose par programmation
La charge utile du webhook et GET /v3/session/{id}/decision/ portent les trois couches dans un seul objet decision. Traitez le webhook comme votre source de vérité et ne faites du polling que pour la réconciliation : certains événements, comme les modifications de données faites par un réviseur, n'arrivent jamais que par webhook. Voir obtenir des résultats avec les webhooks.
#Obtenir une copie pour vos archives
Pour les audits et les dépôts réglementaires, téléchargez la session en PDF : il regroupe chaque étape, les données extraites, les scores biométriques, les résultats AML et la décision finale. Voir télécharger un rapport de vérification.