API d'import de session partagée : KYC réutilisable

Liste des fonctionnalités de vérification configurées pour cette session, sous forme de noms d'affichage : ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (vérification de la localisation) (les sessions de Vérification d'entreprise (KYB) utilisent l'ensemble de fonctionnalités KYB : KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Avec include=events, chaque entrée devient un objet {feature, node_id} au lieu d'une simple chaîne, et la fonctionnalité d'e-mail est renommée : elle apparaît sous la forme EMAIL en mode événements au lieu de EMAIL_VERIFICATION utilisé ici.

Tableau de rapports de Vérification d'identité (OCR) produits par les étapes de document d'identité dans le graphe du workflow. Toujours un tableau JSON — lisez id_verifications[0] et itérez si votre workflow peut exécuter plusieurs vérifications d'identité (par exemple une vérification principale plus un contrôle renforcé). null jusqu'à ce qu'au moins une étape d'identité ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, les champs de document extraits, les URL des images, les scores de qualité, la MRZ, l'analyse d'adresse, les correspondances entre sessions et warnings[].

Tableau de rapports NFC / passeport électronique produits par les étapes NFC dans le graphe du workflow. Il s'agit toujours d'un tableau JSON, jamais d'un objet nfc singulier — lisez nfc_verifications[0] et itérez si votre workflow peut effectuer une vérification NFC plus d'une fois. null jusqu'à ce qu'au moins une étape NFC ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, chip_protocol, chip_data, authenticity (intégrité SOD + DG), certificate_summary et warnings[]. Une carte My Number japonaise est lue via JPKI au lieu de l'OACI 9303 : son élément a chip_protocol: "jpki", contient ses preuves sous jpki, et laisse les champs OACI à null. Lorsque l'étape NFC a été ignorée avant même d'avoir pu être proposée (document sans puce, certificat manquant, aucune capacité NFC signalée, clé MRZ illisible, JPKI indisponible pour une carte My Number), cela reste null et nfc_skip_reason en explique la raison ; un contournement au niveau de l'étape elle-même (l'utilisateur a appuyé sur ignorer, ou le lecteur s'est révélé indisponible au moment de la lecture) produit tout de même un rapport avec is_nfc_skipped: true.

Tableau de rapports de détection du vivant produits par les étapes de détection du vivant dans le graphe du workflow. Toujours un tableau JSON — jamais un objet liveness singulier. null jusqu'à ce qu'au moins une étape de détection du vivant ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, method, score, reference_image, video_url, l'age_estimation facultative, les matches[] entre sessions et warnings[].

Tableau de rapports de correspondance faciale produits par les étapes de correspondance faciale dans le graphe du workflow. Toujours un tableau JSON — jamais un objet face_match singulier. null jusqu'à ce qu'au moins une étape de correspondance faciale ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, le score de similarité, source_image, target_image et warnings[].

Tableau de rapports de vérification du téléphone — toujours un tableau JSON, jamais un objet phone singulier. null jusqu'à ce qu'au moins une étape de vérification du téléphone ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, le numéro de téléphone et les métadonnées de pays, lifecycle[], matches[] et warnings[].

Tableau de rapports de vérification d'e-mail — toujours un tableau JSON, jamais un objet email singulier. null jusqu'à ce qu'au moins une étape d'e-mail ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, l'adresse e-mail, les données de compromission, lifecycle[], matches[] et warnings[].

Tableau de rapports de Justificatif de domicile (POA) — toujours un tableau JSON, jamais un objet poa singulier. null jusqu'à ce qu'au moins une étape POA ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, l'URL du fichier du document, l'émetteur, les dates, l'adresse analysée et warnings[].

Rapports Document AI regroupés par nœud de workflow — toujours un tableau JSON, jamais un objet unique. null jusqu'à ce qu'au moins une étape Document AI ait produit des données. Présents uniquement lorsque session_kind = user. Chaque élément est un groupe de nœuds avec un status global, le node_id, un tableau items[] des résultats par document (données extraites indexées par la clé de champ configurée), et warnings.

Tableau de rapports de réponses aux questionnaires — toujours un tableau JSON, jamais un objet questionnaire singulier. null jusqu'à ce qu'au moins une étape de questionnaire ait produit des données. Chaque élément est le rapport complet, comprenant node_id, les métadonnées du questionnaire, les sections avec les éléments de formulaire et les réponses de l'utilisateur.

Résultats de la vérification bancaire, un élément par étape de vérification bancaire, pour la Vérification des utilisateurs et la Vérification d'entreprise (KYB). null jusqu'à ce qu'une étape en produise un. Le champ method de chaque élément indique comment le compte a été vérifié : open_banking (connexion bancaire) ou account_lookup (vérification de compte), ou une solution de repli statement ou microdeposits, et none lorsque la personne a continué sans banque avant qu'une tentative ne soit évaluée (continued_without_bank). Voir Méthodes de vérification bancaire.

