Skip to main content
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

La liste 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

  1. Par document : les mêmes vérifications que /extract a déjà renvoyées pour chaque fichier (type, lisibilité, expiration, majorité, MRZ, ancienneté, provenance, spécimen).
  2. 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.
  3. 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.
La vérification est déterministe : la même entrée donne le même verdict, sauf pour le filtrage (qui dépend de la liste chargée) et la date, qui vient de l’horloge du serveur.

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é.
(Exemple illustratif : la forme de 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 reference et le même environment, la révision ajoute une vérification info policy:periodic_review.
  • Sans intégration, ou sans reference, la révision est respectée mais ajoute un avertissement policy: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.
Chacune exige 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 une corporation 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 une reference, 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 donne passed: false et deux échecs critiques, un du document et un du profil :