POST /v1/kyc/verify renvoie le verdict pour un profil client et les documents qui l’accompagnent. Scope : kyc:verify. L’endpoint ne lit aucun fichier et ne coûte aucune lecture de document. POST /v1/kyc/assess prend le même corps, exécute ce même verdict, et ajoute une évaluation du risque.
Requête
Corps JSON. Tous les champs sont facultatifs, mais un corps vide ne vérifie rien.values
values est un objet libre. Le moteur lit les clés ci-dessous et ignore les autres. Envoyez des chaînes. Les dates sont au format YYYY-MM-DD.
La vérification de complétude compte ces clés comme présentes lorsqu’elles ne sont pas vides.
La liste requise vient d’un moteur d’abord conçu pour des dossiers nord-américains. Elle demande
province, postal_code et un sin ou ssn : une personne marocaine atteint au mieux 27 sur 28 (96 %) et sin/ssn reste dans missing. À partir de 80 %, rien n’est signalé. Les exemples utilisent le pays MA, id_type National ID et un numéro de CIN comme BK123456 ; province et postal_code acceptent n’importe quel texte pour une adresse marocaine, et le format postal canadien n’est vérifié que si country vaut CA.
Autres clés utilisées par les vérifications :
Réponse
checks ci-dessus est raccourcie à trois entrées ; une réponse complète en contient davantage. L’exemple est la sortie réelle du moteur pour des données fictives (une carte nationale d’identité marocaine et une fiche de paie pour Test Client).
Chaque vérification a cinq clés.
Ne faites pas correspondre sur
label : il peut changer. Faites correspondre sur id, et traitez la partie après le premier deux-points comme une variable.
Comment lire le verdict
Le dossier passe quand aucune vérification critique n’a échoué. Un dossier avec 30 avertissements passe quand même, donc regardez
flags en plus de passed.
Les trois niveaux
- Par document : les mêmes vérifications que
/extracta déjà renvoyées pour chaque fichier (type, lisibilité, expiration, majorité, MRZ, ancienneté, provenance, spécimen). - Inter-documents et profil : le nom, la date de naissance et l’adresse concordent entre les documents et avec
values; les formats des numéros ; les coordonnées bancaires ; la pièce d’identité exigée figure parmi les fichiers envoyés. - Niveau dossier : filtrage des sanctions et des PEP, bénéficiaires effectifs pour les entités, vérifications de registre, déterminations propres à la politique, puis complétude.
Vérifications
Les ids sont listés avec la partie après le premier deux-points remplacée par*. « Document » désigne le libellé de l’étape ou l’indice doc_type (par exemple passport, ou Government photo ID quand un step_key est envoyé).
Par document
Inter-documents et profil
Niveau dossier
Filtrage
Chaque partie du dossier est filtrée par défaut (screen: true).
Une correspondance de sanctions est critique et bloque. Une correspondance PEP est un avertissement. Un résultat propre produit une seule vérification
screening qui indique contre quoi la partie a été filtrée :
Avec
canadian_screening à true (ou si la politique le demande) et un client canadien (country vaut CA, CAN ou Canada), les parties sur lesquelles le jeu de listes n’a rien trouvé sont aussi filtrées par les tables canadiennes LBA et PEP du fournisseur eID, quand l’espace de travail a un compte. La vérification screening:canchek indique combien de parties ont été filtrées.
Politique et options
Chaque appel s’exécute sous la politique KYC de votre espace de travail pour le type de client (kyc pour une personne, kyb pour toute entité) et l’environnement. Le champ policy de la réponse indique laquelle.
Une option de requête peut ajouter des vérifications ou être plus stricte. Elle ne peut pas désactiver un élément verrouillé par la politique. Une option refusée n’est pas une erreur : l’appel s’exécute avec la règle plus stricte et le refus est consigné.
overrides_refused est réelle, les valeurs sont un exemple.) Un refus ajoute aussi une vérification info policy:override_refused:screen.
Ce qu’une politique peut modifier :
Les valeurs de politique se modifient dans la console, pas par l’API.
Révision périodique
purpose: "periodic_review" est destiné à un client déjà intégré. Il ne revérifie pas l’identité (PCMLTFR s.155(1)) : les pièces d’identité, l’exigence eID et les vérifications d’emplacements ne sont pas appliquées. Le filtrage, les déterminations et tous les autres verrous s’exécutent quand même.
- Avec une intégration réussie au dossier chez Sahl pour la même
referenceet le mêmeenvironment, la révision ajoute une vérification infopolicy:periodic_review. - Sans intégration, ou sans
reference, la révision est respectée mais ajoute un avertissementpolicy:periodic_review_unanchored: l’identité a été ignorée sur votre seule parole.
Vos propres vérifications
extra_checks vous permet d’intégrer au verdict une vérification que vous avez exécutée vous-même, comme un client en double ou une liste de blocage dans votre base, afin qu’elle puisse le bloquer.
id, label, severity (critical, warning ou info) et passed ; detail est facultatif. Un id qui commence par eid: ou policy: est réservé à Sahl : il revient sous la forme partner:eid:... ou partner:policy:..., affiché et capable de bloquer, mais il ne satisfait jamais l’exigence eID de la politique.
Registre Corporations Canada
Pour unecorporation que le conseiller indique comme constituée au fédéral (LCSA), et quand la politique l’active (activé par défaut), Sahl recherche la société. registry contient alors l’enregistrement normalisé, pour que vous puissiez pré-remplir à partir de lui, et les vérifications registry: le comparent à vos données. Dans tous les autres cas, registry est null.
Classement
Avec unereference, le verdict est classé sur le dossier pour (espace de travail, environnement, référence). Les documents dont le document_id vient de /extract y sont liés. Un statut défini par une personne (approved, refused) n’est jamais annulé par un nouveau verdict. Le webhook kyc.case_verified se déclenche après la validation.
Exemples
Un dossier bloqué
Une carte nationale expirée donnepassed: false et deux échecs critiques, un du document et un du profil :