Skip to main content
Ce parcours mène un faux client, Test Client, de deux documents à une évaluation du risque. Il s’exécute sur la sandbox avec la clé que vous avez créée dans Tester en sandbox.

Ce dont vous avez besoin

N’utilisez que des données fictives. Ces appels envoient une reference : les fichiers sont donc classés dans votre propre dossier.

Le plan

  1. POST /v1/kyc/extract avec la fiche de paie.
  2. POST /v1/kyc/extract avec la CIN.
  3. Construisez values à partir de ce qui a été lu et de ce que le client a déclaré.
  4. POST /v1/kyc/assess avec values et les entrées documents inchangées.
Pourquoi deux lectures et non une : doc_type s’applique à tous les fichiers d’un appel, donc un type de document par appel. Pourquoi une CIN dans un parcours sur la fiche de paie : avec les règles par défaut, une vérification exige une pièce d’identité officielle avec photo parmi les documents (required:photo_id est critique). Une fiche de paie seule serait bloquée. Une fiche de paie est un justificatif, pas une preuve d’identité. Pourquoi annual_income est saisi à l’étape 3 : on demande au lecteur de ne jamais estimer. Une fiche de paie montre la paie d’une période : annual_income ne revient donc que si la fiche l’imprime. Le parcours prend le revenu dans le formulaire de demande du client, et la fiche de paie fournit l’employeur et la profession.

Code complet

Exécutez-le :
Les trois versions ont été exécutées contre un serveur local de substitution qui renvoie des réponses /extract préparées et exécute le code de vérification et de scoring de Sahl sur le corps envoyé : les nombres affichés ci-dessous sont donc ceux que le moteur calcule pour cette entrée. Le lecteur réel renvoie les champs qu’il voit sur vos fichiers, ce qui peut différer.

Résultat attendu

case est un vrai identifiant dans votre réponse. L’ordre des champs de la fiche de paie peut différer. Dans un environnement de production avec la liste de sanctions complète chargée, la ligne de filtrage est le contrôle d’information Sanctions screening — no matches; PEP not list-screened. Si votre environnement n’a que la liste d’exemple de 30 noms, flags affiche aussi screening et le risque de conformité passe à Medium (2 points).

Ce que chaque étape a renvoyé

1. Fiche de paie

Une fiche de paie n’a pas de contrôles de document : checks est donc vide. Elle fournit l’employeur, la profession et le nom du titulaire. C’est aussi sur elle que porte kyc.documents_read.

2. Carte nationale (CIN)

checks affiche quatre réussites : ses champs clés ont été lus, il n’est pas expiré, le numéro de CIN est bien formé (format:cin:, une ou deux lettres puis cinq à sept chiffres, par exemple BK123456) et le titulaire est majeur. L’exemple utilise le pays MA et id_type National ID, que le moteur accepte tels quels.

4. Évaluation

Abrégé. La réponse complète répète chaque contrôle et le bloc de politique. Comment la lire :
  • passed: true : aucun contrôle critique n’a échoué.
  • Le seul drapeau est completeness à 61 % : le parcours n’a envoyé ni adresse, ni téléphone, ni email, ni réponse sur la PPE. Une personne doit les compléter. La liste des données requises du moteur est nord-américaine : elle demande aussi une province et un sin/ssn, qu’un dossier marocain ne peut pas toujours fournir, donc un dossier marocain reste sous 100 %. Cela coûte aussi un point de risque : le risque de conformité est donc Low (le plafond de Low est de 1 point).
  • Le profil de risque 58 est le calcul décrit dans Évaluation du risque. La capacité 20 vient d’un revenu de 84 000, d’actifs liquides de 20 000 et d’un patrimoine net de 60 000, lus ici en MAD. Le moteur lit les montants comme de simples nombres, avec des tranches fixes qui ne dépendent pas de la devise.

Essayer les cas d’échec

Dans la console

Ouvrez Cases et trouvez client-0001 dans sandbox. Les documents, les contrôles et le verdict y sont classés. Les mêmes appels figurent dans Developers, Call log.

Suite

Recettes

Cinq cas d’usage fonctionnels.

Mise en production

Ce qu’il faut vérifier avant la production.