Résultats de la Signature électronique, un élément par signataire et par étape de signature, pour la Vérification des utilisateurs et la Vérification d'entreprise. Présent uniquement lorsque le workflow comprend une étape de Signature électronique ; tableau vide jusqu'à ce qu'un signataire l'atteigne. Voir le rapport de Signature électronique.

Tableau de rapports de filtrage AML — toujours un tableau JSON, jamais un objet aml unique. null jusqu'à ce qu'au moins une étape AML ait produit des données. Chaque élément est le rapport complet, incluant node_id, le status au niveau de la fonctionnalité, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled et warnings[].

Tableau de rapports d'Analyse de l'appareil et de l'IP — toujours un tableau JSON, jamais un objet ip_analysis singulier. null jusqu'à ce qu'au moins une étape d'analyse IP ait produit des données. Chaque élément est le rapport complet, comprenant node_id, le status au niveau de la fonctionnalité, les données IP et de géolocalisation, l'empreinte de l'appareil et warnings[]. Les entrées présentant un doublon (node_id, ip_address, device_fingerprint) sont dédupliquées côté serveur.

Tableau de résultats de vérification de localisation, un par étape de vérification de localisation : la tentative acceptée de cette étape. null jusqu'à ce qu'une étape de vérification de localisation ait produit des données. Les tentatives antérieures de la même étape se trouvent dans geolocation_attempts.

Chaque tentative de chaque étape de vérification de localisation de cette session, de la plus ancienne à la plus récente. Les tentatives remplacées par une nouvelle soumission sont exclues. Un workflow qui masque geolocation_checks via ses attributs de réponse masque également cette liste.

Tableau de rapports de Validation en base de données — toujours un tableau JSON, jamais un objet database_validation singulier. null jusqu'à ce qu'au moins une étape de validation en base de données ait produit des données. Chaque élément correspond au rapport complet, incluant node_id, le status au niveau de la fonctionnalité, screened_data, les validations[] par service (chacune avec son source_data de registre) et warnings[]. Les champs screened_data et source_data varient selon le pays :

ARG (Argentine) : screened_data : {document_number, selfie, gender, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Utilise la validation biométrique par correspondance faciale de RENAPER. Le genre est automatiquement déduit de l'analyse du visage ou du prénom lorsqu'il n'est pas présent sur le document (ex. permis de conduire)

BOL (Bolivie) : screened_data : {document_number, date_of_birth, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (Brésil) : screened_data : {tax_number, first_name, last_name, date_of_birth}. source_data inclut toujours {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} pour les correspondances CPF réussies. Les recherches réussies pour les adultes définissent ces indicateurs à false. Le service Consulta CPF de la Receita Federal peut renvoyer HTTP 422 (mineur de moins de 18 ans) ou 451 (moins de 16 ans) avec des données retenues en vertu de la LGPD ; dans ces cas, source_data définit les indicateurs de minorité à true selon le cas, inclut le statut HTTP en amont, et la validation au niveau du champ est no_match. Consultez la section Brésil de la référence des codes de résultat de la Validation en base de données pour la liste complète des codes.

CHL (Chili) : screened_data : {personal_number, first_name, last_name, date_of_birth}. source_data : {identification_number, first_name, last_name, date_of_birth, gender}

COL (Colombie) : screened_data : {document_number, document_type, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (Costa Rica) : screened_data : {personal_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}

DOM (République dominicaine) : screened_data : {personal_number}. source_data : {identification_number} (renvoie valid/invalid uniquement)

ECU (Équateur) : screened_data : {personal_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (Espagne) : screened_data : {personal_number, document_type, expiration_date, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (Guatemala) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}

HND (Honduras) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}

MEX (Mexique) : screened_data : {personal_number (CURP), first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Utilise le registre d'état civil RENAPO. Un service distinct de vérification de validité INE est également disponible pour MEX en tant que validation supplémentaire individuelle.

PAN (Panama) : screened_data : {personal_number, selfie}. source_data : {identification_number}. Utilise la validation biométrique SIB

PER (Pérou) : screened_data : {personal_number (DNI), first_name, last_name}. source_data : {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (Paraguay) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}

SLV (Salvador) : screened_data : {document_number, date_of_birth, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}

URY (Uruguay) : screened_data : {personal_number, date_of_birth, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name}

VEN (Venezuela) : screened_data : {document_number, first_name, last_name}. source_data : {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

Vérifications au registre des sociétés. Présent uniquement lorsque session_kind = business. Chaque élément encapsule le payload complet du registre des sociétés.

Vérifications agrégées des personnes clés. Présent uniquement lorsque session_kind = business. Chaque élément utilise la structure à deux compartiments (registry, submitted, ubo_kyc_summary).

Vérifications de documents groupées par nœud de workflow. Présentes uniquement lorsque session_kind = business.

Renvoyé uniquement avec include=resubmissions, pour les sessions utilisateur et d'entreprise. Une entrée par demande de resoumission, de la plus ancienne à la plus récente. Chaque entrée contient les résultats renvoyés par les étapes resoumises avant la demande, afin que les soumissions antérieures restent consultables. La suppression de la session supprime toutes les soumissions.