Geteilte Sitzung importieren: API für KYC & KYB

Liste der für diese Sitzung konfigurierten Verifizierungsfunktionen als Anzeigenamen: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (Standortverifizierung) (Sitzungen zur Unternehmensverifizierung verwenden das KYB-Funktionsset: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Bei include=events wird jeder Eintrag zu einem Objekt {feature, node_id} anstelle einer einfachen Zeichenkette, und die E-Mail-Funktion wird umbenannt: Sie erscheint im Ereignismodus als EMAIL anstelle des hier verwendeten EMAIL_VERIFICATION.

Array von Ausweisverifizierungsberichten (OCR), die von Ausweisdokument-Schritten im Workflow-Graphen erzeugt wurden. Immer ein JSON-Array – lesen Sie id_verifications[0] und iterieren Sie, falls Ihr Workflow mehr als eine Ausweisprüfung ausführen kann (beispielsweise eine primäre Prüfung plus eine zusätzliche Prüfung). null, bis mindestens ein Ausweisschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, extrahierten Dokumentfeldern, Bild-URLs, Qualitätswerten, MRZ, Adress-Parsing, sitzungsübergreifenden Übereinstimmungen sowie warnings[].

Array von NFC- / ePass-Berichten, die von NFC-Schritten im Workflow-Graphen erzeugt wurden. Dies ist immer ein JSON-Array, niemals ein einzelnes nfc-Objekt – lesen Sie nfc_verifications[0] und iterieren Sie, falls Ihr Workflow NFC mehr als einmal ausführen kann. null, bis mindestens ein NFC-Schritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, chip_protocol, chip_data, authenticity (SOD + DG-Integrität), certificate_summary sowie warnings[]. Eine japanische My Number Card wird über JPKI anstelle von ICAO 9303 ausgelesen: Ihr Eintrag weist chip_protocol: "jpki" auf, führt ihre Nachweise unter jpki und lässt die ICAO-Felder null. Wenn der NFC-Schritt übersprungen wurde, bevor er überhaupt angeboten werden konnte (Dokument ohne Chip, fehlendes Zertifikat, keine gemeldete NFC-Fähigkeit, unlesbarer MRZ-Schlüssel, JPKI für eine My Number Card nicht verfügbar), bleibt dies null und nfc_skip_reason erklärt den Grund; ein Überspringen beim Schritt selbst (Benutzer hat auf Überspringen getippt oder das Lesegerät war zum Scanzeitpunkt nicht verfügbar) erzeugt dennoch einen Bericht mit is_nfc_skipped: true.

Array von Berichten zur Liveness-Erkennung, die von Schritten zur Liveness-Erkennung im Workflow-Graphen erzeugt wurden. Immer ein JSON-Array – niemals ein einzelnes liveness-Objekt. null, bis mindestens ein Schritt zur Liveness-Erkennung Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, method, score, reference_image, video_url, optionaler age_estimation, sitzungsübergreifenden matches[] sowie warnings[].

Array von Gesichtsabgleichsberichten, die von Gesichtsabgleichsschritten im Workflow-Graphen erzeugt wurden. Immer ein JSON-Array – niemals ein einzelnes face_match-Objekt. null, bis mindestens ein Gesichtsabgleichsschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, Ähnlichkeits-score, source_image, target_image sowie warnings[].

Array von Telefonverifizierungsberichten – immer ein JSON-Array, niemals ein einzelnes phone-Objekt. null, bis mindestens ein Telefonschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, der Telefonnummer und Ländermetadaten, lifecycle[], matches[] sowie warnings[].

Array von E-Mail-Verifizierungsberichten – immer ein JSON-Array, niemals ein einzelnes email-Objekt. null, bis mindestens ein E-Mail-Schritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, der E-Mail-Adresse, Daten zu Datenlecks, lifecycle[], matches[] sowie warnings[].

Array von Adressnachweis-Berichten (POA) – immer ein JSON-Array, niemals ein einzelnes poa-Objekt. null, bis mindestens ein POA-Schritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, der Dokumentdatei-URL, Aussteller, Datumsangaben, geparster Adresse sowie warnings[].

Document AI-Berichte gruppiert nach Workflow-Knoten — immer ein JSON-Array, niemals ein einzelnes Objekt. null, bis mindestens ein Document AI-Schritt Daten erzeugt hat. Nur vorhanden, wenn session_kind = user. Jeder Eintrag ist eine Knotengruppe mit einem aggregierten status, der node_id, einem items[]-Array der Ergebnisse pro Dokument (extrahierte Daten zugeordnet nach dem konfigurierten Feldschlüssel) und warnings.

Array von Fragebogen-Antwortberichten – immer ein JSON-Array, niemals ein einzelnes questionnaire-Objekt. null, bis mindestens ein Fragebogenschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, der Fragebogen-Metadaten, Abschnitten mit Formularelementen sowie den Antworten des Benutzers.

Ergebnisse der Bankverifizierung, ein Eintrag pro Schritt der Bankverifizierung, für die Benutzer- und Unternehmensverifizierung. null, bis ein Schritt ein Ergebnis erzeugt. Das Feld method jedes Eintrags gibt an, wie das Konto verifiziert wurde: open_banking (Bank-Anmeldung) oder account_lookup (Kontoabfrage) oder ein statement- bzw. microdeposits-Fallback, und none, wenn die Person vor der Auswertung eines Versuchs ohne Bank fortgefahren ist (continued_without_bank). Siehe Bank-Verifizierungsmethoden.

E-Signatur-Ergebnisse, ein Element pro Unterzeichner und Signaturschritt, für Benutzerverifizierung und Unternehmensverifizierung (KYB). Nur vorhanden, wenn der Workflow einen E-Signatur-Schritt enthält; ein leeres Array, bis ein Unterzeichner diesen erreicht. Siehe den E-Signatur-Bericht.

Array von AML-Screening-Berichten — immer ein JSON-Array, niemals ein einzelnes aml-Objekt. null, bis mindestens ein AML-Schritt Daten erzeugt hat. Jedes Element ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled und warnings[].

Array von Geräte- und IP-Analyse-Berichten – immer ein JSON-Array, niemals ein einzelnes ip_analysis-Objekt. null, bis mindestens ein IP-Analyseschritt Daten erzeugt hat. Jeder Eintrag ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, IP- und Geolokalisierungsdaten, Geräte-Fingerprint sowie warnings[]. Einträge mit doppeltem (node_id, ip_address, device_fingerprint) werden serverseitig dedupliziert.

Array von Standortverifizierungsergebnissen, eines pro Standortverifizierungsschritt: der akzeptierte Versuch dieses Schritts. null, bis ein Standortverifizierungsschritt Daten erzeugt hat. Frühere Versuche desselben Schritts befinden sich in geolocation_attempts.

Jeder Versuch jedes Standortverifizierungsschritts dieser Sitzung, der älteste zuerst. Versuche, die durch eine erneute Einreichung ersetzt wurden, werden ausgelassen. Ein Workflow, der geolocation_checks über seine Antwort-Attribute zurückhält, hält auch diese Liste zurück.

Array von Berichten zur Datenbankvalidierung — immer ein JSON-Array, niemals ein einzelnes database_validation-Objekt. null, bis mindestens ein Schritt der Datenbankvalidierung Daten erzeugt hat. Jedes Element ist der vollständige Bericht, einschließlich node_id, status auf Funktionsebene, screened_data, der dienstspezifischen validations[] (jeweils mit ihren Register-source_data) und warnings[]. Die Felder screened_data und source_data variieren je nach Land:

ARG (Argentinien): 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}. Verwendet die biometrische Validierung des Gesichtsabgleichs von RENAPER. Das Geschlecht wird automatisch aus der Gesichtsanalyse oder dem Vornamen abgeleitet, wenn es im Dokument nicht vorhanden ist (z. B. bei Führerscheinen)

