KYC riutilizzabile: API per importare sessione condivisa

Elenco delle funzionalità di verifica configurate per questa sessione, come nomi visualizzati: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (Verifica della posizione) (le sessioni di Verifica aziendale utilizzano il set di funzionalità KYB: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Con include=events ogni voce diventa un oggetto {feature, node_id} invece di una semplice stringa, e la funzionalità email viene rinominata: compare come EMAIL in modalità eventi invece dell'EMAIL_VERIFICATION utilizzato qui.

Array di report di verifica dell'identità (OCR) prodotti dai passaggi dei documenti di identità nel grafo del workflow. Sempre un array JSON — leggi id_verifications[0] e itera se il tuo workflow può eseguire più di un controllo dell'identità (ad esempio un controllo primario più uno step-up). null fino a quando almeno un passaggio di verifica dell'identità non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, campi estratti del documento, URL delle immagini, punteggi di qualità, MRZ, analisi dell'indirizzo, corrispondenze cross-sessione e warnings[].

Array di report NFC / passaporto elettronico prodotti dai passaggi NFC nel grafo del workflow. Questo è sempre un array JSON, mai un singolo oggetto nfc — leggi nfc_verifications[0] e itera se il tuo workflow può eseguire l'NFC più di una volta. null fino a quando almeno un passaggio NFC non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, chip_protocol, chip_data, authenticity (integrità SOD + DG), certificate_summary e warnings[]. Una Japan My Number Card viene letta tramite JPKI anziché ICAO 9303: il relativo elemento ha chip_protocol: "jpki", contiene le prove sotto jpki e lascia i campi ICAO null. Quando il passaggio NFC è stato ignorato prima ancora di poter essere proposto (documento senza chip, certificato mancante, nessuna funzionalità NFC segnalata, chiave MRZ illeggibile, JPKI non disponibile per una My Number Card), questo rimane null e nfc_skip_reason ne spiega il motivo; se viene ignorato durante il passaggio stesso (l'utente ha toccato il pulsante «Ignora» o il lettore è risultato non disponibile al momento della scansione) viene comunque prodotto un report con is_nfc_skipped: true.

Array di report di rilevamento della vitalità prodotti dai passaggi di rilevamento della vitalità nel grafo del workflow. Sempre un array JSON — mai un singolo oggetto liveness. null fino a quando almeno un passaggio di rilevamento della vitalità non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, method, score, reference_image, video_url, age_estimation opzionale, matches[] cross-sessione e warnings[].

Array di report di confronto facciale prodotti dai passaggi di confronto facciale nel grafo del workflow. Sempre un array JSON — mai un singolo oggetto face_match. null fino a quando almeno un passaggio di confronto facciale non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, lo score di similarità, source_image, target_image e warnings[].

Array di report di verifica telefonica — sempre un array JSON, mai un singolo oggetto phone. null fino a quando almeno un passaggio telefonico non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, il numero di telefono e i metadati del paese, lifecycle[], matches[] e warnings[].

Array di report di verifica email — sempre un array JSON, mai un singolo oggetto email. null fino a quando almeno un passaggio email non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, l'indirizzo email, i dati sulle violazioni, lifecycle[], matches[] e warnings[].

Array di report di Prova di residenza (POA) — sempre un array JSON, mai un singolo oggetto poa. null fino a quando almeno un passaggio POA non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, l'URL del file del documento, l'ente emittente, le date, l'indirizzo analizzato e warnings[].

Report di Document AI raggruppati per nodo del workflow — sempre un array JSON, mai un singolo oggetto. null finché almeno un passaggio di Document AI non ha prodotto dati. Presente solo quando session_kind = user. Ogni elemento è un gruppo di nodi con uno status aggregato, il node_id, un array items[] dei risultati per documento (dati estratti indicizzati dalla chiave di campo configurata) e warnings.

Array di report delle risposte ai questionari — sempre un array JSON, mai un singolo oggetto questionnaire. null fino a quando almeno un passaggio con questionario non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, i metadati del questionario, le sezioni con gli elementi del modulo e le risposte dell'utente.

