config dans chaque élément du tableau features pour POST /v3/workflows/ et PATCH /v3/workflows/{settings_uuid}/.
features. Envoyez les fonctionnalités dans l’ordre exact d’exécution.
Le moteur qui exécute une fonctionnalité, celui de Didit ou celui d’un fournisseur tiers, ne fait pas partie des champs de configuration ci-dessous. Il est géré via la Marketplace de la console, qui définit automatiquement
provider_key et fallback_to_native sur l’objet config de la fonctionnalité pour vous.Règles de validation
OCRprend par défaut tous les pays et types de documents pris en charge lorsqueconfig.documents_allowedest omis, égal ànullou à{}. Si vous envoyez un objetdocuments_allowedpersonnalisé, il doit contenir au moins un pays valide et un type de document activé. Chaque configuration de document peut définirsidesà1pour une capture du recto uniquement, ou à2pour une capture recto et verso.QUESTIONNAIREexigeconfig.questionnaire_uuid.KYB_DOCUMENTSexigeconfig.kyb_required_document_groups.SIGNATURErefusesignature_level: "qes"avecqes_not_availabletant que les signatures qualifiées ne sont pas disponibles, et une nouvelle étape àsignature_level: "aes"avecaes_not_availabletant quesignature_availability.aesvautfalsesur le workflow. Ses documents doivent exister au moment de la création d’une session : avecsignature_documents_sourcedéfini surworkflow, l’étape nécessite des documents téléversés dans la console, et une étape sans document peut rester en brouillon mais ne peut pas être mise en production ; avecsession, chaque appel de création doit envoyersign.documents.FACE_MATCHdoit venir aprèsOCRdans les requêtes de workflow simples.NFCetDATABASE_VALIDATIONnécessitentOCRlorsqu’ils figurent dans le même workflow.AMLnécessite l’un deOCR,KYB_REGISTRYouDOCUMENT_AIen amont. Si seulDOCUMENT_AIle précède, lefull_nameà filtrer doit pouvoir être renseigné, soit à partir d’un champ Document AI en amont déjà défini surfull_name, qui est mappé automatiquement, soit à partir d’une entrée expliciteconfig.aml_field_sources(voir AML).- Les sous-fonctionnalités KYB, comme
KYB_DOCUMENTSetKYB_KEY_PEOPLE, nécessitentKYB_REGISTRYplus haut dans le workflow. - Un workflow est soit un workflow de personne (KYC), soit un workflow d’entreprise (KYB), jamais les deux. Un workflow qui utilise une fonctionnalité KYB (
KYB_REGISTRY,KYB_DOCUMENTS,KYB_KEY_PEOPLE) ne peut combiner ces fonctionnalités qu’avecAML,DOCUMENT_AI,QUESTIONNAIRE,PHONE_VERIFICATION,EMAIL_VERIFICATION,IP_ANALYSISetSIGNATURE. Il ne peut pas inclure de fonctionnalités réservées aux personnes, commeOCR,LIVENESS,FACE_MATCH,NFC,PROOF_OF_ADDRESS,DATABASE_VALIDATIONouAGE_ESTIMATION, et un workflow de personne ne peut pas inclure de fonctionnalités KYB. Sur un workflow d’entreprise,DOCUMENT_AIcompare tout champ marquéis_full_nameavec l’entreprise vérifiée, et non avec une personne. Pour vérifier les personnes derrière une entreprise, créez un workflow KYC distinct et référencez-le depuis le nœudKYB_KEY_PEOPLEà l’aide dekyb_ubo_verification_workflow,kyb_officer_verification_workflowoukyb_shareholder_verification_workflow. - Les champs d’action utilisent
DECLINE,REVIEWouNO_ACTION, sauf si le champ ci-dessous indique qu’il est restreint. - Les champs de score et de seuil sont des nombres compris entre
0et100, sauf si une plage plus étroite est indiquée.
Règles de statut communes
Chaque fonctionnalité accepte un tableaustatus_rules facultatif. Utilisez-le pour remplacer le statut de la fonctionnalité lorsqu’une condition sur un champ est remplie.
Lisez l’exemple ci-dessus ainsi :
kyc.extra_fields.profession correspond de façon floue à Soft. Engineer avec un score minimal de 80 → définissez le statut de la fonctionnalité sur Declined.
Pour la Vérification d’identité, ciblez les valeurs extraites de extra_fields, comme kyc.extra_fields.profession, les dates de validité des catégories du permis de conduire, comme kyc.extra_fields.dl_class_code_b_from et kyc.extra_fields.dl_class_code_b_to, ou les codes de restriction ou d’information par catégorie comme kyc.extra_fields.dl_class_code_b_notes (colonne 12 des permis britanniques). Ces valeurs proviennent de l’objet extra_fields du résultat OCR ; elles ne font pas partie de expected_details.
dl_class_code_*_from et dl_class_code_*_to contiennent toujours soit une date ISO valide, soit aucune valeur dans extra_fields. Didit ne renvoie jamais de texte OCR illisible dans un champ de date. Si la cellule du tableau des catégories est illisible, le champ est omis au lieu d’être envoyé sous forme de chaîne brute. Utilisez donc l’opérateur is_empty pour orienter les dates de catégorie illisibles, plutôt que de supposer que le champ est toujours présent.value_type: "relative_date" avec un objet de valeur de la forme { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }. Par exemple, operator: "less_than" avec { "direction": "past", "amount": 3, "unit": "years" } correspond aux dates antérieures à trois ans à compter d’aujourd’hui.
Comparer avec une étape précise
Un workflow en graphe peut exécuter plusieurs fois la même fonctionnalité, par exemple trois étapes de Vérification d’identité. Avecvalue_type: "field", ajoutez @<node_id> à la valeur pour la lire depuis une étape précise.
Le nœud référencé doit être une étape de fonctionnalité qui s’exécute toujours avant l’étape propre à la règle, sur tous les chemins qui y mènent, ou l’étape propre à la règle elle-même.
Une valeur sans ce suffixe est lue depuis l’étape propre à la règle.
kyc.full_name de cette étape correspond de façon floue au nom complet lu par l’étape ocr_1, avec un score minimal de 80 → définissez le statut de la fonctionnalité sur Declined.
Dans la console, le sélecteur de variables liste chaque étape éligible par son numéro sur le canevas et enregistre le suffixe à votre place.
Vérification d’identité (OCR)
Valeur de la fonctionnalité :OCR.
La détection du vivant du document se configure avec les six seuils
document_liveness_* ci-dessus, et non avec des champs d’action par signal. portrait_replacement_action, printed_copy_action et screen_capture_action sont des paramètres au niveau du compte et ne sont pas acceptés dans la configuration d’un workflow : l’API supprime les clés de configuration inconnues à l’enregistrement, donc les y envoyer n’a aucun effet. Chaque signal dispose d’un seuil de refus et d’un seuil de révision sur une échelle de 0-100, où un score plus élevé indique une plus grande probabilité d’authenticité.Méthodes par pays
methods est indexé par le code pays ISO 3166-1 alpha-3. Chaque pays accepte jusqu’à trois objets de méthode ; tout ce que vous omettez prend sa valeur par défaut.
wallet.on_failure vaut fallback_to_document, decline ou retry. retry (portefeuille uniquement, capture de document désactivée pour le pays) permet à un utilisateur dont la connexion n’a pas abouti à l’étape du portefeuille de réessayer ; la session n’est jamais refusée à ce titre et reste ouverte jusqu’à ce qu’il termine ou qu’elle expire. Les commutateurs id_lookup n’acceptent que fallback_to_document ou decline.
Pour écarter les documents du premier écran et ne les proposer que lorsqu’un portefeuille ou une recherche n’aboutit pas, définissez document.fallback_only. L’exemple utilise la Finlande, où le Finnish Trust Network passe en premier et où la capture de document sert de solution de repli. La Finlande exige aussi que ses types de documents soient activés dans documents_allowed (par exemple passeport et carte d’identité) afin que la solution de repli ait des documents à proposer.
available dans le catalogue actuel, donc cette configuration s’enregistre telle quelle. Le bloc portefeuille est volontairement omis de cet exemple : un portefeuille ne s’enregistre que dans un pays où le catalogue le marque available, et wallet.enabled: true ailleurs est rejeté, ce qui fait échouer l’enregistrement complet, configuration des recherches comprise. Lorsque le catalogue marque un portefeuille comme available, ajoutez-le à ce pays :
Règles de validation appliquées par l’API à l’enregistrement :
- Un code pays inconnu, une clé inconnue dans un pays ou une clé inconnue dans une méthode est rejeté : aucune donnée n’est ignorée silencieusement.
- Un pays où aucune méthode n’est activée est rejeté : personne dans ce pays ne pourrait vérifier son identité.
- Un portefeuille ou une consultation ne peut basculer vers la capture de document que si celle-ci est activée pour ce pays.
fallback_to_documentdans un pays oùdocument.enabledvautfalseentraîne un refus à l’exécution, car il n’existe aucune capture de document vers laquelle basculer. document.fallback_only: trueest rejeté avec le code HTTP 400, sauf sidocument.enabledvauttrueet qu’au moins un portefeuille ou une consultation d’identité de ce pays bascule vers la capture de document.
methods, dans l’onglet Pays de la console ou avec l’outil MCP didit_workflow_get_id_verification_methods_catalog. Le comportement, la couverture et la facturation sont décrits dans Méthodes de vérification d’identité.
NFC / ePassport
Valeur de la fonctionnalité :NFC.
Détection du vivant
Valeur de fonctionnalité :LIVENESS.
Correspondance faciale
Valeur de fonctionnalité :FACE_MATCH.
Estimation de l’âge
Valeur de la fonctionnalité :AGE_ESTIMATION.
Vérification du téléphone
Valeur de fonctionnalité :PHONE_VERIFICATION.
La vérification du téléphone est désactivée tant que l’organisation n’a pas effectué sa première recharge.
L’enrichissement des informations sur le téléphone est une option facultative. Lorsque
phone_enrichment_enabled vaut true, chaque vérification du téléphone terminée est enrichie d’informations sur le téléphone et facturée $0.05 par requête en plus du coût standard de la vérification du téléphone. Les actions basées sur le score ne prennent effet qu’une fois le score d’enrichissement disponible ; les actions liées à l’indice de confiance, au type de téléphone et à la portabilité s’appliquent dès que l’enrichissement est exécuté.La vérification de l’empreinte sociale est une deuxième option, distincte de la première. Lorsque phone_social_enabled vaut true, chaque vérification du téléphone terminée indique également sur quelles plateformes en ligne le numéro est enregistré - messagerie, réseaux sociaux, plateformes de commerce en ligne et plateformes professionnelles - et est facturée $0.05 par requête. Elle peut être activée avec ou sans phone_enrichment_enabled : les deux options sont tarifées et facturées indépendamment. Une recherche qui ne trouve le numéro sur aucune des plateformes couvertes constitue une réponse valide et facturable, et déclenche phone_no_social_presence_action. Utilisez phone.social_profiles_registered (le nombre de plateformes sur lesquelles le numéro est enregistré) pour orienter le parcours dans un graphe de workflow selon ce résultat.Vérification de l’e-mail
Valeur de fonctionnalité :EMAIL_VERIFICATION.
L’enrichissement par des données de renseignement sur les e-mails est un module complémentaire facultatif. Lorsque
email_enrichment_enabled a pour valeur true, chaque vérification e-mail terminée est enrichie par des données de renseignement sur les e-mails et facturée $0.05 par requête en plus du coût standard de la vérification e-mail. L’action basée sur le score prend effet dès que le score d’enrichissement est disponible ; les actions liées aux fuites de données s’appliquent dès que l’enrichissement est exécuté.La vérification de l’empreinte sociale est un second module complémentaire, distinct du premier. Lorsque email_social_enabled a pour valeur true, chaque vérification e-mail terminée indique aussi sur quelles plateformes en ligne l’adresse est enregistrée (fournisseurs d’e-mail, réseaux sociaux, services professionnels, de commerce en ligne et de divertissement) et est facturée $0.05 par requête. Elle peut être activée avec ou sans email_enrichment_enabled : les deux modules complémentaires sont tarifés et facturés indépendamment. Une recherche qui trouve l’adresse sur aucune des plateformes couvertes constitue une réponse valide et facturable, et déclenche email_no_social_presence_action. Utilisez email.social_profiles_registered (le nombre de plateformes sur lesquelles l’adresse est enregistrée) pour créer une branche selon ce résultat dans un graphe de workflow.Validation en base de données
Valeur de la fonctionnalité :DATABASE_VALIDATION.
Exemple :
400 qui le nomme et indique la raison, et rien n’est enregistré.
Cela couvre un identifiant absent du catalogue, un identifiant qui appartient à un autre pays, un service pas encore disponible, et un service proposé uniquement via le POST /v3/database-validation/ autonome.
Un service dont les entrées ne sont fournies par aucune étape précédente est rejeté de la même manière, avec la liste des entrées manquantes.
Un service que le workflow enregistré contient déjà, mais ne peut plus exécuter, est supprimé lorsque vous enregistrez à nouveau le workflow.
Par exemple, ce workflow argentin lit le numéro de DNI et le genre depuis la Vérification d’identité, puis les compare à RENAPER sans selfie :
arg_renaper, après une étape LIVENESS, pour comparer aussi le selfie à la photo détenue par RENAPER.
Voir RENAPER pour son score de correspondance faciale et son seuil.
Vérification bancaire
Valeur de la fonctionnalité :BANK_VERIFICATION.
L’utilisateur vérifie un compte bancaire, et le titulaire communiqué par la banque est comparé à l’identité établie par une étape précédente du workflow. Il le fait selon l’une de deux méthodes : la connexion à sa banque (open_banking), où il se connecte auprès de sa banque, ou la vérification du compte (account_lookup), où il saisit les coordonnées du compte et la banque confirme le nom qui y est associé. bank_method_order et le methods de chaque pays déterminent les méthodes proposées dans un pays et celle qui apparaît en premier ; voir Méthodes de vérification bancaire. L’étape produit des éléments de preuve (un score de correspondance du nom du titulaire, la comparaison qui l’a produit, les codes de motif), et les clés bank_*_action transforment ces éléments en statut.
Deux éléments déterminent si le nœud fait quoi que ce soit. bank_countries est une liste blanche : un objet vide ne propose aucune banque et n’exécute aucune vérification. Par ailleurs, le titulaire doit pouvoir être comparé à quelque chose : placez devant ce nœud une étape OCR, DATABASE_VALIDATION ou QUESTIONNAIRE, envoyez expected_details à la création de la session, ou associez vous-même les champs avec bank_field_sources. Sans aucun de ces éléments, la titularité ne peut être que unknown, ce que décide bank_reference_identity_missing_action.
La vérification bancaire est encore en cours de déploiement : un nœud
BANK_VERIFICATION n’est accepté que sur un compte où elle a été activée. Partout ailleurs, l’enregistrement est rejeté et le message l’indique. La route qui exécute l’étape n’est pas non plus configurée ici : elle est définie par la paire provider_key et fallback_to_native que la Marketplace de la console renseigne pour vous.Connecter un compte
Quand l’utilisateur ne peut pas vérifier
L’utilisateur peut toujours continuer sans banque, et l’étape ne le bloque jamais. Voir Quand la personne ne peut pas vérifier sa banque.
Ce que la poursuite implique pour la session est défini par
bank_unsupported_action, bank_attempts_exhausted_action ou bank_skipped_action, selon la raison pour laquelle l’utilisateur a continué, sauf si une tentative évaluée auparavant a déjà décidé de l’étape : voir Actions de décision.
Comparaison du titulaire
Vérification du compte
Ces clés ne s’appliquent qu’à la vérification du compte. La connexion bancaire conserve ses propres correspondances proches et son proprebank_max_attempts.
Données financières
bank_expected_currencies fonctionne avec le seul consentement ownership par défaut. Les trois autres clés lisent de véritables données financières : chacune nécessite le périmètre de consentement correspondant dans bank_scopes, faute de quoi l’enregistrement est refusé.
Ce qui est stocké
Actions de verdict
Chaque clé ici prendDECLINE, REVIEW ou NO_ACTION, sauf si elle est marquée comme restreinte, et revient à la valeur par défaut ci-dessous lorsque vous l’omettez ou envoyez null. Rien qui ne constitue pas une preuve positive de propriété n’est approuvé par défaut, et seule une preuve démontrable contre l’utilisateur entraîne un refus.
Autres contrôles
Ces clés sont facultatives. Chaque clé d’action prendDECLINE, REVIEW ou NO_ACTION.
Exemple d’objet
config, pour un compte où la Vérification bancaire est activée et où la route que vous avez choisie couvre le pays que vous indiquez :
AML
Valeur de fonctionnalité :AML.
Pour le filtrage des personnes dans le cadre du KYC, utilisez les champs suivants :
Pour le filtrage des entreprises dans le cadre du KYB, utilisez les champs suivants :
Filtrage d’une entité extraite par une étape Document AI
Une étape AML lit normalement l’entité à filtrer depuis l’étapeOCR (une personne) ou l’étape KYB_REGISTRY (une entreprise). Un workflow dont la seule étape d’extraction est DOCUMENT_AI, c’est-à-dire des documents non standardisés comme un certificat fiscal ou un acte constitutif, n’a ni l’une ni l’autre. Il doit donc préciser d’où provient chaque entrée de filtrage.
Exemple : filtrage de l’entreprise mentionnée dans une acta constitutiva mexicaine, sans aucun document d’identité dans le workflow :
Analyse de l’appareil et de l’IP
Valeur de fonctionnalité :IP_ANALYSIS.
Exemple :
recovered_device_action séparément de duplicated_device_action lorsque vous souhaitez surveiller les appareils récupérés avec un niveau de confiance élevé avant de les refuser automatiquement. Cela est utile pendant le déploiement, car les correspondances d’appareils récupérés sont conçues pour détecter les réseaux de fraude, mais doivent tout de même être calibrées sur votre propre trafic.
Vérification de la localisation
Valeur de la fonctionnalité :GEOLOCATION.
Vérifie où se trouve la personne pendant sa vérification, à partir de la position de l’appareil ou de la localisation IP de la connexion, par rapport aux zones autorisées et bloquées, à la localisation IP et à l’adresse du document.
Consultez Vérification de la localisation pour savoir comment se comporte l’étape, et son rapport pour les champs de décision.
Placez-la après la Vérification d’identité ou le Justificatif de domicile si vous voulez mesurer la distance jusqu’à l’adresse du document, car cette distance n’est calculée que lorsqu’une adresse est enregistrée.
Si geolocation_position_source n’est pas défini, la distance par rapport à la localisation IP nécessite une étape Analyse de l’appareil et de l’IP dans le même workflow.
Toutes les clés sont facultatives : une étape dont config est vide demande à l’appareil une position précise à 250 m, pas plus ancienne que 120 secondes, accorde 3 tentatives à la personne et n’applique aucune règle de zone.
Chaque constat possède sa propre clé d’action. Une clé d’action que vous ne définissez pas prend la valeur par défaut du geolocation_preset choisi, ou la valeur par défaut de chaque clé indiquée ci-dessous si aucun préréglage n’est choisi.
Une localisation incertaine ou refusée prend par défaut REVIEW, jamais DECLINE, car une autorisation refusée ou un rayon large ne sont pas une preuve de fraude.
Une action que vous définissez explicitement l’emporte toujours sur le préréglage.
Un défi rejoué (LOCATION_REPLAY_DETECTED) et une attestation d’appareil ayant échoué (LOCATION_INTEGRITY_FAILED) entraînent toujours un refus et n’ont pas de clé d’action.
Formes de zones
Chaque élément degeolocation_areas possède un id (de 1 à 64 caractères parmi A-Z a-z 0-9 _ -, unique dans la liste), un label facultatif (80 caractères maximum), un type égal à allowed ou blocked, et un kind qui détermine la forme.
Une liste contient au maximum 50 zones et doit comporter au moins une zone
allowed tant que is_geolocation_geofencing_enabled vaut true.
geolocation_areas et geolocation_geofencing_by_country ne peuvent pas être envoyés ensemble, et geolocation_refusal_path: "end_session" exige que geolocation_permission_denied_action soit REVIEW ou DECLINE.
L’API refuse une zone qui ne pourrait jamais correspondre, comme une région d’un pays sans frontières publiées, au lieu de l’enregistrer.
Exemple :
Justificatif de domicile
Valeur de fonctionnalité :PROOF_OF_ADDRESS.
Questionnaire
Valeur de fonctionnalité :QUESTIONNAIRE.
Registre KYB
Valeur de fonctionnalité :KYB_REGISTRY.
kyb_registry_fields_config associe chaque clé de champ configurable à {"enabled": bool, "required": bool}. enabled: false masque le champ, enabled: true, required: false l’affiche comme facultatif, et enabled: true, required: true le rend obligatoire à la soumission. company_name, country_code et region sont toujours affichés et obligatoires, et ne peuvent pas être configurés. Lorsque l’objet est omis, égal à null ou à {}, la valeur par défaut s’applique : seul incorporation_date est obligatoire et tous les autres champs sont facultatifs.
registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. Consultez champs configurables du formulaire de registre pour le comportement côté utilisateur final, et validation du numéro de TVA et de l’identifiant fiscal pour savoir comment vat_number et tax_number sont vérifiés.
Documents KYB
Valeur de fonctionnalité :KYB_DOCUMENTS.
Personnes clés KYB
Valeur de fonctionnalité :KYB_KEY_PEOPLE.
Document AI
Valeur de fonctionnalité :DOCUMENT_AI.
Demande un ou plusieurs documents à l’utilisateur et extrait les champs nommés que vous définissez à l’aide d’un modèle de vision. Chaque champ configuré devient une valeur exploitable dans les branchements, document_ai.<key>, et le résultat de l’étape est document_ai.status.
Chaque entrée de
document_ai_documents est un document :
Chaque entrée du tableau
fields d’un document est un champ :
Exemple :
Signature électronique
Valeur de la fonctionnalité :SIGNATURE.
Permet à la personne vérifiée, ou aux personnes clés d’une entreprise, de signer des documents, au niveau Simple (par défaut) ou Avancé (AES). Placez-la après les étapes qui vérifient le signataire : Vérification d’identité, et Vérification de l’e-mail ou du téléphone pour le code. Voir Signature électronique.
Les champs d’un document de workflow se placent dans l’éditeur de modèles de la console. Pour les documents de session, envoyez-les dans
sign.documents[].fields, et envoyez les valeurs des champs api.<key> dans sign.field_values. Voir Créer une session.
Exemple, pour des documents envoyés avec chaque session :