BOL (Bolivien): 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 (Brasilien): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data enthält für erfolgreiche CPF-Übereinstimmungen immer {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16}. Erfolgreiche Abfragen für Erwachsene setzen diese Flags auf false. Der Dienst Receita Federal Consulta CPF kann HTTP 422 (Minderjährige unter 18) oder 451 (unter 16) mit durch das LGPD zurückgehaltenen Daten zurückgeben; in diesen Fällen setzt source_data die Minor-Flags entsprechend auf true, enthält den Upstream-HTTP-Status, und die Validierung auf Feldebene lautet no_match. Die vollständige Codeliste finden Sie im Abschnitt zu Brasilien in der Referenz zu den Ergebnis-Codes der Datenbankvalidierung.

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

COL (Kolumbien): 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 (Dominikanische Republik): screened_data: {personal_number}. source_data: {identification_number} (gibt nur valid/invalid zurück)

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 (Spanien): 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 (Mexiko): 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}. Verwendet das Zivilregister RENAPO. Für MEX ist außerdem ein separater INE-Gültigkeitsprüfungsdienst als zusätzliche Einzelvalidierung verfügbar.

PAN (Panama): screened_data: {personal_number, selfie}. source_data: {identification_number}. Verwendet die biometrische SIB-Validierung

PER (Peru): 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}

Prüfungen des Unternehmensregisters. Nur vorhanden, wenn session_kind = business. Jedes Element enthält die vollständige Unternehmensregister-Payload.

Aggregierte Prüfungen der Schlüsselpersonen. Nur vorhanden, wenn session_kind = business. Jedes Element verwendet die Zwei-Bucket-Struktur (registry, submitted, ubo_kyc_summary).

Prüfungen der Dokumentenverifizierung, gruppiert nach Workflow-Knoten. Nur vorhanden, wenn session_kind = business.

Wird nur mit include=resubmissions zurückgegeben, für Benutzer- und Unternehmenssitzungen. Ein Eintrag pro erneuter Einreichungsanfrage, die ältesten zuerst. Jeder Eintrag enthält die Ergebnisse, die die erneut eingereichten Schritte vor der Anfrage zurückgegeben haben, sodass frühere Einreichungen lesbar bleiben. Durch das Löschen der Sitzung werden alle Einreichungen gelöscht.