Risultati della verifica bancaria, un elemento per ciascun passaggio di verifica bancaria, per la Verifica degli utenti e la Verifica aziendale. null finché un passaggio non ne produce uno. Il parametro method di ciascun elemento indica come è stato verificato il conto: open_banking (accesso bancario) o account_lookup (controllo del conto), oppure un'alternativa tramite statement o microdeposits, e none quando la persona ha proseguito senza una banca prima della valutazione di qualsiasi tentativo (continued_without_bank). Consulta Metodi di verifica bancaria.

Risultati di Firma elettronica, un elemento per ciascun firmatario e passaggio di firma, per la Verifica degli utenti e la Verifica aziendale (KYB). Presente solo quando il workflow ha un passaggio di Firma elettronica; un array vuoto finché un firmatario non lo raggiunge. Consulta il report di Firma elettronica.

Array di report di screening AML — sempre un array JSON, mai un singolo oggetto aml. null finché almeno un passaggio AML non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled e warnings[].

Array di report di Analisi dispositivo e IP — sempre un array JSON, mai un singolo oggetto ip_analysis. null fino a quando almeno un passaggio di analisi IP non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, dati IP e di geolocalizzazione, fingerprint del dispositivo e warnings[]. Le voci con (node_id, ip_address, device_fingerprint) duplicati vengono deduplicate lato server.

Array di risultati della verifica della posizione, uno per ciascun passaggio di verifica della posizione: il tentativo accettato di quel passaggio. null fino a quando un passaggio di verifica della posizione non ha prodotto dati. I tentativi precedenti dello stesso passaggio si trovano in geolocation_attempts.

Ogni tentativo di ciascun passaggio di verifica della posizione di questa sessione, dal più vecchio al più recente. I tentativi sostituiti da un nuovo invio vengono omessi. Un workflow che esclude geolocation_checks tramite i propri attributi di risposta esclude anche questo elenco.

Array di report di Validazione su database — sempre un array JSON, mai un singolo oggetto database_validation. null finché almeno un passaggio di validazione su DB non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, lo status a livello di funzionalità, screened_data, i validations[] per servizio (ciascuno con i relativi source_data del registro) e warnings[]. I campi screened_data e source_data variano in base al paese:

ARG (Argentina): 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}. Utilizza la validazione biometrica di confronto facciale RENAPER. Il genere viene dedotto automaticamente dall'analisi del volto o dal nome proprio quando non è presente nel documento (es. patenti di guida)

BOL (Bolivia): 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 (Brasile): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data include sempre {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} per corrispondenze CPF riuscite. Le ricerche riuscite per adulti impostano tali flag su false. Il servizio Consulta CPF della Receita Federal può restituire HTTP 422 (minore di 18 anni) o 451 (minore di 16 anni) con dati omessi in conformità alla LGPD; in tali casi source_data imposta i flag per minori su true come opportuno, include il codice di stato HTTP del servizio upstream e la validazione a livello di campo è no_match. Consulta la sezione Brasile del riferimento Database Validation Outcome Codes per l'elenco completo dei codici.

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

COL (Colombia): 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 (Repubblica Dominicana): screened_data: {personal_number}. source_data: {identification_number} (restituisce solo valid/invalid)

ECU (Ecuador): 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 (Spagna): 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 (Messico): 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}. Utilizza il registro civile RENAPO. È inoltre disponibile un servizio separato di controllo validità INE per MEX come validazione aggiuntiva una per volta.

PAN (Panama): screened_data: {personal_number, selfie}. source_data: {identification_number}. Utilizza la validazione biometrica SIB

PER (Perù): 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 (El 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}

Controlli del registro delle imprese. Presente solo quando session_kind = business. Ciascun elemento include l'intero payload del registro delle imprese.

Controlli aggregati sulle persone chiave. Presente solo quando session_kind = business. Ciascun elemento utilizza la struttura a due contenitori (registry, submitted, ubo_kyc_summary).

Controlli di verifica del documento raggruppati per nodo del workflow. Presenti solo quando session_kind = business.

Restituito solo con include=resubmissions, per sessioni utente e aziendali. Una voce per ogni richiesta di nuovo invio, dalla meno recente alla più recente. Ogni voce include i risultati restituiti dai passaggi reinviati prima della richiesta, in modo che i precedenti invii rimangano leggibili. L'eliminazione della sessione elimina tutti gli invii.