Skip to main content
Chaque recette est un script complet en JavaScript et en Python. Elles utilisent des clients fictifs et la sandbox. Exécutez-les telles quelles après avoir placé vos propres fichiers à côté. Les recettes JavaScript partagent un petit utilitaire, présenté en premier. Toutes les recettes 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 les corps envoyés (la recette eID interroge un substitut qui répond pending, puis complete). Elles n’ont pas été exécutées contre l’API réelle.

Utilitaire pour les recettes JavaScript

Enregistrez-le sous common.mjs.
L’utilitaire lève une erreur qui porte status, body et requestId (l’en-tête X-Request-ID). Communiquez l’identifiant de requête lorsque vous écrivez à Sahl.

1. Dossier de prêt

Un demandeur envoie une pièce d’identité, un justificatif de domicile et une fiche de paie. Vous voulez un verdict pour le dossier et une suite à donner : continuer, revue humaine ou refus.
Résultat pour le faux fichier (ni rue, ni téléphone, ni email dans values : la complétude est donc inférieure à 100 %) :
Comment elle décide : un échec critique (passed: false) signifie refuser ou corriger. Des drapeaux sans échec critique signifient qu’une personne révise. Rien du tout signifie continuer. Ces suites sont votre politique, pas celle de Sahl.

2. Dossier d’ouverture de compte

Le client remplit votre formulaire de demande et envoie une pièce d’identité avec photo. Vous vérifiez l’ensemble du dossier, intégrez votre propre contrôle de doublon et conservez le case_id.
Résultat pour les données fictives, qui renseignent chaque donnée requise sauf sin/ssn. La liste des données requises du moteur est nord-américaine et un client marocain n’a pas de NAS : sin/ssn reste dans missing et la complétude est de 96 %. C’est au-dessus du seuil d’alerte de 80 %, donc rien n’est signalé :
Points à reprendre :
  • La recette remplace les valeurs d’identité du formulaire par celles lues sur la pièce d’identité. Si vous préférez détecter une faute de frappe dans le formulaire, laissez les noms du formulaire dans values et laissez consistency:profile_name_id les comparer avec la pièce d’identité (critique lorsqu’ils diffèrent).
  • Une entrée extra_checks en échec avec la gravité critical met passed à faux : votre propre règle peut donc bloquer le dossier.
  • policy.overrides_refused est vide sauf si vous avez envoyé un interrupteur que la politique de votre espace de travail verrouille.
  • Pour une entité, utilisez kind: "corporation" (ou un autre type d’entité), envoyez legal_name, business_number, director_names et beneficial_owners, et lisez l’acte constitutif avec step_key=articles_of_incorporation. Voir les données requises.

3. Vérification du revenu à partir d’une fiche de paie

Le client déclare un revenu et envoie une fiche de paie. L’API lit la fiche de paie. Elle ne fixe aucune règle de revenu et ne renvoie un chiffre que si la fiche de paie en imprime un. Les règles ici sont donc les vôtres : titulaire, employeur, date, et revenu s’il est indiqué.
Résultat pour la fausse fiche de paie, qui n’imprime pas de chiffre annuel :
Sur quoi repose cette recette :
  • annual_income ne revient que si la fiche de paie l’indique. On demande au lecteur de ne jamais estimer.
  • L’API contrôle l’ancienneté des justificatifs de domicile, pas des fiches de paie. Les 90 jours ici sont votre règle.
  • capacity n’utilise que le revenu déclaré. Quand net_liquid_assets et total_net_worth manquent, le score est tiré vers le bas ; envoyez-les si vous les avez. Voir Capacité.

4. Contrôle eID

Un client canadien ouvre un compte à distance. L’eID ne couvre que les clients canadiens dans cette version : cette recette est la seule qui garde le pays CA. Vous lancez le contrôle, attendez le client, conservez le rapport PDF, puis vérifiez sous la même référence.
Cela envoie un vrai email via le fournisseur eID, en sandbox aussi. Remplacez l’adresse par une adresse que vous contrôlez. Votre espace de travail a besoin de son propre compte chez un fournisseur eID.
Résultat, avec un client qui termine après la troisième interrogation :
Conservez le PDF : le fournisseur supprime les données personnelles après environ sept jours. Voir Contrôle eID.

5. Gérer un champ que le lecteur n’a pas lu

L’API ne renvoie aucune confiance par champ. Un champ est dans fields ou il n’y est pas, et les contrôles signalent quand les champs clés d’un document manquent. Cette recette transforme ces signaux en ce qu’il faut demander au client, ne réessaie que si le fichier n’a jamais été lu, et laisse ce que le client a saisi primer sur ce qui a été lu.
Quand une CIN revient sans date_of_birth ni id_number, le résultat est :
Règles à retenir :