> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Workflow-Funktionskonfigurationen: API-Referenz > Didit-Referenz für alle Konfigurationsfelder von POST und PATCH /v3/workflows/ zum Erstellen linearer Workflows mit dem features-Array. Verwenden Sie diese `config`-Felder innerhalb jedes Elements des `features`-Arrays für [`POST /v3/workflows/`](https://docs.didit.me/de/management-api/workflows/create) und [`PATCH /v3/workflows/{settings_uuid}/`](https://docs.didit.me/de/management-api/workflows/update). ```json theme={null} { "workflow_label": "Standard KYC", "features": [ { "feature": "OCR", "config": { "documents_allowed": { "USA": { "DL": { "enabled": 1, "sides": 2 } } } } } ] } ``` Die v3-Workflow-API erstellt einen linearen, knotenbasierten Workflow aus dem geordneten `features`-Array. Senden Sie Funktionen in der exakten Ausführungsreihenfolge. > [!NOTE] > > Welche Engine eine Funktion ausführt – Didits eigene oder die eines Drittanbieters – ist keines der unten aufgeführten Konfigurationsfelder. Dies wird über den [Marketplace](https://docs.didit.me/de/console/marketplace.md) der Konsole verwaltet, der `provider_key` und `fallback_to_native` im `config`-Objekt der Funktion für Sie festlegt. ## Validierungsregeln * `OCR` verwendet standardmäßig alle unterstützten Länder und Dokumenttypen, wenn `config.documents_allowed` weggelassen wird, `null` oder `{}` ist. Wenn Sie ein benutzerdefiniertes `documents_allowed`-Objekt senden, muss es mindestens ein gültiges Land und einen aktivierten Dokumenttyp enthalten. Jede Dokumentkonfiguration kann `sides` auf `1` für die Erfassung nur der Vorderseite oder auf `2` für die Erfassung von Vorder- und Rückseite setzen. * `QUESTIONNAIRE` erfordert `config.questionnaire_uuid`. * `KYB_DOCUMENTS` erfordert `config.kyb_required_document_groups`. * `SIGNATURE` lehnt `signature_level: "qes"` mit `qes_not_available` ab, bis qualifizierte Signaturen verfügbar sind, und einen neuen Schritt mit `signature_level: "aes"` mit `aes_not_available`, solange `signature_availability.aes` im Workflow `false` ist. Seine Dokumente müssen vorhanden sein, wenn eine Sitzung erstellt wird: Wenn `signature_documents_source` auf `workflow` gesetzt ist, benötigt der Schritt in der Konsole hochgeladene Dokumente, und ein Schritt ohne Dokumente kann als Entwurf verbleiben, aber nicht live geschaltet werden; bei `session` muss jede Erstellungsanfrage `sign.documents` enthalten. * `FACE_MATCH` muss in einfachen Workflow-Anfragen nach `OCR` folgen. * `NFC` und `DATABASE_VALIDATION` erfordern `OCR`, wenn sie im selben Workflow vorkommen. `AML` benötigt eines von `OCR`, `KYB_REGISTRY` oder `DOCUMENT_AI` vor sich; wenn nur `DOCUMENT_AI` davor steht, muss der zu prüfende `full_name` befüllbar sein – entweder über ein vorgelagertes Document AI-Feld, das bereits den Schlüssel `full_name` trägt und automatisch zugeordnet wird, oder über einen expliziten Eintrag in `config.aml_field_sources` (siehe [AML](#aml)). * KYB-Unterfunktionen wie `KYB_DOCUMENTS` und `KYB_KEY_PEOPLE` erfordern `KYB_REGISTRY` an einer früheren Stelle im Workflow. * Ein Workflow ist entweder ein Personen-Workflow (KYC) oder ein Unternehmens-Workflow (KYB), niemals beides. Ein Workflow, der eine beliebige KYB-Funktion (`KYB_REGISTRY`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE`) verwendet, darf diese nur mit `AML`, `DOCUMENT_AI`, `QUESTIONNAIRE`, `PHONE_VERIFICATION`, `EMAIL_VERIFICATION`, `IP_ANALYSIS` und `SIGNATURE` kombinieren. Er darf keine reinen Personenfunktionen wie `OCR`, `LIVENESS`, `FACE_MATCH`, `NFC`, `PROOF_OF_ADDRESS`, `DATABASE_VALIDATION` oder `AGE_ESTIMATION` enthalten, und ein Personen-Workflow darf keine KYB-Funktionen enthalten. In einem Unternehmens-Workflow gleicht `DOCUMENT_AI` jedes als `is_full_name` gekennzeichnete Feld mit dem verifizierten Unternehmen statt mit einer Person ab. Um die Personen hinter einem Unternehmen zu verifizieren, erstellen Sie einen separaten KYC-Workflow und verweisen Sie im `KYB_KEY_PEOPLE`-Knoten mithilfe von `kyb_ubo_verification_workflow`, `kyb_officer_verification_workflow` oder `kyb_shareholder_verification_workflow` darauf. * Aktionsfelder verwenden `DECLINE`, `REVIEW` oder `NO_ACTION`, sofern das jeweilige Feld unten nicht als eingeschränkt angegeben ist. * Score- und Schwellenwert-Felder sind Zahlen von `0` bis `100`, sofern kein engerer Bereich angegeben ist. ## Allgemeine Statusregeln Jede Funktion unterstützt ein optionales `status_rules`-Array. Verwenden Sie es, um den Funktionsstatus zu überschreiben, wenn eine Feldbedingung zutrifft. ```json theme={null} { "status_rules": [ { "field": "kyc.issuing_state", "operator": "in", "value": ["VEN", "IRN"], "status": "In Review", "value_type": "literal" }, { "field": "kyc.extra_fields.profession", "operator": "fuzzy_match", "value": "Soft. Engineer", "score": 80, "status": "Declined", "value_type": "literal" }, { "field": "kyc.extra_fields.dl_class_code_b_to", "operator": "less_than", "value": "2030-01-01", "status": "In Review", "value_type": "literal" }, { "field": "kyc.extra_fields.dl_class_code_b_from", "operator": "less_than", "value": { "direction": "past", "amount": 3, "unit": "years" }, "status": "Declined", "value_type": "relative_date" } ] } ``` | Feld | Typ | Beschreibung | | - | - | - | | `field` | string | Zu prüfender Feldpfad, z. B. `kyc.issuing_state` oder `kyc.document_type`. | | `operator` | string | Einer der folgenden Werte: `equals`, `not_equals`, `greater_than`, `greater_than_or_equals`, `less_than`, `less_than_or_equals`, `contains`, `not_contains`, `in`, `not_in`, `is_empty`, `is_not_empty`, `regex` oder `fuzzy_match`. | | `value` | any | Vergleichswert. Für Operatoren, die keinen Wert benötigen, weglassen oder `null` übergeben. | | `status` | string | Einer der folgenden Werte: `Approved`, `Declined`, `In Review` oder `No Action`. | | `value_type` | string | Optional. Standardmäßig `literal`. Verwenden Sie `field`, um mit einem anderen Feld zu vergleichen, `list`, um eine Didit-Listen-UUID zur Laufzeit aufzulösen, oder `relative_date`, um ein Datumsfeld mit dem heutigen Datum plus/minus einer Dauer zu vergleichen. | | `score` | number | Erforderlich für `fuzzy_match`. Mindest-Ähnlichkeitswert von `0` bis `100`. Die Regel greift, wenn die berechnete Ähnlichkeit größer oder gleich diesem Wert ist (`similarity >= score`). Beispielsweise kann `Software Engineer` mit `Soft. Engineer` übereinstimmen, wenn die Ähnlichkeit mindestens `80` beträgt. | Lesen Sie das obige Beispiel wie folgt: `kyc.extra_fields.profession` stimmt mittels Fuzzy-Matching mit `Soft. Engineer` überein, wobei der Mindestwert `80` beträgt → setzen Sie den Funktionsstatus auf `Declined`. Zielen Sie bei der Ausweisverifizierung auf extrahierte `extra_fields`-Werte wie `kyc.extra_fields.profession`, Gültigkeitsdaten von Führerscheinklassen wie `kyc.extra_fields.dl_class_code_b_from` und `kyc.extra_fields.dl_class_code_b_to` oder klassenspezifische Einschränkungs-/Informationscodes wie `kyc.extra_fields.dl_class_code_b_notes` (Spalte 12 bei Führerscheinen aus dem Vereinigten Königreich) ab. Diese Werte stammen aus dem `extra_fields`-Objekt des OCR-Ergebnisses; sie sind nicht Teil von `expected_details`. > [!NOTE] > > `dl_class_code_*_from` und `dl_class_code_*_to` sind immer entweder ein gültiges ISO-Datum oder in `extra_fields` nicht vorhanden – Didit gibt in einem Datumsfeld niemals unlesbaren OCR-Text zurück. Wenn die Zelle der Klassentabelle nicht gelesen werden kann, wird das Feld weggelassen, anstatt als Roh-String gesendet zu werden. Verwenden Sie daher den Operator `is_empty`, um unlesbare Gültigkeitsdaten von Führerscheinklassen weiterzuleiten, anstatt davon auszugehen, dass das Feld immer vorhanden ist. Verwenden Sie für Datumsfelder `value_type: "relative_date"` mit einem Wertobjekt im Format `{ "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }`. Beispielsweise findet `operator: "less_than"` mit `{ "direction": "past", "amount": 3, "unit": "years" }` Datumswerte, die mehr als drei Jahre vor dem heutigen Datum liegen. ### Mit einem bestimmten Schritt vergleichen Ein Graph-Workflow kann dieselbe Funktion mehr als einmal ausführen, beispielsweise drei Schritte zur Ausweisverifizierung. Hängen Sie bei `value_type: "field"` das Suffix `@` an den Wert an, um ihn aus einem bestimmten Schritt auszulesen. Der referenzierte Knoten muss ein Funktionsschritt sein, der auf jedem Pfad, der den eigenen Schritt der Regel erreicht, immer vor diesem ausgeführt wird, oder der eigene Schritt der Regel selbst. Ein Wert ohne das Suffix wird aus dem eigenen Schritt der Regel ausgelesen. ```json theme={null} { "status_rules": [ { "field": "kyc.full_name", "operator": "fuzzy_match", "value": "kyc.full_name@ocr_1", "value_type": "field", "score": 80, "status": "Declined" } ] } ``` Lesen Sie diese Regel, die auf dem dritten Schritt zur Ausweisverifizierung konfiguriert ist, wie folgt: Wenn `kyc.full_name` dieses Schritts mittels Fuzzy-Matching mit dem durch Schritt `ocr_1` gelesenen vollständigen Namen mit einem Mindestwert von `80` übereinstimmt → setzen Sie den Funktionsstatus auf `Declined`. In der Konsole listet die Variablenauswahl jeden berechtigten Schritt anhand seiner Nummer auf dem Canvas auf und speichert das Suffix automatisch für Sie. ## OCR / Ausweisverifizierung Funktionswert: `OCR`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `documents_allowed` | object | Optional. Weglassen, `null` oder `{}` senden, um jedes unterstützte Land und jeden unterstützten Dokumenttyp zuzulassen. Senden Sie eine Konfiguration von ISO3-Ländercodes zu Dokumenttypen nur dann, wenn Sie die zulässigen Dokumente einschränken möchten. Mindestens ein benutzerdefiniertes Dokument muss `enabled: 1` haben. Dokumentkonfigurationen können `sides: 1` für die Erfassung nur der Vorderseite oder `sides: 2` für die Erfassung von Vorder- und Rückseite enthalten. Zu den Dokumenttypen gehören `P`, `ID`, `DL`, `RP`, `HIC`, `TC`, `SSC` und weitere vom jeweiligen Land unterstützte Werte. | | `methods` | object | Welche der drei [Ausweisverifizierungsmethoden](https://docs.didit.me/de/core-technology/id-verification/verification-methods.md) jedes Land verwenden darf: Dokumentenerfassung, Abfrage ohne Dokument gegen eine behördliche oder andere maßgebliche Quelle sowie digitale ID-Wallets. Wenn der Schlüssel, ein Land oder eine Methode innerhalb eines Landes weggelassen wird, ist für dieses Land nur die Dokumentenerfassung zulässig. Jede Methode und jedes Wallet muss im Funktionskatalog für das Land als verfügbar markiert sein, andernfalls wird das Speichern abgelehnt. Siehe [Methoden pro Land](#methoden-pro-land) unten. | | `document_blur_fields_by_country` | object | ISO3-Ländercode zu Feldnamen, die auf Dokumentbildern unkenntlich gemacht (geschwärzt) werden sollen. | | `image_capture_methods_allowed` | string\[] | Zulässige Erfassungsmethoden. Werte umfassen `CAMERA_SCAN` und `UPLOAD`. | | `duplicated_user_action` | action | Aktion für einen duplizierten Benutzer. | | `is_age_restrictions_enabled` | boolean | Aktiviert Mindest- und Höchstalterprüfungen. | | `age_restrictions_by_country` | object | ISO3-Ländercode zu einer Alterskonfiguration mit `minimum_age`, optionalem `maximum_age` und optionalen `states`. | | `minimum_age` | integer | Globales Mindestalter, `1` bis `120`. | | `minimum_age_action` | action | Aktion, wenn der Benutzer unter dem `minimum_age` liegt. | | `maximum_age` | integer | Globales Höchstalter, `1` bis `120`. | | `maximum_age_action` | action | Aktion, wenn der Benutzer über dem `maximum_age` liegt. | | `expiration_date_not_detected_action` | action | Aktion, wenn das Ablaufdatum des Dokuments fehlt. | | `invalid_code_action` | action | Aktion, wenn ein Barcode oder maschinenlesbarer Code ungültig ist. | | `invalid_mrz_action` | action | Aktion, wenn die MRZ ungültig ist. | | `inconsistent_data_action` | action | Aktion, wenn extrahierte Dokumentfelder widersprüchlich sind. | | `invalid_validation_action` | action | Aktion, wenn die Dokumentvalidierung fehlschlägt. | | `expected_details_mismatch_action` | action | Aktion, wenn die erwarteten Benutzerdetails nicht mit dem Dokument übereinstimmen. | | `image_too_blurry_action` | action | Aktion bei unscharfen Dokumentbildern. | | `image_too_dark_action` | action | Aktion bei zu dunklen Dokumentbildern. | | `image_too_bright_action` | action | Aktion bei überbelichteten Dokumentbildern. | | `unparsed_address_action` | action | Aktion, wenn die Dokumentadresse nicht geparst werden kann. | | `address_validation_enabled` | boolean | Validiert die in diesem Schritt gelesene Adresse (auf dem Ausweisdokument aufgedruckt) gegen postalische Referenzdaten: Es wird bestätigt, dass die Adresse existiert, und sie wird normalisiert; sie wird niemals mit einer Person verknüpft. Das Ergebnis ist das `address_validation`-Objekt dieses Schritts in der Entscheidung. **Kosten: \$0.10 pro validierter Adresse**; eine Validierung, die nicht ausgeführt werden konnte (`unavailable`), ist kostenlos. Standardmäßig deaktiviert. | | `address_not_verified_action` | action | Aktion, wenn die Adressvalidierung die Adresse nicht bis auf Gebäudeebene bestätigen konnte (`ADDRESS_NOT_VERIFIED`: `partially_verified` oder `not_verified`). Gilt nur, wenn `address_validation_enabled` aktiviert ist. Standardmäßig `NO_ACTION`, wodurch lediglich die Warnung protokolliert wird. | | `document_or_personal_number_format_mismatch_action` | action | Aktion, wenn das Format der Dokument- oder Personennummer nicht dem erwarteten Muster entspricht. | | `critical_field_occlusion_action` | action | Aktion, wenn die Verdeckungsprüfung meldet, dass ein kritisches gedrucktes Feld – eine Identifikationsnummer, ein Name, das Geburtsdatum oder das Ablaufdatum – auf dem erfassten Dokument physisch verdeckt war. Das Verdecken einer Identifikationsnummer ist eher ein Manipulationssignal als ein Problem der Aufnahmequalität, daher ist die Standardeinstellung `REVIEW`; der für ein verdecktes Feld gelesene Wert wird in jedem Fall aus der Extraktion verworfen. Erhöhen Sie den Wert auf `DECLINE`, wenn ein geschwärztes Dokument niemals einen Prüfer erreichen darf. | | `document_without_portrait_action` | action | Aktion, wenn der erkannte Dokumenttyp auf keiner Seite ein Porträtfoto enthält (einige Aufenthaltstitel, Krankenversichertenkarten, Meldebescheinigungen und andere laut Katalog porträtlose Dokumentfamilien). Standardmäßig `REVIEW`. Ziehen Sie `DECLINE` in Betracht, wenn der Gesichtsabgleich die Identitätsprüfung des Workflows verankert. | | `is_document_selfie_portrait_match_enabled` | boolean | Aktiviert den Abgleich des Dokumentporträts mit dem Selfie. | | `document_selfie_portrait_match_decline_threshold` | integer | Ablehnungsschwellenwert für den Abgleich zwischen Dokumentporträt und Selfie. | | `document_selfie_portrait_match_review_threshold` | integer | Prüfschwellenwert für den Abgleich zwischen Dokumentporträt und Selfie. | | `document_selfie_face_search_enabled` | boolean | Führt die [Gesichtssuche 1:N](https://docs.didit.me/de/core-technology/face-search/overview.md#das-bei-der-dokumentenerfassung-aufgenommene-selfie) auf dem während der Dokumentenerfassung aufgenommenen Selfie aus (erfordert `is_document_selfie_portrait_match_enabled`): gleicht es mit der Gesichts-Sperrliste und zuvor verifizierten Benutzern ab. Das Selfie wird nur verglichen, sein biometrisches Template wird niemals gespeichert. Standardmäßig aktiviert. `false` überspringt die Suche, sodass die Aktionen für duplizierte Gesichter beim Dokument-Selfie keine Datengrundlage haben; `face_search_enabled: false` im Liveness-Schritt überspringt sie ebenfalls, da dieses Opt-out jedes Selfie der Sitzung abdeckt. | | `document_selfie_duplicated_face_action` | action | Entscheidung, wenn das Selfie der Dokumentenerfassung mit dem Gesicht eines in dieser Anwendung bereits verifizierten Benutzers übereinstimmt oder möglicherweise übereinstimmt. Standardmäßig `NO_ACTION`. | | `document_selfie_duplicated_face_name_mismatch_action` | action | Entscheidung, wenn das Selfie der Dokumentenerfassung mit einem bereits unter einem anderen Namen verifizierten Benutzer übereinstimmt. Kann `document_selfie_duplicated_face_action` nur eskalieren. Standardmäßig `REVIEW`. | | `document_selfie_duplicated_face_document_mismatch_action` | action | Entscheidung, wenn das Selfie der Dokumentenerfassung mit einem bereits verifizierten Benutzer mit einem abweichenden Geburtsdatum auf dessen Ausweisdokument übereinstimmt. Dieselbe Person mit einem anderen oder verlängerten Dokument wird nicht markiert. Kann `document_selfie_duplicated_face_action` nur eskalieren. Standardmäßig `REVIEW`. | | `id_verification_name_match_score_threshold` | integer | Schwellenwert für Namensübereinstimmung über mehrere Ausweisverifizierungen hinweg. | | `id_verification_max_retry_attempts` | integer | Wiederholungslimit für die Ausweisverifizierung, `2` bis `5`. | | `id_document_quality_threshold` | integer | Mindestwert für die Erfassungsqualität (`0` bis `100`), den ein Dokumentenbild erreichen muss, um akzeptiert zu werden. Die Qualitätsprüfung wird immer durchgeführt; nur dieser Schwellenwert ist konfigurierbar. Der Standardwert ist `20`, so abgestimmt, dass minderwertige und grenzwertige Erfassungen (Unschärfe, Bewegung, unleserlicher Text) abgelehnt werden, während lesbare Dokumente durchgehen; erhöhen Sie ihn für strengere Erfassungsanforderungen. Die Konsole stellt diesen Wert auf einem Schieberegler dar, bei dem der Standardwert von `20` als ausgewogener Wert von 50% angezeigt wird. | | `cross_org_fraud_document_action` | action | Entscheidung, wenn dieses Dokument von einer anderen Organisation im Netzwerk als betrügerisch markiert wurde. | | `document_audio_recording_enabled` | boolean | Das Mikrofon während der Dokumentenerfassung aufzeichnen, damit ein Prüfer die Sitzung anhören kann. Standardmäßig deaktiviert. | | `document_liveness_portrait_replace_decline_threshold` | integer | Porträtaustausch-Score (`0` bis `100`, höher = eher echt), unterhalb dessen die Sitzung abgelehnt wird. Standardwert ist `35`. Siehe [Schwellenwerte für die Dokumenten-Liveness](https://docs.didit.me/de/core-technology/id-verification/warnings-id-verification.md#schwellenwerte-für-die-dokument-liveness-erkennung-konfigurieren). | | `document_liveness_portrait_replace_review_threshold` | integer | Porträtaustausch-Score, unterhalb dessen die Sitzung in Prüfung geht, sofern sie nicht bereits abgelehnt wurde. Bei `100` wird fast jede Sitzung zurückgehalten. Standardwert ist `70`. Siehe [Schwellenwerte für die Dokumenten-Liveness](https://docs.didit.me/de/core-technology/id-verification/warnings-id-verification.md#schwellenwerte-für-die-dokument-liveness-erkennung-konfigurieren). | | `document_liveness_printed_copy_decline_threshold` | integer | Papierkopie-Score (`0` bis `100`, höher = eher echt), unterhalb dessen die Sitzung abgelehnt wird. Standardwert ist `35`. Siehe [Schwellenwerte für die Dokumenten-Liveness](https://docs.didit.me/de/core-technology/id-verification/warnings-id-verification.md#schwellenwerte-für-die-dokument-liveness-erkennung-konfigurieren). | | `document_liveness_printed_copy_review_threshold` | integer | Papierkopie-Score, unterhalb dessen die Sitzung in Prüfung geht, sofern sie nicht bereits abgelehnt wurde. Bei `100` wird fast jede Sitzung zurückgehalten. Standardwert ist `77`. Siehe [Schwellenwerte für die Dokumenten-Liveness](https://docs.didit.me/de/core-technology/id-verification/warnings-id-verification.md#schwellenwerte-für-die-dokument-liveness-erkennung-konfigurieren). | | `document_liveness_screen_replay_decline_threshold` | integer | Bildschirmaufnahme-Score (`0` bis `100`, höher = eher echt), unterhalb dessen die Sitzung abgelehnt wird. Standardwert ist `30`. Siehe [Schwellenwerte für die Dokumenten-Liveness](https://docs.didit.me/de/core-technology/id-verification/warnings-id-verification.md#schwellenwerte-für-die-dokument-liveness-erkennung-konfigurieren). | | `document_liveness_screen_replay_review_threshold` | integer | Bildschirmaufnahme-Score, unterhalb dessen die Sitzung in Prüfung geht, sofern sie nicht bereits abgelehnt wurde. Bei `100` wird fast jede Sitzung zurückgehalten. Standardwert ist `70`. Siehe [Schwellenwerte für die Dokumenten-Liveness](https://docs.didit.me/de/core-technology/id-verification/warnings-id-verification.md#schwellenwerte-für-die-dokument-liveness-erkennung-konfigurieren). | | `id_verification_injection_attack_action` | action | Entscheidung, wenn das Dokument oder das für einen ID-Lookup aufgenommene Selfie eingeschleust statt von der geräteeigenen Kamera erfasst wurde (`INJECTION_ATTACK_DETECTED`): eine softwarebasierte virtuelle Kamera, ein von der Seite oder durch Browser-Automatisierung erzeugter Kamera-Feed, eine per Hook eingebundene Kamera oder ein an die App angehängtes Instrumentierungstool. Werte: `DECLINE`, `REVIEW`, `NO_ACTION`. Standardwert ist `DECLINE`. Signale, die eine echte Person erzeugen kann, lösen dies niemals aus. Bei Liveness und Gesichtsabgleich folgt das Risiko stattdessen `frame_injection_action`. | | `image_quality_too_low_action` | action | Entscheidung, wenn die allgemeine Dokumentenbildqualität unter dem erforderlichen Standard liegt. | | `is_image_capture_review_screen_enabled` | boolean | Dem Benutzer nach jeder Dokumentenerfassung einen Überprüfungsbildschirm anzeigen, damit das Foto vor dem Absenden erneut aufgenommen werden kann. Standardmäßig deaktiviert. | | `is_ocr_id_verification_data_review_enabled` | boolean | Dem Benutzer ermöglichen, die extrahierten Identitätsdaten zu überprüfen und zu korrigieren, bevor der Schritt abgeschlossen wird. Standardmäßig deaktiviert. Eine Korrektur wird anhand von `ocr_id_verification_data_review_critical_fields` bewertet, und eine Abweichung führt entsprechend zur kritischen oder geringfügigen Aktion. Die Überprüfung wird auch ausgeführt, wenn der Workflow NFC enthält – ein späteres Auslesen des Chips überschreibt dies einfach. | | `ocr_id_verification_data_review_critical_fields` | string\[] | Welche extrahierten Identitätsfelder als kritisch gelten, wenn der Benutzer das OCR-Ergebnis bearbeitet, sodass eine Abweichung die kritische statt der geringfügigen Aktion auslöst. Format: `["first_name" \| "last_name" \| "date_of_birth" \| ...]`. | | `ocr_id_verification_data_review_critical_mismatch_action` | restricted action | Entscheidung, wenn die Bearbeitung des Benutzers bei einem kritischen Feld von der OCR abweicht. | | `ocr_id_verification_data_review_minor_mismatch_action` | action | Entscheidung, wenn die Bearbeitung des Benutzers bei einem unkritischen Feld von der OCR abweicht. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | > [!NOTE] > > Die Dokumenten-Liveness wird mit den sechs obigen `document_liveness_*`-Schwellenwerten konfiguriert, nicht mit > Aktionsfeldern pro Signal. `portrait_replacement_action`, `printed_copy_action` und > `screen_capture_action` sind Einstellungen auf Kontoebene und werden in einer Workflow-Funktionskonfiguration > **nicht** akzeptiert: Die API entfernt unbekannte Konfigurationsschlüssel beim Speichern, sodass das Senden dort > keine Auswirkung hat. Jedes Signal hat einen Ablehnungsschwellenwert und einen Prüfungsschwellenwert auf einer Skala von `0` bis `100`, > wobei ein höherer Score bedeutet, dass das Dokument mit höherer Wahrscheinlichkeit echt ist. Beispiel: ```json theme={null} { "feature": "OCR", "config": { "documents_allowed": { "USA": { "DL": { "enabled": 1, "sides": 2 } } }, "duplicated_user_action": "REVIEW", "image_capture_methods_allowed": ["CAMERA_SCAN", "UPLOAD"] } } ``` ### Methoden pro Land `methods` verwendet den Ländercode nach [ISO 3166-1 alpha-3](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3) als Schlüssel. Jedes Land enthält bis zu drei Methodenobjekte; alles, was Sie weglassen, nimmt seinen Standardwert an. ```json theme={null} { "feature": "OCR", "config": { "methods": { "ZAF": { "document": { "enabled": true }, "id_lookup": { "enabled": true, "max_attempts": 2, "skip_liveness_and_face_match": true, "on_partial_match": "fallback_to_document", "on_no_match": "fallback_to_document", "on_provider_error": "fallback_to_document" }, "wallet": { "enabled": false, "providers": [], "on_failure": "fallback_to_document" } }, "DNK": { "document": { "enabled": true }, "id_lookup": { "enabled": true, "on_no_match": "decline" } } } } } ``` `wallet.on_failure` ist `fallback_to_document`, `decline` oder `retry`. `retry` (nur Wallet, Dokumentenerfassung für das Land deaktiviert) hält einen Benutzer, dessen Anmeldung nicht abgeschlossen wurde, im Wallet-Schritt, um es erneut zu versuchen; die Sitzung wird dafür niemals abgelehnt und bleibt geöffnet, bis er fertig ist oder sie abläuft. Die id\_lookup-Schalter akzeptieren nur `fallback_to_document` oder `decline`. Um Dokumente vom ersten Bildschirm fernzuhalten und sie nur anzubieten, wenn ein Wallet oder Lookup nicht erfolgreich ist, setzen Sie `document.fallback_only`. Das Beispiel verwendet Finnland, wo das Finnish Trust Network an erster Stelle steht und die Dokumentenerfassung das Fallback ist. Finnland muss außerdem seine Dokumenttypen in `documents_allowed` aktiviert haben (zum Beispiel Reisepass und Personalausweis), damit im Fallback Dokumente angeboten werden können. ```json theme={null} { "FIN": { "document": { "enabled": true, "fallback_only": true }, "wallet": { "enabled": true, "providers": ["ftn"], "on_failure": "fallback_to_document" } } } ``` Beide obigen Lookups sind im heutigen Katalog als `available` gekennzeichnet, sodass diese Konfiguration wie angegeben gespeichert wird. Der Wallet-Block wurde in diesem Beispiel absichtlich weggelassen: Eine Wallet lässt sich nur in einem Land speichern, in dem der Katalog sie als `available` kennzeichnet; `wallet.enabled: true` an jedem anderen Ort wird abgelehnt und bricht den gesamten Speichervorgang ab, einschließlich der Lookup-Konfiguration. Wo der Katalog eine Wallet als `available` kennzeichnet, fügen Sie sie in diesem Land hinzu: ```json theme={null} { "DNK": { "document": { "enabled": true }, "wallet": { "enabled": true, "providers": ["mitid"], "on_failure": "fallback_to_document" } } } ``` | Key | Type | Default | Description | | - | - | - | - | | `.document.enabled` | boolean | `true` | Gibt an, ob ein fotografiertes Dokument in diesem Land akzeptiert wird. Welche Dokumente akzeptiert werden, wird weiterhin über `documents_allowed` geregelt. | | `.document.fallback_only` | boolean | `false` | Lässt die Dokumentenerfassung aktiviert, bietet sie jedoch nicht auf dem ersten Bildschirm an. Benutzer starten mit der Wallet oder dem ID-Lookup des Landes. Nur Benutzer, deren Wallet-Anmeldung fehlschlägt, abgebrochen wird oder abläuft oder deren Lookup nicht übereinstimmt (gemäß den Schaltern `on_failure`, `on_partial_match`, `on_no_match` und `on_provider_error`, die auf `fallback_to_document` gesetzt sind), werden zur Dokumentenerfassung weitergeleitet. Bei einer einzelnen Wallet gelangt der Benutzer direkt zu dieser Wallet. Wenn keine einzelne Wallet vorhanden ist, wird eine Wallet oder ein Lookup Seite an Seite mit der Dokumentenerfassung angezeigt. Wird mit HTTP 400 abgelehnt, es sei denn, `document.enabled` ist `true` und mindestens eine Wallet oder ein ID-Lookup im Land greift auf die Dokumentenerfassung zurück. | | `.id_lookup.enabled` | boolean | `false` | Bietet den dokumentenlosen Lookup gegen die behördliche oder eine andere autoritative Quelle dieses Landes an. Wird abgelehnt, wenn der Katalog die Quelle des Landes nicht als `available` ausweist. | | `.id_lookup.max_attempts` | integer | `1` | `1` bis `5`. Wie viele **beantwortete** Lookups der Benutzer erhält, bevor der Fallback-Schalter greift. Eine Nummer, die die clientseitige Formatprüfung nicht besteht, erreicht das Register nie, sodass sie weder zählt noch abgerechnet wird. | | `.id_lookup.skip_liveness_and_face_match` | boolean | `true` | Nach einem Treffer gegen ein Register, das ein Porträtfoto zurückgibt, werden die workflow-eigenen Schritte für Liveness-Erkennung und Gesichtsabgleich übersprungen – der Lookup hat bereits passive Liveness-Erkennung auf dem Selfie ausgeführt und es mit diesem Porträtfoto abgeglichen. Wird beim Speichern für eine Quelle, die kein Porträtfoto zurückgibt und bei der der Schalter wirkungslos wäre, auf `false` normalisiert. | | `.id_lookup.on_partial_match` | `fallback_to_document` \| `decline` | `fallback_to_document` | Was geschieht, wenn das Register geantwortet hat, aber einige Felder nicht übereinstimmten. | | `.id_lookup.on_no_match` | `fallback_to_document` \| `decline` | `fallback_to_document` | Was geschieht, wenn das Register geantwortet hat und keinen übereinstimmenden Datensatz enthält. | | `.id_lookup.on_provider_error` | `fallback_to_document` \| `decline` | `fallback_to_document` | Was geschieht, wenn das Register nicht erreicht werden konnte. Wird nie abgerechnet. | | `.id_lookup.response_fields` | string\[] \| null | `null` | Optionale Teilmenge der Antwortfeldschlüssel der Quelle. Unbekannte Schlüssel werden abgelehnt und die Pflichtfelder der Quelle werden stets wieder hinzugefügt, sodass der gespeicherte Wert immer eine gültige Auswahl darstellt. Die aktuelle Staging-Implementierung wendet diese Auswahl auf die Vergleichsausgabe, das optionale Geschlecht und gespeicherte Register-Porträtfotos an. Erforderliche Identitätsfelder bleiben erhalten. Siehe den Hinweis zu Rollout und Datenaufbewahrung unten. | | `.wallet.enabled` | boolean | `false` | Bietet die Anmeldung per digitaler ID-Wallet in diesem Land an. | | `.wallet.providers` | string\[] | `[]` | Katalog-Wallet-IDs, die dieses Land akzeptiert – eine Positivliste, niemals eine Rangfolge. Die von Ihnen gesendete Reihenfolge wird in die Katalogreihenfolge normalisiert. Mindestens eine Wallet ist erforderlich, wenn `enabled` auf `true` gesetzt ist. Eine Wallet, die im Land nicht angeboten wird oder sich noch in der Vorbereitung befindet, wird abgelehnt. | | `.wallet.on_failure` | `fallback_to_document` \| `decline` \| `retry` | `fallback_to_document` | Was geschieht, wenn die Anmeldung abgebrochen wird, ein Timeout auftritt oder fehlschlägt. `retry` belässt den Benutzer auf dem Wallet-Schritt für einen erneuten Versuch (nur Wallet); dies wird in Kombination mit `document.fallback_only` abgewiesen. | Validierung, die die API beim Speichern anwendet: * Ein unbekannter Ländercode, ein unbekannter Schlüssel innerhalb eines Landes oder ein unbekannter Schlüssel innerhalb einer Methode wird abgelehnt – nichts wird stillschweigend verworfen. * Ein Land, in dem keine Methode aktiviert ist, wird abgelehnt: dort könnte sich niemand verifizieren. * Eine Wallet oder ein Lookup kann nur dann auf die Dokumentenerfassung zurückgreifen, wenn die Dokumentenerfassung für dieses Land aktiviert ist. `fallback_to_document` in einem Land, in dem `document.enabled` auf `false` gesetzt ist, führt zur Laufzeit zu einer Ablehnung, da kein Fallback-Ziel existiert. * `document.fallback_only: true` wird mit HTTP 400 abgelehnt, es sei denn, `document.enabled` ist `true` und mindestens eine Wallet oder ein ID-Lookup in diesem Land greift auf die Dokumentenerfassung zurück. > [!WARNING] > > Die aktuelle Staging-Implementierung wendet `id_lookup.response_fields` auf die Vergleichsausgabe, das optionale Geschlecht und aufbewahrte Register-Porträtfotos an. Erforderliche Identitätsfelder bleiben Teil des Verifizierungsdatensatzes. Dies ist keine Garantie dafür, dass jede Zwischen-Payload des Anbieters von der Verarbeitung ausgeschlossen ist. Das Produktions-Rollout wurde für diese Änderung noch nicht verifiziert; prüfen Sie das Verhalten in Ihrer Zielumgebung, bevor Sie sich bei Aufbewahrungsanforderungen auf die Feldauswahl verlassen. Lesen Sie den Funktionskatalog, bevor Sie `methods` schreiben – über den Tab **Länder** der Konsole oder mit dem MCP-Tool [`didit_workflow_get_id_verification_methods_catalog`](https://docs.didit.me/de/integration/mcp/tools). Verhalten, Abdeckung und Abrechnung finden Sie unter [Methoden der Ausweisverifizierung](https://docs.didit.me/de/core-technology/id-verification/verification-methods.md). ## NFC / ePassport Funktionswert: `NFC`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `allow_nfc_skip` | boolean | Ermöglicht es Benutzern, NFC zu überspringen, wenn ihr Dokument das Auslesen per Chip unterstützt. | | `skip_nfc_action` | action | Aktion, wenn der Benutzer NFC überspringt. | | `unverified_chip_action` | action | Aktion, wenn die Chip-Verifizierung fehlschlägt. | | `trust_anchor_missing_action` | action | Entscheidung, wenn die Datengruppen-Hashes des Chips intakt sind, die Zertifikatskette jedoch nicht verifiziert werden kann, weil der CSCA-Trust-Anchor des Ausstellungslands nicht geladen ist. | | `jpki_request_attributes` | boolean | Japan My Number Card ([JPKI](https://docs.didit.me/de/core-technology/nfc-verification/overview.md#japan-my-number-card-jpki), nur native SDKs): Liest auch das Signaturzertifikat aus, das die Signatur-PIN der Karte erfordert und den Namen, das Geburtsdatum, das Geschlecht sowie die Adresse des Inhabers enthält und mit den Daten der Ausweisverifizierung abgeglichen wird. Standardwert `true`. `false` liest nur das Benutzerauthentifizierungszertifikat (4-stellige PIN) aus, das die Karte und die PIN nachweist, aber keine Inhaberdaten enthält. | | `jpki_certificate_invalid_action` | action | Entscheidung, wenn ein Zertifikat der My Number Card nicht auf die JPKI-Zertifizierungsstelle zurückgeführt werden kann, außerhalb seiner Gültigkeitsdauer liegt oder kein Kartenzertifikat des angeforderten Typs ist (`JPKI_CERTIFICATE_INVALID`). Standardwert `DECLINE`. | | `jpki_signature_invalid_action` | action | Entscheidung, wenn die Signatur der My Number Card über die Einmal-Challenge nicht verifiziert werden kann, sodass der Besitz der Karte und die Kenntnis ihrer PIN nicht nachgewiesen sind (`JPKI_SIGNATURE_INVALID`). Standardwert `DECLINE`. | | `jpki_certificate_revoked_action` | action | Entscheidung, wenn die Sperrprüfung meldet, dass ein Zertifikat der My Number Card widerrufen wurde (`JPKI_CERTIFICATE_REVOKED`). Standardwert `DECLINE`. | | `jpki_revocation_unchecked_action` | action | Entscheidung, wenn die My Number Card verifiziert wurde, aber keine Antwort zur Zertifikatswiderrufsprüfung verfügbar war, sodass nicht ausgeschlossen werden kann, dass das Zertifikat widerrufen wurde (`JPKI_REVOCATION_UNCHECKED`). Standardwert `REVIEW`. | | `jpki_inconsistent_data_action` | action | Entscheidung, wenn Name, Geburtsdatum, Geschlecht oder Adresse im Signaturzertifikat der My Number Card von den Daten der Ausweisverifizierung derselben Karte abweichen (`JPKI_AND_OCR_DATA_NOT_SAME`). Standardwert `REVIEW`. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | ## Liveness Funktionswert: `LIVENESS`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `face_liveness_method` | string | Einer der Werte `ACTIVE_3D`, `FLASHING` oder `PASSIVE`. | | `face_liveness_mode` | string | Überschreibung des Liveness-Modus. | | `face_liveness_flash_mode` | string | Blitzmodus für die Methoden `ACTIVE_3D` und `FLASHING`. `"0"` (nicht strikt, Standard) prüft, ob die auf dem Bildschirm aufblitzenden Farben auf dem Gesicht des Benutzers reflektiert werden; `"1"` (strikt) erfordert zusätzlich, dass die Reflexionen der exakten Farbsequenz entsprechen – besserer Schutz vor Replay- und Video-Injection-Angriffen, jedoch mit mehr falschen Ablehnungen. | | `face_liveness_score_decline_threshold` | integer | Schwellenwert für Ablehnung. | | `face_liveness_score_review_threshold` | integer | Schwellenwert für Prüfung. | | `face_liveness_possible_duplicated_face_action` | action | Aktion, wenn das Gesicht möglicherweise doppelt vorkommt. | | `face_liveness_multiple_faces_action` | action | Aktion, wenn mehrere Gesichter erkannt werden. | | `face_liveness_video_anomaly_action` | action | Aktion, wenn die gespeicherte Aufnahme eine wiederholte Bewegungssequenz enthält. Standardwert `NO_ACTION`; `REVIEW` und `DECLINE` können eine bereits entschiedene Verifizierung asynchron eskalieren. Spärliche oder wiederholte Standbilder allein lösen dies nicht aus. | | `face_liveness_attack_face_match_action` | action | Aktion, wenn das Liveness-Gesicht mit einem Gesicht aus einer früheren Sitzung dieser Anwendung eines anderen Benutzers übereinstimmt, dessen Aufnahme mit hoher Konfidenz als Liveness-Angriff eingestuft wurde (Warnung `FACE_MATCHES_LIVENESS_ATTACK`). Akzeptiert `NO_ACTION` oder `REVIEW`; `DECLINE` wird akzeptiert, aber als `REVIEW` angewendet, da ein echter Benutzer einmal versehentlich abgelehnt werden und danach bestehen kann. Standardwert ist `NO_ACTION`. | | `race_map_similarity_thresholds` | object | Demografieabhängige Ähnlichkeitsschwellenwerte. | | `face_privacy_mode_enabled` | boolean | Aktiviert den Datenschutzmodus für Gesichts-Assets. | | `face_quality_review_threshold` | integer | Prüfungs-Schwellenwert für die Bildqualität des Gesichts. | | `face_quality_decline_threshold` | integer | Ablehnungs-Schwellenwert für die Bildqualität des Gesichts. Muss kleiner oder gleich dem Prüfungs-Schwellenwert sein. | | `face_luminance_min_threshold` | integer | Minimaler Helligkeitsschwellenwert. Muss niedriger sein als `face_luminance_max_threshold`. | | `face_luminance_min_action` | action | Aktion bei zu geringer Helligkeit. | | `face_luminance_max_threshold` | integer | Maximaler Helligkeitsschwellenwert. | | `face_luminance_max_action` | action | Aktion bei zu hoher Helligkeit. | | `face_liveness_max_attempts` | integer | Gesamtzahl der Liveness-Übermittlungen pro Sitzung, `1` bis `3`. Standardwert `3` bedeutet ein anfänglicher Versuch plus zwei Wiederholungsversuche. Der Wert `1` deaktiviert Wiederholungsversuche bei Qualitätsfehlern der Aufnahme nicht: Wenn alle Warnungen beim Versuch umgebungsbedingt sind (`LOW_FACE_LUMINANCE`, `HIGH_FACE_LUMINANCE`, `LOW_FACE_QUALITY`, `HIGH_FACE_OCCLUSION`, `NO_FACE_DETECTED`), erhält der Benutzer immer einen zweiten Versuch mit konkretem Feedback. | | `cross_org_fraud_face_action` | action | **Veraltet und wird nicht mehr angewendet.** Behandelte ein Gesicht so, als trüge es ein Betrugsurteil, was eine stabile biometrische Identität nicht kann. Wird weiterhin akzeptiert, damit bestehende Workflows weiterhin validieren. Verwenden Sie `cross_org_identity_claim_pattern_action`. | | `cross_org_identity_claim_pattern_action` | action | Entscheidung, wenn andere Organisationen im Netzwerk Ereignisse zur Identitätsbehauptung für dieselbe Person erfasst haben, bei denen die angegebene Identität nicht übereinstimmte. Nur Prüfung oder Keine Aktion möglich – eine hier festgelegte Ablehnung wird auf Prüfung herabgestuft. Siehe [Organisationsübergreifende Identitätsansprüche](https://docs.didit.me/de/core-technology/liveness/cross-organization-identity-claims.md). | | `external_capture_device_action` | action | Entscheidung, wenn ein externes Aufnahmegerät erkannt wird. | | `face_audio_recording_enabled` | boolean | Mikrofon während der Selfie-Aufnahme aufzeichnen, damit ein Prüfer die Sitzung anhören kann. Standardmäßig deaktiviert. | | `face_search_enabled` | boolean | Automatische [Gesichtssuche 1:N](https://docs.didit.me/de/core-technology/face-search/overview.md#automatische-gesichtssuche-deaktivieren) für das Selfie ausführen: Abgleich mit zuvor verifizierten Benutzern, der Gesichts-Sperrliste und -Positivliste, und Speicherung des biometrischen Templates für spätere Abgleiche. Standardmäßig aktiviert. `false` überspringt die Suche, speichert kein Gesichtstemplate für diesen Schritt und lässt Aktionen für doppelte Gesichter ohne Grundlage. | | `face_liveness_uncertain_retry_enabled` | boolean | Nur für aktive Liveness im nativen SDK. Wenn diese Einstellung aktiviert ist, wird für eine Aufnahme, deren Liveness-Score strikt zwischen `face_liveness_score_decline_threshold` und `face_liveness_score_review_threshold` liegt, niemals eine Entscheidung getroffen, unabhängig vom Urteil der Engine: Der Person wird mitgeteilt, dass das Ergebnis unklar war, und sie wird jedes Mal zu einer erneuten Aufnahme aufgefordert, außerhalb des Budgets von `face_liveness_max_attempts` (das weiterhin für Aufnahmen gilt, die die Engine nicht bewerten konnte). Standardmäßig deaktiviert; der Web-Ablauf ignoriert diese Einstellung. | | `face_liveness_duplicated_face_name_mismatch_action` | action | Entscheidung, wenn ein doppeltes Gesicht unter einem anderen Namen gefunden wird. | | `face_liveness_duplicated_face_document_mismatch_action` | action | Entscheidung, wenn ein doppeltes Gesicht gefunden wird und das Ausweisdokument des abgeglichenen Benutzers ein anderes Geburtsdatum aufweist. Dieselbe Person mit einem anderen oder erneuerten Dokument wird nicht markiert. Standardwert ist `REVIEW`. | | `frame_injection_action` | action | Entscheidung, wenn injizierte Videoframes erkannt werden. | | `screen_capture_action` | action | Entscheidung, wenn das Selfie ein Foto eines Bildschirms ist. | | `virtual_camera_action` | action | Entscheidung, wenn der Feed einer virtuellen Kamera erkannt wird. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | ## Gesichtsabgleich Funktionswert: `FACE_MATCH`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `face_match_score_decline_threshold` | integer | Schwellenwert für Ablehnung. | | `face_match_score_review_threshold` | integer | Schwellenwert für Prüfung. | | `face_match_max_attempts` | integer | Gesamtzahl der Übermittlungen für den Gesichtsabgleich pro Sitzung, `1` bis `3`. Der Standardwert `3` bedeutet einen anfänglichen Versuch plus zwei Wiederholungsversuche. | | `face_match_not_computed_action` | eingeschränkte Aktion | Entscheidung, wenn kein Übereinstimmungswert ermittelt werden konnte (fehlendes Porträt oder Selfie). | | `face_match_eyes_covered_action` | Aktion | Entscheidung, wenn der Augenbereich im Selfie verdeckt ist. Standardmäßig `NO_ACTION`, wodurch der Nachweis erfasst wird, ohne das Ergebnis des Gesichtsabgleichs zu ändern. Dieses Signal wird noch kalibriert und verbleibt daher im Shadow-Modus, bis der Bereich als kalibriert gemeldet wird: Wenn Sie jetzt `REVIEW` oder `DECLINE` festlegen, wird dies ab diesem Zeitpunkt wirksam. | | `face_match_mouth_covered_action` | Aktion | Entscheidung, wenn der Mundbereich im Selfie verdeckt ist. Derselbe Standardwert `NO_ACTION` und derselbe Kalibrierungshinweis wie bei `face_match_eyes_covered_action`. | | `face_match_face_covered_action` | Aktion | Entscheidung, wenn das Gesicht im Selfie insgesamt verdeckt ist. Derselbe Standardwert `NO_ACTION` und derselbe Kalibrierungshinweis wie bei `face_match_eyes_covered_action`. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | ## Altersschätzung Funktionswert: `AGE_ESTIMATION`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `enable_id_verification_fallback` | boolean | Führt die Ausweisverifizierung durch, wenn die Altersschätzung im Grenzbereich liegt. | | `minimum_age_threshold` | integer | Mindestalter, `1` bis `100`. | | `borderline_minimum_age_threshold` | integer | Untere Grenze für den Grenzbereich, `1` bis `100`. | | `borderline_maximum_age_threshold` | integer | Obere Grenze für den Grenzbereich, `1` bis `100`. | | `face_liveness_method` | string | Einer der Werte `ACTIVE_3D`, `FLASHING` oder `PASSIVE`. | | `face_liveness_flash_mode` | string | Blitzmodus für die Methoden `ACTIVE_3D` und `FLASHING`. `"0"` (nicht strikt, Standard) prüft, ob die auf dem Bildschirm aufblitzenden Farben auf dem Gesicht des Benutzers reflektiert werden; `"1"` (strikt) erfordert zusätzlich, dass die Reflexionen exakt mit der aufgeblitzten Farbsequenz übereinstimmen. | | `face_liveness_score_decline_threshold` | number | Ablehnungsschwellenwert für die von der Altersschätzung genutzte Liveness-Prüfung. | | `face_liveness_score_review_threshold` | number | Prüfungsschwellenwert für die von der Altersschätzung genutzte Liveness-Prüfung. | | `face_liveness_possible_duplicated_face_action` | action | Aktion, wenn das Gesicht möglicherweise dupliziert ist. | | `face_liveness_multiple_faces_action` | action | Aktion, wenn mehrere Gesichter erkannt werden. | | `face_liveness_video_anomaly_action` | action | Aktion, wenn die gespeicherte Aufnahme eine wiederholte Bewegungssequenz enthält. Standard ist `NO_ACTION`; `REVIEW` und `DECLINE` können eine bereits entschiedene Verifizierung asynchron eskalieren. Einzelne oder wiederholte Standbilder allein lösen dies nicht aus. | | `face_liveness_attack_face_match_action` | action | Aktion, wenn das Liveness-Gesicht mit einem Gesicht aus einer früheren Sitzung dieser Anwendung eines anderen Benutzers übereinstimmt, dessen Erfassung mit hoher Konfidenz als Liveness-Angriff eingestuft wurde (Warnung `FACE_MATCHES_LIVENESS_ATTACK`). Akzeptiert `NO_ACTION` oder `REVIEW`; `DECLINE` wird akzeptiert, aber als `REVIEW` angewendet, da ein echter Benutzer einmal versehentlich abgelehnt werden und die Verifizierung anschließend bestehen kann. Standard ist `NO_ACTION`. | | `face_privacy_mode_enabled` | boolean | Aktiviert den Datenschutzmodus für Gesichts-Assets. | | `face_quality_review_threshold` | integer | Prüfungsschwellenwert für die Gesichtsqualität. | | `face_quality_decline_threshold` | integer | Ablehnungsschwellenwert für die Gesichtsqualität. | | `face_luminance_min_threshold` | integer | Mindestschwellenwert für die Helligkeit. | | `face_luminance_min_action` | action | Aktion, wenn die Helligkeit zu gering ist. | | `face_luminance_max_threshold` | integer | Maximaler Schwellenwert für die Helligkeit. | | `face_luminance_max_action` | action | Aktion, wenn die Helligkeit zu hoch ist. | | `face_liveness_max_attempts` | integer | Gesamtzahl der Liveness-Übermittlungen pro Sitzung, `1` bis `3`. Der Standardwert `3` bedeutet einen ersten Versuch plus zwei Wiederholungsversuche. Die Einstellung `1` deaktiviert Wiederholungsversuche bei Fehlern aufgrund der Erfassungsqualität nicht: Wenn jede Warnung bei dem Versuch umgebungsbedingt ist (`LOW_FACE_LUMINANCE`, `HIGH_FACE_LUMINANCE`, `LOW_FACE_QUALITY`, `HIGH_FACE_OCCLUSION`, `NO_FACE_DETECTED`), erhält der Benutzer immer einen zweiten Versuch mit umsetzbarem Feedback. | | `external_capture_device_action` | action | Entscheidung, wenn ein externes Erfassungsgerät erkannt wird. | | `face_audio_recording_enabled` | boolean | Nimmt das Mikrofon während der Selfie-Erfassung auf, sodass ein Prüfer die Sitzung hören kann. Standardmäßig deaktiviert. | | `face_search_enabled` | boolean | Führt die automatische [Gesichtssuche 1:N](https://docs.didit.me/de/core-technology/face-search/overview.md#automatische-gesichtssuche-deaktivieren) auf dem Selfie aus: gleicht es mit zuvor verifizierten Benutzern, der Gesichts-Sperrliste sowie der Gesichts-Positivliste ab und speichert sein biometrisches Template für spätere Abgleiche. Standardmäßig aktiviert. `false` überspringt die Suche, speichert kein biometrisches Template für diesen Schritt und lässt die Aktionen für duplizierte Gesichter ohne Grundlage. | | `face_liveness_uncertain_retry_enabled` | boolean | Nur für aktive Liveness im nativen SDK. Wenn aktiviert, wird eine Erfassung, deren Liveness-Wert strikt zwischen `face_liveness_score_decline_threshold` und `face_liveness_score_review_threshold` liegt, niemals entschieden, unabhängig vom Urteil der Engine: Der Person wird mitgeteilt, dass das Ergebnis unklar war, und sie wird jedes Mal gebeten, die Erfassung zu wiederholen, außerhalb des Budgets von `face_liveness_max_attempts` (das weiterhin für Erfassungen gilt, die die Engine nicht bewerten konnte). Standardmäßig deaktiviert; der Web-Flow ignoriert dies. | | `face_liveness_duplicated_face_name_mismatch_action` | action | Entscheidung, wenn ein dupliziertes Gesicht unter einem anderen Namen gefunden wird. | | `face_liveness_duplicated_face_document_mismatch_action` | action | Entscheidung, wenn ein dupliziertes Gesicht gefunden wird und das Ausweisdokument des übereinstimmenden Benutzers ein abweichendes Geburtsdatum aufweist. Dieselbe Person mit einem anderen oder erneuerten Dokument wird nicht markiert. Standard ist `REVIEW`. | | `frame_injection_action` | action | Entscheidung, wenn injizierte Videoframes erkannt werden. | | `screen_capture_action` | action | Entscheidung, wenn das Selfie ein Foto eines Bildschirms ist. | | `virtual_camera_action` | action | Entscheidung, wenn der Feed einer virtuellen Kamera erkannt wird. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | ## Telefonverifizierung Funktionswert: `PHONE_VERIFICATION`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `code_size` | integer | OTP-Länge, `4` bis `8`. | | `phone_max_retries` | integer | Maximale Anzahl an Wiederholungsversuchen beim Senden, `1` bis `5`. | | `phone_max_check_attempts` | integer | Maximale Anzahl an OTP-Prüfversuchen, `1` bis `5`. | | `phone_verification_countries` | object | ISO2-Ländercode zur Kanalkonfiguration. Beispiel: `{ "US": { "sms": { "enabled": true } } }`. | | `disposable_number_action` | action | Aktion für Wegwerfnummern. | | `voip_number_action` | action | Aktion für VoIP-Nummern. | | `duplicated_phone_number_action` | action | Aktion für doppelte Telefonnummern. | | `high_risk_phone_action` | action | Aktion, wenn der Zustellanbieter den OTP-Versand blockiert. Nur `DECLINE` oder `REVIEW`; Standardwert `DECLINE`. Wird nur angewendet, wenn jede Blockierung im Schritt genau die `risk_factors` `["device_attribute"]` aufweist; jeder andere Risikofaktor, jede Mischung, die diesen enthält, oder das Fehlen von Risikofaktoren führt unabhängig von dieser Einstellung zu einer Ablehnung. | | `phone_shared_device_mode` | boolean | Ermöglicht den Telefonverifizierungsmodus für geteilte Geräte. | | `phone_enrichment_enabled` | boolean | Aktiviert die Anreicherung mit Telefoninformationen (Leitungstyp-Risiko, Vertrauensindex, Netzbetreiber, Portierungs-/SIM-Swap-Historie, Betrugsrisiko-Score). **Wird mit \$0.05 pro Verifizierung berechnet**, zusätzlich zum Preis der Telefonverifizierung. | | `phone_intelligence_score_action` | action | Aktion, wenn der Betrugsrisiko-Score der Telefonnummer bei oder über `phone_intelligence_score_threshold` liegt. | | `phone_intelligence_score_threshold` | integer | Betrugsrisiko-Score (`0`–`100`, höher bedeutet riskanter), der `phone_intelligence_score_action` auslöst. Standardwert `80`. | | `phone_type_risk_action` | action | Aktion, wenn die Nummer als Telefontyp mit hohem Risiko eingestuft wird. | | `recent_port_action` | action | Aktion, wenn die Nummer kürzlich portiert wurde (SIM-Swap-/Portierungssignal). | | `low_phone_trust_action` | action | Aktion, wenn der Vertrauensindex der Telefonnummer bei oder unter `phone_trust_index_threshold` liegt. | | `phone_trust_index_threshold` | integer | Vertrauensindex (`0`–`100`, niedriger bedeutet riskanter), bei oder unter dem `low_phone_trust_action` angewendet wird. Standardwert `30`. | | `phone_social_enabled` | boolean | Aktiviert die Prüfung des digitalen Fußabdrucks (Social Footprint): auf welchen Messaging-, Social-Media-, E-Commerce- und professionellen Plattformen die verifizierte Nummer registriert ist. **Wird mit \$0.05 pro Verifizierung berechnet**, zusätzlich zum Preis der Telefonverifizierung und unabhängig von `phone_enrichment_enabled`. | | `phone_no_social_presence_action` | action | Aktion, wenn die Social-Footprint-Prüfung ergibt, dass die Nummer auf keiner der abgedeckten Plattformen registriert ist – ein häufiges Signal für synthetische Identitäten. Standardwert `NO_ACTION`. | | `cross_org_fraud_phone_action` | action | Urteil, wenn diese Nummer von einer anderen Organisation im Netzwerk als betrügerisch markiert wurde. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | Die Telefonverifizierung ist deaktiviert, bis die Organisation ihre erste Aufladung abgeschlossen hat. > [!NOTE] > > Die Anreicherung mit Telefoninformationen ist ein optionales Add-on. Wenn `phone_enrichment_enabled` auf `true` gesetzt ist, wird jede abgeschlossene Telefonverifizierung mit Telefoninformationen angereichert und **mit \$0.05 pro Anfrage abgerechnet**, zusätzlich zu den regulären Kosten der Telefonverifizierung. Die Score-basierten Aktionen greifen erst, sobald der Anreicherungs-Score verfügbar ist; die Aktionen für Vertrauensindex, Telefontyp und Portierung werden angewendet, sobald die Anreicherung ausgeführt wird. > > Die Prüfung des Social Footprints ist ein zweites, separates Add-on. Wenn `phone_social_enabled` auf `true` gesetzt ist, meldet jede abgeschlossene Telefonverifizierung außerdem, auf welchen Online-Plattformen die Nummer registriert ist – Messaging, soziale Medien, E-Commerce und professionelle Dienste – und wird **mit \$0.05 pro Anfrage abgerechnet**. Es kann mit oder ohne `phone_enrichment_enabled` aktiviert werden: Beide Add-ons werden unabhängig voneinander bepreist und abgerechnet. Eine Abfrage, die die Nummer auf keiner der abgedeckten Plattformen findet, ist ein gültiges, abrechenbares Ergebnis und löst `phone_no_social_presence_action` aus. Verwenden Sie `phone.social_profiles_registered` (die Anzahl der Plattformen, auf denen die Nummer registriert ist), um in einem Workflow-Graphen basierend auf dem Ergebnis eine Verzweigung vorzunehmen. ## E-Mail-Verifizierung Feature-Wert: `EMAIL_VERIFICATION`. | Config-Feld | Typ | Beschreibung | | - | - | - | | `email_code_size` | integer | OTP-Länge, `4` bis `8`. | | `email_max_retries` | integer | Maximale Anzahl an Wiederholungsversuchen beim Senden, `1` bis `5`. | | `email_max_check_attempts` | integer | Maximale Anzahl an OTP-Prüfversuchen, `1` bis `5`. | | `email_alphanumeric_code` | boolean | Verwendet alphanumerische E-Mail-Codes. | | `breached_email_action` | action | Aktion für kompromittierte E-Mails. | | `disposable_email_action` | action | Aktion für Wegwerf-E-Mails. | | `duplicated_email_action` | action | Aktion für duplizierte E-Mails. | | `only_corporate_emails_allowed` | boolean | Lehnt nicht geschäftliche E-Mail-Adressen ab. | | `email_enrichment_enabled` | boolean | Aktiviert die E-Mail-Intelligence-Anreicherung (Zustellbarkeit, Domain-Reputation, Betroffenheit von Datenlecks, Betrugs-Risiko-Score). **Wird mit \$0.05 pro Verifizierung berechnet**, zusätzlich zum Preis der E-Mail-Verifizierung. | | `email_intelligence_score_action` | action | Aktion, wenn der Betrugs-Risiko-Score der E-Mail bei oder über `email_intelligence_score_threshold` liegt. | | `email_intelligence_score_threshold` | integer | Betrugs-Risiko-Score (`0`–`100`, höher bedeutet riskanter), der `email_intelligence_score_action` auslöst. Standardwert `80`. | | `recent_email_breach_action` | action | Aktion, wenn die E-Mail in einem kürzlich aufgetretenen bekannten Datenleck vorkommt. | | `frequent_email_breach_action` | action | Aktion, wenn die E-Mail in vielen bekannten Datenlecks vorkommt. | | `email_social_enabled` | boolean | Aktiviert die Social-Footprint-Prüfung: auf welchen E-Mail-, Social-Media-, beruflichen, E-Commerce- und Entertainment-Plattformen die verifizierte Adresse registriert ist. **Wird mit \$0.05 pro Verifizierung berechnet**, zusätzlich zum Preis der E-Mail-Verifizierung und unabhängig von `email_enrichment_enabled`. | | `email_no_social_presence_action` | action | Aktion, wenn die Social-Footprint-Prüfung feststellt, dass die Adresse auf keiner der abgedeckten Plattformen registriert ist – ein häufiges Signal für synthetische Identitäten. Standardwert `NO_ACTION`. | | `cross_org_fraud_email_action` | action | Urteil, wenn diese Adresse von einer anderen Organisation im Netzwerk als betrügerisch markiert wurde. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | > [!NOTE] > > Die E-Mail-Intelligence-Anreicherung ist ein optionales Add-on. Wenn `email_enrichment_enabled` auf `true` gesetzt ist, wird jede abgeschlossene E-Mail-Verifizierung mit E-Mail-Intelligence angereichert und **mit \$0.05 pro Anfrage abgerechnet**, zusätzlich zu den regulären Kosten der E-Mail-Verifizierung. Die Score-basierte Aktion tritt in Kraft, sobald der Anreicherungs-Score verfügbar ist; die Datenleck-Aktionen greifen, sobald die Anreicherung ausgeführt wird. > > Die Social-Footprint-Prüfung ist ein zweites, separates Add-on. Wenn `email_social_enabled` auf `true` gesetzt ist, gibt jede abgeschlossene E-Mail-Verifizierung zusätzlich an, auf welchen Online-Plattformen die Adresse registriert ist – E-Mail-Anbieter, soziale Medien, berufliche Plattformen, E-Commerce- und Entertainment-Dienste – und **wird mit \$0.05 pro Anfrage abgerechnet**. Es kann mit oder ohne `email_enrichment_enabled` aktiviert werden: Die beiden Add-ons werden unabhängig voneinander bepreist und abgerechnet. Eine Abfrage, die die Adresse auf keiner der abgedeckten Plattformen findet, ist eine gültige, kostenpflichtige Antwort und löst `email_no_social_presence_action` aus. Verwenden Sie `email.social_profiles_registered` (die Anzahl der Plattformen, auf denen die Adresse registriert ist), um im Workflow-Graphen basierend auf dem Ergebnis zu verzweigen. ## Datenbankvalidierung Funktionswert: `DATABASE_VALIDATION`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `database_validation_countries` | object | ISO3-Ländercode zu `{ "services": ["service_id"] }`. Verwenden Sie Service-IDs aus dem Datenbankvalidierungskatalog. | | `database_validation_partial_match_action` | action | Aktion, wenn die Datenbankvalidierung eine teilweise Übereinstimmung liefert. | | `database_validation_no_match_action` | action | Aktion, wenn die Datenbankvalidierung keine Übereinstimmung liefert. | | `database_validation_not_applicable_action` | action | Aktion, wenn die Datenbankvalidierung nicht ausgeführt werden kann, weil das Dokument nicht das Identifikationsmerkmal enthält, das die konfigurierten Dienste erfordern (z. B. ein Reisepass ohne nationale Identifikationsnummer). Standardwert ist `NO_ACTION`. | | `database_validation_field_sources` | object | Gibt an, woher eine Datenbankeingabe gelesen werden soll, die kein früherer Schritt im Graphen füllen kann. `source` benennt den Erzeuger und `key` den Wert darin: ein Document AI-Feldschlüssel für `document_ai`, eine Fragebogen-Knoten-ID für `questionnaire` und `expected_details.` oder `metadata.` für `expected_data`. Exakte Schlüsselübereinstimmungen mit einem vorgelagerten Schritt werden automatisch aufgelöst und bewusst nicht persistent gespeichert, sodass das Umbenennen eines Document AI-Felds niemals ein veraltetes Mapping in der Konfiguration festschreibt. Ein fehlerhafter Eintrag wird mit einem `400`-Fehler abgewiesen, der das entsprechende Eingabefeld nennt. Format: `{"": {"source": "document_ai"\|"questionnaire"\|"expected_data", "key": "\|\|expected_details.\|metadata."}}`. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | Beispiel: ```json theme={null} { "feature": "DATABASE_VALIDATION", "config": { "database_validation_countries": { "BRA": { "services": ["SERVICE_ID_FROM_CATALOG"] } }, "database_validation_field_sources": { "tax_id": { "source": "expected_data", "key": "expected_details.document_number" } }, "database_validation_no_match_action": "REVIEW", "database_validation_partial_match_action": "REVIEW" } } ``` > [!WARNING] > > `database_validation_countries` sorgt dafür, dass dieser Schritt überhaupt ausgeführt wird. Eine > `DATABASE_VALIDATION`-Funktion, die ohne dieses Feld gespeichert wird, wird zwar akzeptiert, führt > dann jedoch keinerlei Prüfung durch. Übergeben Sie daher immer mindestens ein Land mit mindestens > einer Service-ID. Eine Service-ID für einen Dienst, den dieser Schritt nicht ausführen kann, wird mit einem `400`-Fehler abgewiesen, der die ID benennt und die Ursache erklärt; es wird nichts gespeichert. Dies betrifft eine ID, die nicht im Katalog enthalten ist, eine ID, die zu einem anderen Land gehört, einen Dienst, der noch nicht verfügbar ist, und einen Dienst, der nur über das eigenständige [`POST /v3/database-validation/`](https://docs.didit.me/de/core-technology/database-validation/overview) angeboten wird. Ein Dienst, dessen Eingaben von keinem früheren Schritt bereitgestellt werden, wird auf dieselbe Weise abgewiesen, wobei die fehlenden Eingaben aufgelistet werden. Ein Dienst, der im gespeicherten Workflow bereits vorhanden ist, aber nicht mehr ausgeführt werden kann, wird entfernt, sobald Sie ihn erneut speichern. Dieser Workflow für Argentinien liest beispielsweise die DNI-Nummer und das Geschlecht aus der Ausweisverifizierung und gleicht sie ohne Selfie mit RENAPER ab: ```json theme={null} { "workflow_label": "Argentina DNI check", "features": [ {"feature": "OCR"}, { "feature": "DATABASE_VALIDATION", "config": {"database_validation_countries": {"ARG": {"services": ["arg_renaper_data"]}}} } ] } ``` Verwenden Sie stattdessen `arg_renaper` nach einem `LIVENESS`-Schritt, um auch das Selfie mit dem bei RENAPER hinterlegten Foto abzugleichen. Informationen zum Übereinstimmungswert und Schwellenwert für den Gesichtsabgleich finden Sie unter [RENAPER](https://docs.didit.me/de/api-reference/database-validation/argentina/renaper.md). ## Bank-Verifizierung Feature-Wert: `BANK_VERIFICATION`. Der Benutzer verifiziert ein Bankkonto, und der von der Bank gemeldete Kontoinhaber wird mit der Identität verglichen, die ein vorheriger Schritt im Workflow festgestellt hat. Der Benutzer führt dies über eine von zwei Methoden durch: Bank-Login (`open_banking`), bei dem er sich bei seiner Bank anmeldet, oder die Kontoprüfung (`account_lookup`), bei der er die Kontodaten eingibt und die Bank den darauf eingetragenen Namen bestätigt. `bank_method_order` und die `methods` jedes Landes bestimmen, welche Methoden ein Land anbietet und welche an erster Stelle steht; siehe [Bank-Verifizierungsmethoden](https://docs.didit.me/de/core-technology/bank-verification/verification-methods.md). Der Schritt erzeugt Nachweise – einen Inhabernamen-Score, den Vergleich, der ihn hervorgebracht hat, Ursachencodes – und die `bank_*_action`-Schlüssel wandeln diese Nachweise in einen Status um. Zwei Faktoren entscheiden darüber, ob der Knoten überhaupt etwas ausführt. `bank_countries` ist eine Zulassungsliste (Whitelist), daher bietet eine leere Map keine Bank an und führt keine Prüfung durch. Zudem benötigt der Inhaber eine Referenz, mit der er verglichen werden kann: Platzieren Sie einen `OCR`-, `DATABASE_VALIDATION`- oder `QUESTIONNAIRE`-Schritt davor, übergeben Sie `expected_details` bei der Sitzungserstellung oder mappen Sie die Felder selbst mit `bank_field_sources`. Ohne eines dieser Elemente kann die Eigentümerstruktur nur `unknown` sein, worüber `bank_reference_identity_missing_action` entscheidet. > [!NOTE] > > Die Bank-Verifizierung befindet sich noch im Rollout, daher wird ein `BANK_VERIFICATION`-Knoten nur für Konten akzeptiert, für die sie aktiviert wurde. Überall sonst wird das Speichern abgelehnt und entsprechend ausgewiesen. Welche Route den Schritt ausführt, wird hier ebenfalls nicht konfiguriert: Es handelt sich um das Paar aus `provider_key` und `fallback_to_native`, das der [Marketplace](https://docs.didit.me/de/console/marketplace.md) der Konsole für Sie festlegt. ### Konto verknüpfen | Config-Feld | Typ | Beschreibung | | - | - | - | | `bank_countries` | object | In welchen Ländern ein Benutzer ein Bankkonto verknüpfen darf. Eine Zulassungsliste: Eine leere Map bedeutet, dass der Knoten nichts anbietet und nichts ausführt. `institutions` schränkt die Auswahl auf bestimmte Instituts-IDs ein, `"all"` bietet jede identitätsfähige Bank im Land an. Ein Land, das von keiner Route des Knotens bedient wird, bleibt erhalten: Es bietet nur seine Fallbacks und "Ohne Bank fortfahren" an, siehe [Wenn die Person ihre Bank nicht verifizieren kann](https://docs.didit.me/de/core-technology/bank-verification/fallbacks.md). Ein Code, der kein Land benennt, wird beim Speichern abgelehnt. `methods` legt fest, welche der beiden Methoden – Bank-Login (`open_banking`) und Kontoprüfung (`account_lookup`) – das Land in welcher Reihenfolge anbietet; diese Einstellung hat Vorrang vor `bank_method_order`: Der Benutzer beginnt mit der ersten und erhält die zweite als Ausweichoption. Ein aktiviertes Land, dessen `methods` eine Methode benennt, die keine Route des Knotens dort bedient, wird beim Speichern abgelehnt; dasselbe gilt für ein von einer Route bedientes Land, das durch `methods` ohne Methode bleibt. Struktur: `{"": {"enabled": true\|false, "institutions": ["", ...]\|"all", "methods"?: ["open_banking"\|"account_lookup", ...]}}`. | | `bank_method_order` | string\[] | Welche der beiden Methoden der Schritt anbietet und in welcher Reihenfolge, in jedem Land, das keine eigenen `methods` festlegt: `open_banking` (Bank-Login: Der Benutzer meldet sich bei seiner Bank an, und nur diese Methode liest Guthaben, Transaktionen und Einkommen aus) und `account_lookup` (Kontoprüfung: kein Login, nur Eigentümerstruktur). In jedem Land beginnt der Benutzer mit der ersten Methode, die eine Route dort bedient, und erhält die andere als Ausweichoption; eine Methode, die keine Route in einem Land bedient, wird dort weggelassen. Mindestens eine Methode. Ein Speichervorgang, der keine sendet, erhält `["open_banking", "account_lookup"]`, es sei denn, er sendet `bank_open_banking_enabled` oder `bank_account_lookup_enabled`, wodurch dies festgelegt wird. | | `bank_scopes` | object | In welche Datenfreigaben der Benutzer einwilligen soll. `ownership` ist das, was das Produkt verifiziert, und kann nicht deaktiviert werden. `identifiers` demaskiert die IBAN oder Kontonummer; `balances`, `transactions` und `income` lesen reale Finanzdaten aus, werden jeweils separat abgerechnet und beim Speichern abgelehnt, sofern Ihre Anwendung nicht über die entsprechende Berechtigung für Finanzdaten verfügt. Nur der Bank-Login liest Daten aus: Ein Land, das die Kontoprüfung anbietet, wird nicht abgelehnt, und ein Benutzer, der sich per Kontoprüfung verifiziert, besteht auch ohne Erhebung dieser Daten, was das Ergebnis in `financial_data.not_collected` aufführt. Ein deaktivierter Scope wird niemals angefordert, sodass die Bank ihn auf ihrem Einwilligungsbildschirm nicht anzeigt. Standardmäßig nur `ownership`. Struktur: `{"ownership": true, "identifiers": true\|false, "balances": true\|false, "transactions": true\|false, "income": true\|false}`. | | `bank_eligible_account_types` | string\[] | Welche Kontotypen der Benutzer auswählen darf: `checking`, `current`, `savings`, `business` oder `other`. Kreditkarten, Kredite und Anlagekonten sind niemals zulässig – sie weisen die Eigentümerstruktur eines Zahlungskontos nicht nach. Standardmäßig Giro- und Kontokorrentkonten (current und checking). | | `bank_account_selection` | string | `user` lässt den Benutzer auswählen, welches der verknüpften Konten verifiziert wird; `auto` wählt das erste berechtigte Konto. | | `bank_require_oauth_only` | boolean | Nur Institute anbieten, die über OAuth oder App-to-App erreichbar sind, niemals einen herkömmlichen Bildschirm zur Erfassung von Anmeldedaten. In Märkten, in denen Open Banking OAuth bereits zum einzigen Weg macht, ändert dies nichts. | | `bank_max_attempts` | integer | Wie viele Bank-Login-Versuche der Benutzer erhält, `1` bis `5`; eine Mikroeinzahlung oder ein Kontoauszug-Upload verbraucht ebenfalls einen Versuch. Die Kontoprüfung verfügt über ein eigenes `bank_account_check_max_attempts`. Sobald jede dem Benutzer angebotene Verifizierungsmethode, einschließlich des Kontoauszug-Uploads, ihre Versuche ohne erfolgreiche Verknüpfung aufgebraucht hat, entscheidet `bank_attempts_exhausted_action`. | | `bank_connection_timeout_minutes` | integer | Wie lange eine gestartete Verbindung offen bleibt, bevor der Versuch abgebrochen wird, `5` bis `60` Minuten. | | `bank_allow_skip` | boolean | Ersetzt durch `bank_continue_without_bank`: Der Benutzer kann jetzt immer ohne Bank fortfahren. Wird für ein Release aus einem Speichervorgang ausgelesen, der kein `bank_continue_without_bank` sendet: `true` setzt `from_start`, alles andere `when_needed`. Jeder Speichervorgang schreibt dies zurück: `true` für `from_start`, `false` für `when_needed`. | ### Wenn der Benutzer sich nicht verifizieren kann Der Benutzer kann jederzeit ohne Bank fortfahren, und der Schritt lässt ihn niemals festhängen. Siehe [Wenn die Person ihre Bank nicht verifizieren kann](https://docs.didit.me/de/core-technology/bank-verification/fallbacks.md). | Config-Feld | Typ | Beschreibung | | - | - | - | | `bank_continue_without_bank` | string | Wann der Schritt **Ohne Ihre Bank fortfahren** anzeigt. `when_needed`, der Standardwert, zeigt ihn an, sobald keine Methode für das Land oder die Bank des Benutzers funktioniert, wenn seine Bank nicht erreichbar ist und ihn keine andere Methode verifizieren konnte, beispielsweise weil die Kontoprüfung die Bank ebenfalls nicht erreichen konnte, oder wenn er angibt, kein Online-Banking zu haben. `from_start` zeigt ihn auch auf dem ersten Bildschirm an. Er kann nicht deaktiviert werden. Ein Speichervorgang, der weder diesen Schlüssel noch `bank_allow_skip` sendet, erhält `when_needed`. | | `bank_statement_standalone_enabled` | boolean | Zusammen mit `bank_statement_enabled` wird der Upload des Kontoauszugs auch dann angeboten, wenn kein Bankversuch stattgefunden hat, in jedem Land, einschließlich solcher, die von keiner Bank-Anmelde- oder Kontoprüfungsroute unterstützt werden. Er wird dann separat als `bank_statement_upload` abgerechnet, zum Preis von USD 0.20 pro ausgewertetem Auszug vor Anwendung Ihres Vertragspreises oder Sonderpreises: siehe [Preise](https://docs.didit.me/de/core-technology/bank-verification/fallbacks.md#preise). Sandbox-Sitzungen können ihn ohne Abrechnung testen. Standardmäßig aktiviert. | Was das Fortfahren für die Sitzung bedeutet, wird durch `bank_unsupported_action`, `bank_attempts_exhausted_action` oder `bank_skipped_action` festgelegt, je nachdem, warum der Benutzer fortgefahren ist, es sei denn, ein zuvor ausgewerteter Versuch hat den Schritt bereits entschieden: siehe [Entscheidungsaktionen](#entscheidungsaktionen). ### Inhaber abgleichen | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `bank_reference_identity` | string | Welcher frühere Schritt die Identität bereitstellt, mit der der Inhaber verglichen wird: `kyc` (Ausweisverifizierung), `database_validation`, `expected_details` (was Sie bei der Sitzungserstellung gesendet haben), `questionnaire` oder `auto`, um dasjenige zu verwenden, das der Workflow erzeugt hat. Der Schritt, der sie tatsächlich bereitgestellt hat, wird im Ergebnis als `reference_identity_source` zurückgegeben. | | `bank_field_sources` | object | Woher ein Referenzidentitätsfeld gelesen werden soll, wenn kein früherer Schritt im Graphen es ausfüllen kann. Der SCHLÜSSEL der Map ist einer von `full_name`, `first_name`, `last_name`, `address`; `source` benennt den Erzeuger und `key` den Wert darin – ein Document AI-Feldschlüssel für `document_ai`, eine Fragebogen-Knoten-ID für `questionnaire` und `expected_details.` oder `metadata.` für `expected_data`. Ein Wert unter `expected_details.` darf nur ein Feld benennen, das die Payload zur Sitzungserstellung tatsächlich enthält: `address`, `country`, `date_of_birth`, `first_name`, `gender`, `id_country`, `identification_number`, `ip_address`, `last_name`, `nationality` oder `poa_country`. Ein fehlerhafter Eintrag wird beim Speichern abgelehnt, nicht verworfen. Struktur: `{"full_name"\|"first_name"\|"last_name"\|"address": {"source": "document_ai"\|"questionnaire"\|"expected_data", "key": "\|\|expected_details.\|metadata."}}`. | | `bank_name_match_threshold` | integer | Ab diesem Wert gilt der Inhabername als übereinstimmend. `50` bis `100`, Standardwert ist `85`. | | `bank_partial_match_floor` | integer | Unter diesem Wert gilt der Inhabername als nicht übereinstimmend. `0` bis `99`, Standardwert ist `70`. Der Bereich zwischen dem Mindestwert und dem Schwellenwert ist die teilweise Übereinstimmung, daher muss der Mindestwert strikt unter dem Schwellenwert liegen, andernfalls wird das Speichern verweigert. Ein explizites `null` bedeutet hier "Standardwert verwenden", weshalb ein Schwellenwert von `50` ohne Mindestwert abgelehnt wird: Er wird als `50` gegen den Standard-Mindestwert von `70` geprüft. | | `bank_require_address_match` | boolean | Erfordert zusätzlich, dass die Adresse des Inhabers übereinstimmt. Ein Name, der den Schwellenwert erreicht hat, dessen Adresse jedoch darunter liegt, wird zu einer teilweisen Übereinstimmung herabgestuft. Ein Institut, das keine Adresse zurückgibt, entbindet von dieser Anforderung; eine Sitzung ohne eigene Adresse zum Abgleich tut dies nicht und führt zu einer teilweisen Übereinstimmung. Standardmäßig deaktiviert. | | `bank_use_provider_score` | boolean | Liest auch den institutseigenen Inhabernamen-Score und lässt diesen entscheiden, wenn er höher als der von Didit ist oder wenn Didit überhaupt keinen Inhabernamen zum Bewerten hatte. Ein auf diese Weise entschiedenes Ergebnis gibt `provider_only` als Abgleichmethode an, und eine Verbindung, die keinen solchen Score zurückgegeben hat, erfasst eine `provider_score_unavailable`-Warnung. Standardmäßig aktiviert. | | `bank_show_match_result_to_user` | boolean | Zeigt dem Benutzer das Ergebnis des Eigentümerabgleichs innerhalb des Verifizierungsablaufs an. Deaktiviert bedeutet, dass es in der Sitzung erfasst, ihm aber nie angezeigt wird. | ### Kontoprüfung Diese Schlüssel gelten nur für die Kontoprüfung. Bei der Bank-Anmeldung gelten weiterhin die Regeln für enge Übereinstimmungen sowie das eigene `bank_max_attempts`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `bank_account_check_accept_close_match` | boolean | Wenn diese Option aktiviert ist (Standardwert), gilt ein Name, den die Bank zwischen `bank_partial_match_floor` und `bank_name_match_threshold` einstuft, als enge Übereinstimmung: Der Benutzer bestätigt den bei der Bank hinterlegten Namen, wenn `bank_suggest_holder_name` aktiviert ist, und `bank_partial_match_action` entscheidet. Deaktiviert ist diese enge Übereinstimmung keine Übereinstimmung (`OWNER_NAME_MISMATCH`, entschieden durch `bank_no_match_action`) und verbraucht den Versuch. | | `bank_account_check_max_attempts` | integer | Wie viele Kontoprüfungen dem Benutzer zur Verfügung stehen: `1` bis `5`, standardmäßig `3`: wie oft er die Kontodaten für eine Prüfung eingeben kann, die von der Bank beantwortet wird. Diese Anzahl wird getrennt von `bank_max_attempts` gezählt. Eine aufgrund der Eingabe abgelehnte Prüfung (eine ungültige IBAN) oder eine, die die Bank nicht beantworten konnte, verbraucht keinen Versuch. | ### Finanzdaten `bank_expected_currencies` funktioniert allein mit der Standard-Einwilligung `ownership`. Die anderen drei Schlüssel lesen echte Finanzdaten, daher benötigt jeder den passenden Einwilligungsumfang in `bank_scopes`, und das Speichern wird ohne diesen verweigert. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `bank_expected_currencies` | string\[] | ISO 4217-Währungen, auf die das Konto lauten soll. Leer bedeutet beliebig; eine Abweichung wird über `bank_currency_mismatch_action` gemeldet. | | `bank_min_balance` | number | Mindestbetrag des verfügbaren Guthabens in der Kontowährung. Darunter wird `bank_low_balance_action` ausgelöst. Erfordert den Scope `balances`. `0` ist ein echter Grenzwert und nicht dasselbe wie das Weglassen des Schlüssels: Ein überzogenes Konto löst die Aktion aus. Diese Aktion ist standardmäßig `NO_ACTION`, wodurch die Entscheidung unverändert bleibt; das Ablehnen eines überzogenen Kontos erfordert daher zusätzlich `bank_low_balance_action: "DECLINE"`. | | `bank_transactions_history_days` | integer | Wie weit der Transaktionsverlauf zurückgelesen wird, `30` bis `365` Tage. Standardwert ist `90`. Erfordert den Scope `transactions`. | | `bank_refresh_enabled` | boolean | Finanzdaten des Kontos erneut abrufen, nachdem der Schritt bereits entschieden wurde, solange die Einwilligung der Bank gültig ist. Erfordert mindestens einen der Scopes `balances`, `transactions` oder `income`. Eine Einwilligung, die danach abläuft, wird über `bank_consent_expired_action` gesteuert. | ### Was gespeichert wird | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `bank_store_full_identifiers` | boolean | Die Kontokennungen unmaskiert statt maskiert speichern. Erfordert den Scope `identifiers`. Selbst dann wird die unmaskierte Form nur an einen Aufrufer zurückgegeben, der die Leseberechtigung für die Bankverifizierung besitzt. | | `bank_store_raw_owner_data` | boolean | Die vom Institut zurückgegebenen Kontoinhaberdaten neben dem Eigentumsnachweis aufbewahren. Deaktiviert bedeutet, dass nur der Vergleich selbst beibehalten wird: Scores, Abgleichmethode und Begründungscodes. | ### Entscheidungsaktionen Jeder Schlüssel hier akzeptiert `DECLINE`, `REVIEW` oder `NO_ACTION`, sofern er nicht als eingeschränkt gekennzeichnet ist, und greift auf den unten stehenden Standardwert zurück, wenn Sie ihn weglassen oder `null` übergeben. Alles, was kein positiver Eigentumsnachweis ist, wird standardmäßig nicht genehmigt, und nur nachweisbare Belege gegen den Benutzer führen standardmäßig zu einer Ablehnung. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `bank_no_match_action` | eingeschränkte Aktion | Entscheidung, wenn der Kontoinhaber nachweislich nicht die verifizierte Person ist – der Wert für die beste Namensübereinstimmung liegt unter `bank_partial_match_floor`. Verwenden Sie `DECLINE` oder `REVIEW`. Standardwert ist `DECLINE`. | | `bank_partial_match_action` | Aktion | Entscheidung, wenn der Wert für die Namensübereinstimmung zwischen `bank_partial_match_floor` und `bank_name_match_threshold` liegt. Standardwert ist `REVIEW` und führt standardmäßig nie zu einer Genehmigung. | | `bank_not_verifiable_action` | Aktion | Entscheidung, wenn das Institut zwar verbunden wurde, aber keine Inhaberidentität zum Abgleichen zurückgegeben hat. Standardwert ist `REVIEW`. | | `bank_unknown_action` | Aktion | Entscheidung, wenn der Nachweis nach Wiederholungsversuchen nicht abgerufen werden konnte – ein vorübergehender Fehler. Standardwert ist `REVIEW`. | | `bank_reference_identity_missing_action` | Aktion | Entscheidung, wenn kein vorheriger Schritt eine Identität geliefert hat, mit der der Inhaber abgeglichen werden könnte, sodass die Eigentümerschaft nur `unknown` sein kann. Standardwert ist `REVIEW`. | | `bank_joint_account_action` | Aktion | Entscheidung, wenn das Konto mehr als einen Inhaber hat. Standardwert ist `NO_ACTION`. | | `bank_business_account_action` | Aktion | Entscheidung, wenn das Institut den Inhaber als Unternehmen statt als Person einstuft. Standardwert ist `REVIEW` bei einem Personen-Workflow und `NO_ACTION` bei einem Unternehmens-Workflow (KYB), bei dem ein geschäftlicher Inhaber von der Sitzung erwartet wird. | | `bank_unsupported_action` | Aktion | Entscheidung, wenn der Benutzer ohne Bank fortfährt, weil keine Methode dessen Land oder Bank verifizieren konnte: Keine Route für Bank-Anmeldung oder Kontoüberprüfung unterstützt das Land, oder die gewählte Bank kann in diesem Schritt nicht verwendet werden. Das Ergebnis weist dann `continued_without_bank` als true und `NOT_COVERED` in seinen Begründungscodes auf. Standardwert ist `REVIEW`. | | `bank_skipped_action` | eingeschränkte Aktion | Entscheidung, wenn der Benutzer „Ohne Bank fortfahren“ ausgewählt hat, obwohl eine Verifizierungsmethode verfügbar war. Das Ergebnis weist dann `continued_without_bank` als true und `SKIPPED` in seinen Begründungscodes auf. Verwenden Sie `DECLINE` oder `REVIEW`. Standardwert ist `REVIEW`. | | `bank_attempts_exhausted_action` | eingeschränkte Aktion | Entscheidung, wenn der Benutzer die Versuche aller ihm noch angebotenen Verifizierungswege aufgebraucht hat, einschließlich des Uploads von Kontoauszügen (`bank_max_attempts` und `bank_account_check_max_attempts`, sofern das Land die Kontoüberprüfung anbietet), ohne dass eine erfolgreiche Verbindung zustande kam, auch wenn er anschließend ohne Bank fortfährt. Verwenden Sie `DECLINE` oder `REVIEW`. Standardwert ist `DECLINE`. | | `bank_consent_expired_action` | Aktion | Entscheidung, wenn die Einwilligung der Bank abläuft, nachdem der Schritt bereits entschieden wurde. Nur sinnvoll bei `bank_refresh_enabled`. Standardwert ist `NO_ACTION`. | | `bank_currency_mismatch_action` | Aktion | Entscheidung, wenn die Kontowährung nicht in `bank_expected_currencies` enthalten ist. Standardwert ist `NO_ACTION`. | | `bank_country_mismatch_action` | Aktion | Entscheidung, wenn das Land des Instituts vom erwarteten Land oder Dokumentenland abweicht. Standardwert ist `NO_ACTION`. | | `bank_low_balance_action` | Aktion | Entscheidung, wenn das verfügbare Guthaben unter `bank_min_balance` liegt. Erfordert den Scope `balances`. Standardwert ist `NO_ACTION`. | | `status_rules` | Array | Optionale benutzerdefinierte Statusregeln. | ### Weitere Steuerelemente Diese Schlüssel sind optional. Jeder Aktionsschlüssel akzeptiert `DECLINE`, `REVIEW` oder `NO_ACTION`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `bank_abandoned_action` | Aktion | Entscheidung, wenn der Schritt ohne Übereinstimmung endet, nachdem die Person den Vorgang bei ihrer Bank verlassen hat und nicht zurückgekehrt ist (Zeitüberschreitung eines Versuchs). | | `bank_account_age_action` | Aktion | Entscheidung, wenn das Konto jünger als `bank_account_age_days` ist, ein typisches Mule-Muster. | | `bank_account_age_days` | integer | Ein Konto, dessen Verlauf erst vor weniger als dieser Anzahl von Tagen beginnt, gilt als neu; 1 bis 365, Standardwert ist 30. Wird aus dem Transaktionsverlauf ausgelesen, daher nur mit dem Scope `transactions`. | | `bank_account_lookup_enabled` | boolean | Veraltet: Verwenden Sie `bank_method_order` und `bank_countries..methods`. Wird für ein Release aus einem Speichervorgang gelesen, der kein `bank_method_order` sendet: Zusammen mit `bank_open_banking_enabled` legt dieser Parameter die Reihenfolge fest: Die Kontoüberprüfung erfolgt nach der Bank-Anmeldung, wenn der Parameter aktiviert ist, und wird weggelassen, wenn er deaktiviert oder nicht gesetzt ist. Bei jedem Speichern wird zurückgeschrieben, ob ein Land die Kontoüberprüfung anbietet. | | `bank_account_type_action` | Aktion | Entscheidung, wenn das verifizierte Konto ein Sparkonto ist. | | `bank_address_match_threshold` | integer | Ab diesem Score gilt die Adresse des Inhabers als übereinstimmend; 50 bis 100, Standardwert ist 70. Wird nur bei `bank_require_address_match` gelesen. | | `bank_address_mismatch_action` | Aktion | Entscheidung, wenn die Adresse des Inhabers abweicht, wodurch eine Übereinstimmung zu einer teilweisen Übereinstimmung wird. Nur bei `bank_require_address_match`. | | `bank_auto_add_countries` | boolean | Jedes Land anbieten, das über eine Route dieses Knotens bedient werden kann, auch solche, die nach dem Speichern des Knotens hinzugefügt wurden – mit Ausnahme der Länder, die über `bank_countries` deaktiviert sind. Deaktiviert, wenn der Schlüssel fehlt, sodass ein vorhandener Knoten sich nie selbstständig erweitert. | | `bank_cash_flow_action` | Aktion | Entscheidung, wenn Geld eingeht und direkt wieder abfließt oder viele kleine Überweisungen eingehen (Pass-Through-Cashflow). Erfordert den `transactions`-Scope. | | `bank_dob_match_enabled` | boolean | Vergleicht das Geburtsdatum des Inhabers, sofern die Bank eines übermittelt, mit dem verifizierten Geburtsdatum. Eine Nichtübereinstimmung ändert das Ergebnis der Kontoinhaberschaft nie: Sie löst `bank_dob_mismatch_action` aus. Standardmäßig aktiviert. | | `bank_dob_match_threshold` | integer | Ab diesem Wert gilt das Geburtsdatum als übereinstimmend, 50 bis 100, standardmäßig 70. Ein Geburtsdatum entspricht entweder demselben Tag oder nicht; daher liegt der Wert bei 100 oder 0. | | `bank_dob_mismatch_action` | Aktion | Entscheidung, wenn das Geburtsdatum des Inhabers abweicht. Nur mit `bank_dob_match_enabled`. | | `bank_email_match_enabled` | boolean | Vergleicht die bei der Bank hinterlegte E-Mail-Adresse mit der verifizierten E-Mail-Adresse der Sitzung. Eine Nichtübereinstimmung löst `bank_email_mismatch_action` aus. Standardmäßig deaktiviert. | | `bank_email_match_threshold` | integer | Ab diesem Wert gilt die E-Mail-Adresse als übereinstimmend, 50 bis 100, standardmäßig 70. | | `bank_email_mismatch_action` | Aktion | Entscheidung, wenn die E-Mail-Adresse des Inhabers abweicht. Nur mit `bank_email_match_enabled`. | | `bank_evidence_retention_days` | integer | Löscht die Banknachweise so viele Tage nach der Entscheidung: 30, 90, 365 oder 1825. Null bewahrt sie zusammen mit der Sitzung auf. Gelöscht werden: die Inhaberdaten, die Identität, mit der sie verglichen wurden, die Kontokennungen, die Finanzdaten und ein hochgeladener Kontoauszug; eine noch aktive Verbindung wird widerrufen. Die Entscheidung, Werte und Ursachencodes bleiben erhalten. Das Löschen der Sitzung löscht alles, je nachdem, was zuerst eintritt. | | `bank_fallback_used_action` | Aktion | Entscheidung, wenn das Konto über Micro-Deposits oder einen Kontoauszug-Upload verifiziert wurde. | | `bank_match_any_holder` | boolean | Ein Gemeinschaftskonto gilt als übereinstimmend, wenn IRGENDEIN aufgeführter Inhaber mit der Person übereinstimmt. Deaktiviert: Nur der von der Bank zuerst aufgeführte Inhaber kann übereinstimmen. Standardmäßig aktiviert. | | `bank_microdeposits_enabled` | boolean | Bietet Micro-Deposits als Fallback an: Zwei kleine Einzahlungen gehen auf dem Konto ein und die Person gibt die Beträge ein. Wird nur in einem Land angeboten, dessen Route diese senden kann, und zwar nach einem kostenpflichtigen Bankverifizierungsversuch in derselben Sitzung. Ohne Aufpreis enthalten; der Kunde zahlt den Routenpreis einmalig. Sandbox-Sitzungen können dies ohne Abrechnung testen. Als Inhaber gilt der in der Sitzung verifizierte Name, auf den das Konto laut Angabe der Person lautet; daher erfasst ein verifiziertes Konto eine `holder_declared`-Warnung. Standardmäßig aktiviert. | | `bank_mule_score_action` | Aktion | Entscheidung, wenn der Mule-Score bei oder über `bank_mule_score_threshold` liegt. | | `bank_mule_score_threshold` | integer | Ab diesem Mule-Score, 0 bis 100, wird `bank_mule_score_action` ausgelöst; standardmäßig 70. Der Score kombiniert ein neues Konto, Pass-Through-Cashflow, ein leergeräumtes Guthaben und viele kleine eingehende Überweisungen, ausgelesen aus dem Transaktionsverlauf (der `transactions`-Scope). | | `bank_open_banking_enabled` | boolean | Veraltet: Verwenden Sie `bank_method_order` und `bank_countries..methods`. Wird für ein Release aus einem Speichervorgang ausgelesen, der kein `bank_method_order` sendet: Wenn `bank_account_lookup_enabled` aktiviert ist, setzt es die Reihenfolge auf Bank-Login, sofern der Wert aktiviert oder nicht gesetzt ist. Jeder Speichervorgang schreibt zurück, ob irgendein Land Bank-Login anbietet. | | `bank_phone_match_enabled` | boolean | Vergleicht die bei der Bank hinterlegte Telefonnummer mit der verifizierten Telefonnummer der Sitzung. Eine Nichtübereinstimmung löst `bank_phone_mismatch_action` aus. Standardmäßig deaktiviert. | | `bank_phone_match_threshold` | integer | Ab diesem Wert gilt die Telefonnummer als übereinstimmend, 50 bis 100, standardmäßig 70. | | `bank_phone_mismatch_action` | Aktion | Entscheidung, wenn die Telefonnummer des Inhabers abweicht. Nur mit `bank_phone_match_enabled`. | | `bank_popular_mode` | string | `auto` (Standard) sortiert die beliebten Banken danach, was Personen im jeweiligen Land am häufigsten verbinden; `manual` zeigt stattdessen die `popular_institutions` jedes Landes aus `bank_countries` in deren Reihenfolge an. | | `bank_statement_document_checks_action` | Aktion | Entscheidung, wenn ein hochgeladener Kontoauszug Hinweise auf Bearbeitung oder Manipulation aufweist. Standardmäßig `REVIEW`. | | `bank_statement_enabled` | boolean | Bietet den Upload eines Kontoauszugs als Fallback an: ein Kontoauszug aus den letzten 3 Monaten, geprüft auf Manipulation, dessen Inhabername wie bei einer Bank abgeglichen wird. Nach einem kostenpflichtigen Bankverifizierungsversuch in derselben Sitzung ohne Aufpreis enthalten. Mit `bank_statement_standalone_enabled` wird dies auch ohne vorherigen Bankversuch in jedem Land angeboten und dann separat abgerechnet. Sandbox-Sitzungen können dies ohne Abrechnung testen. Standardmäßig deaktiviert. | | `bank_suggest_holder_name` | boolean | Bei einer knappen Übereinstimmung wird der Person der Name angezeigt, unter dem die Bank das Konto führt, und sie wird gebeten zu bestätigen, dass es ihr gehört, oder ein anderes Konto zu verbinden. Ihre Antwort wird als `holder_confirmation` erfasst; die Bestätigung beendet den Schritt mit `bank_partial_match_action`. Standardmäßig aktiviert. | | `fallback_to_native` | boolean | Gibt an, ob eine Marketplace-Verbindung, die nicht hergestellt werden kann, auf Didits native Route zurückgreift. Standardmäßig deaktiviert: Ein stiller Fallback würde Ihr Didit-Guthaben für eine Sitzung verbrauchen, von der Sie erwartet haben, dass sie über Ihren eigenen Provider-Vertrag läuft. Eine Fallback-Verbindung wird als `credential_source = native` erfasst und zum nativen Preis abgerechnet. | | `provider_key` | string | Gibt an, welche Route den Schritt ausführt. Leer (Standard) ist Didits native Bankverifizierung, ein anbieterunabhängiges Produkt, das Didit über Didits Verträge und Abrechnung an den regionalen Open-Banking-Anbieter weiterleitet, der das Land und das Institut des Benutzers abdeckt. Ein Wert benennt einen MARKETPLACE-Provider, dessen eigene Anmeldedaten diese Anwendung verknüpft hat – die Sitzung wird dann über Ihr Provider-Konto ausgeführt, abgerechnet und widerrufen, und Didit berechnet lediglich die Marketplace-Plattformgebühr. Ein Provider, der nicht verknüpft ist, wird beim Speichern abgelehnt. | Beispiel für ein `config`-Objekt für ein Konto, bei dem die Bankverifizierung aktiviert ist und die ausgewählte Route das angegebene Land abdeckt: ```json theme={null} { "bank_method_order": ["open_banking", "account_lookup"], "bank_countries": { "ESP": { "enabled": true, "institutions": "all" } }, "bank_scopes": { "ownership": true }, "bank_eligible_account_types": ["checking", "current"], "bank_name_match_threshold": 85, "bank_partial_match_floor": 70, "bank_partial_match_action": "REVIEW", "bank_no_match_action": "DECLINE" } ``` > [!WARNING] > > `bank_countries` sorgt dafür, dass dieser Schritt überhaupt ausgeführt wird, und wird anhand der Route > geprüft, auf der der Knoten ausgeführt wird, nicht anhand einer globalen Liste. Ein Land, in dem diese > Route keine Kontoinhaberschaft feststellen kann, wird beim Speichern abgelehnt und im Fehler benannt; > lesen Sie daher die Fehlermeldung, anstatt davon auszugehen, dass das Land akzeptiert wurde und zur > Laufzeit übersprungen wird. ## AML Funktionswert: `AML`. Für das KYC-Personen-Screening verwenden Sie diese Felder: | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `is_aml_ongoing_monitoring_enabled` | boolean | Aktiviert die laufende AML-Überwachung. | | `aml_score_approve_threshold` | integer | Schwellenwert für Genehmigung. | | `aml_score_review_threshold` | integer | Schwellenwert für Prüfung. | | `aml_match_score_threshold` | integer | Schwellenwert für den Übereinstimmungswert bei möglichen Treffern. | | `aml_name_weight` | integer | Gewichtung des Namens. Wenn eine AML-Gewichtung angegeben wird, müssen die Gewichtungen für Name, Geburtsdatum und Land in Summe `100` ergeben. | | `aml_dob_weight` | integer | Gewichtung des Geburtsdatums. | | `aml_country_weight` | integer | Gewichtung des Landes. | | `create_cases_on_hit` | boolean | Eröffnet bei einem Treffer des Screenings automatisch einen Fall, statt den Treffer aus der Sitzung heraus einer Triage zu überlassen. Standardmäßig deaktiviert. | | `case_blueprint` | uuid | Aus welcher Fallvorlage der automatisch erstellte Fall aufgebaut wird. Nur in Verbindung mit `create_cases_on_hit` relevant; ist dies nicht gesetzt, wird der Account-Standard verwendet. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | Für das KYB-Unternehmens-Screening verwenden Sie diese Felder: | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `kyb_score_approve_threshold` | integer | Schwellenwert für die Genehmigung beim Unternehmens-AML. | | `kyb_score_review_threshold` | integer | Schwellenwert für die Prüfung beim Unternehmens-AML. | | `kyb_enable_ongoing_monitoring` | boolean | Aktiviert die laufende AML-Überwachung für KYB. | | `kyb_company_aml_match_score_threshold` | integer | Schwellenwert für den Übereinstimmungswert beim Unternehmens-AML. | | `kyb_company_aml_name_weight` | integer | Gewichtung des Unternehmensnamens. Sofern angegeben, müssen die Unternehmens-AML-Gewichtungen in Summe `100` ergeben. | | `kyb_company_aml_dob_weight` | integer | Gewichtung des Gründungsdatums oder Geburtsdatums. | | `kyb_company_aml_country_weight` | integer | Gewichtung des Landes. | ### Screening einer durch einen Document-AI-Schritt extrahierten Entität Ein AML-Schritt liest normalerweise aus dem `OCR`-Schritt (eine Person) oder dem `KYB_REGISTRY`-Schritt (ein Unternehmen), wer überprüft werden soll. Ein Workflow, dessen einziger Extraktionsschritt `DOCUMENT_AI` ist – nicht standardisierte Dokumente wie eine Steuerbescheinigung oder eine Gründungsurkunde –, hat keines von beiden und muss daher angeben, woher die jeweiligen Screening-Eingabedaten stammen. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `aml_field_sources` | object | Woher die Entität gelesen wird, die dieser Schritt überprüft. `source` benennt den Erzeuger und `key` benennt den Wert darin: ein Document AI-Feldschlüssel für `document_ai`, eine Fragebogen-Knoten-ID für `questionnaire` sowie `expected_details.` oder `metadata.` für `expected_data`. Der SCHLÜSSEL der Map ist eine der vier Screening-Eingaben – `full_name`, `date_of_birth`, `nationality`, `document_number` –, die bei einem Unternehmen als Firmenname, Gründungsdatum, Land und Registernummer interpretiert werden. Ein Document AI-Feld, dessen Schlüssel bereits einem dieser vier entspricht, wird automatisch zugewiesen und bewusst nicht dauerhaft gespeichert, sodass das Umbenennen niemals ein veraltetes Mapping einfriert. Ein explizites Mapping hat Vorrang vor dem Auto-Mapping und dem Ausweisdokument; löst es zur Laufzeit in nichts auf, bleibt die Eingabe leer, anstatt auf einen Fallback zurückzugreifen. In einem Unternehmens-Workflow (KYB) ist das von einem `KYB_REGISTRY`-Schritt zurückgegebene Unternehmen maßgeblich: Nur ein explizites Mapping überschreibt eine seiner Eingaben, das Auto-Mapping wird nicht auf einen Registereintrag angewendet, und ohne Register-Schritt stellt das Mapping die gesamte Identität dar. Struktur: `{"full_name"\|"date_of_birth"\|"nationality"\|"document_number": {"source": "document_ai"\|"questionnaire"\|"expected_data", "key": "\|\|expected_details.\|metadata."}}`. | | `aml_entity_type` | string | `person` oder `company`. Standardmäßig `person` bei einem Personen-Workflow (KYC) und `company` bei einem Unternehmens-Workflow (KYB). Setzen Sie `company`, um das in einem hochgeladenen Dokument genannte Unternehmen ohne einen `KYB_REGISTRY`-Schritt zu überprüfen: Der Anbieter durchsucht Unternehmensdatensätze, und der Übereinstimmungswert wird nach den Regeln für Unternehmen bewertet. | | `aml_incomplete_data_action` | action | Entscheidung, wenn das Screening mit weniger als einer vollständigen Identität (Name, Geburtsdatum und Land) ausgeführt wurde. Standard ist `REVIEW`. `NO_ACTION` setzt den Vorgang bei reduzierten Daten fort, falls ein Workflow wissentlich nur einen Namen enthält. Das Screening wird in beiden Fällen ausgeführt, und das Protokoll über unvollständige Daten wird in beiden Fällen aufgezeichnet – dies entscheidet lediglich darüber, wie sich dies auf den Status auswirkt. | Beispiel – Screening des in einer mexikanischen *acta constitutiva* genannten Unternehmens, ohne Ausweisdokument an irgendeiner Stelle im Workflow: ```json theme={null} { "feature": "AML", "config": { "aml_entity_type": "company", "aml_field_sources": { "full_name": { "source": "document_ai", "key": "razon_social" }, "document_number": { "source": "document_ai", "key": "rfc" }, "date_of_birth": { "source": "document_ai", "key": "fecha_constitucion" }, "nationality": { "source": "document_ai", "key": "pais" } }, "aml_incomplete_data_action": "REVIEW" } } ``` > [!WARNING] > > Ohne einen vorherigen `OCR`- oder `KYB_REGISTRY`-Schritt muss ein `AML`-Schritt in der > Lage sein, `full_name` auszufüllen – ohne Namen gibt es keine Anbietersuche. Ein Workflow, > der nichts zuweist oder einen Document-AI-Schlüssel zuweist, den kein vorgelagerter Schritt > extrahiert, wird beim Speichern abgelehnt, anstatt gespeichert zu werden und anschließend nichts > zu screenen. Die AML-Präzision hängt direkt davon ab, wie viele Identifikatoren Sie bereitstellen: > Ein reines Namens-Screening führt zu einem hohen Aufkommen an falsch positiven Ergebnissen. ## Geräte- und IP-Analyse Feature-Wert: `IP_ANALYSIS`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `ip_mismatch_action` | action | Aktion, wenn die IP-Geolokalisierung nicht mit den erwarteten Daten übereinstimmt. | | `ip_location_not_determined_action` | action | Entscheidung, wenn keine IP-Adresse zur Identifizierung des Endbenutzers erfasst wurde, sodass die Sitzung über keinerlei IP-Standort verfügt: Land, Stadt, Internetdienstanbieter (ISP), Koordinaten und Zeitzone sind nicht verfügbar, und `ip_geofencing_by_country`, der Abgleich mit dem Dokumentenland sowie die VPN-/Rechenzentrumsprüfungen können nicht ausgeführt werden. Standardwert ist `NO_ACTION`, wodurch die Warnung `IP_LOCATION_NOT_DETERMINED` in der Sitzung sichtbar bleibt, ohne deren Entscheidung zu ändern; setzen Sie `REVIEW` oder `DECLINE`, wenn eine Sitzung ohne Standort nicht bestanden werden darf. | | `vpn_detection_action` | action | Aktion, wenn die Nutzung eines VPNs oder Proxys erkannt wird. | | `expected_ip_mismatch_action` | action | Aktion, wenn die IP nicht mit der erwarteten IP übereinstimmt. | | `duplicated_ip_action` | action | Aktion, wenn die IP verdächtig wiederverwendet wird. | | `duplicated_device_action` | action | Aktion, wenn derselbe persistente Geräte-Fingerabdruck über Sitzungen mit unterschiedlichen `vendor_data`-Werten hinweg wiederverwendet wird. | | `recovered_device_action` | action | Aktion, wenn die v2-Fingerabdruck-Wiederherstellung die Sitzung mit hoher Konfidenz mit einem zuvor erfassten Gerät verknüpft, nachdem sich die persistente Geräte-ID geändert hat. | | `is_ip_geofencing_enabled` | boolean | Aktiviert IP-Geofencing-Beschränkungen. Wenn `false`, bleibt `ip_geofencing_by_country` erhalten, wird jedoch nicht erzwungen. | | `ip_geofencing_by_country` | object | Regeln für IP-Standorte pro Land, indiziert nach ISO-3-Ländercode: `{"USA": {"allowed": true, "states": {"California": {"allowed": false}}}}`. Bundesstaat-/Regions-Einträge überschreiben das Länder-Flag; nicht aufgeführte Länder sind erlaubt. | | `ip_geofencing_action` | action | Aktion, wenn sich die Sitzungs-IP in einem nicht zulässigen Land oder Bundesstaat/einer nicht zulässigen Region befindet. Standardwert ist `DECLINE`. | | `automation_detected_action` | action | Entscheidung, wenn die Sitzung den Anschein erweckt, durch Automatisierung statt durch eine Person gesteuert zu werden. | | `cross_org_fraud_device_action` | action | Entscheidung, wenn dieses Gerät von einer anderen Organisation im Netzwerk als betrügerisch markiert wurde. | | `cross_org_fraud_ip_action` | action | Entscheidung, wenn diese IP von einer anderen Organisation im Netzwerk als betrügerisch markiert wurde. | | `device_app_tampered_action` | action | Entscheidung, wenn die Binärdatei der Host-Anwendung manipuliert erscheint. | | `device_blocklist_action` | action | Entscheidung, wenn das Gerät auf der Sperrliste der Organisation steht. | | `device_debugger_action` | action | Entscheidung, wenn ein Debugger an die Host-Anwendung angehängt ist. | | `device_emulator_action` | action | Entscheidung, wenn das Gerät ein Emulator anstelle echter Hardware ist. | | `device_hooking_action` | action | Entscheidung, wenn Laufzeit-Hooking oder Instrumentierung erkannt wird. | | `device_integrity_missing_action` | action | Entscheidung, wenn keine Plattform-Attestierung zur Geräteintegrität zurückgegeben wurde. | | `device_rooted_action` | action | Entscheidung, wenn das Gerät gerootet oder gejailbreakt ist. | | `multiple_devices_action` | action | Entscheidung, wenn die Sitzung von mehr als einem Gerät aus gesteuert wurde. | | `device_liveness_attack_history_action` | action | Aktion, wenn dasselbe Gerät (abgeglichen über seine persistente Geräte-ID) in einer früheren Sitzung eines anderen Benutzers verwendet wurde, dessen Liveness-Erfassung als Angriff gewertet wurde (Warnung `DEVICE_LINKED_TO_LIVENESS_ATTACK`). Standardwert ist `NO_ACTION`. | | `device_model_inconsistency_action` | action | Aktion, wenn dasselbe Gerät (abgeglichen über seine persistente Geräte-ID) in einer früheren Sitzung als ein anderes Gerätemodell gemeldet wurde (Warnung `DEVICE_MODEL_INCONSISTENT`). Standardwert ist `NO_ACTION`. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | Beispiel: ```json theme={null} { "feature": "IP_ANALYSIS", "config": { "vpn_detection_action": "REVIEW", "duplicated_device_action": "REVIEW", "recovered_device_action": "REVIEW", "is_ip_geofencing_enabled": true, "ip_geofencing_by_country": { "USA": { "allowed": true, "states": { "California": { "allowed": false } } }, "RUS": { "allowed": false, "states": null } }, "ip_geofencing_action": "DECLINE" } } ``` Verwenden Sie `recovered_device_action` separat von `duplicated_device_action`, wenn Sie wiederhergestellte Geräte mit hoher Konfidenz überwachen möchten, bevor Sie sie automatisch ablehnen. Dies ist während des Rollouts nützlich, da Übereinstimmungen wiederhergestellter Geräte für die Erkennung von Betrugsringen konzipiert sind, jedoch dennoch anhand Ihres eigenen Datenverkehrs kalibriert werden sollten. ## Standortverifizierung Funktionswert: `GEOLOCATION`. Prüft, wo sich die Person während der Verifizierung befindet, anhand der Geräteposition oder des IP-Standorts der Verbindung, und gleicht dies mit zulässigen und blockierten Gebieten, dem IP-Standort und der Dokumentadresse ab. Siehe [Standortverifizierung](https://docs.didit.me/de/core-technology/location-verification/overview.md) zum Verhalten des Schritts und [dessen Bericht](https://docs.didit.me/de/core-technology/location-verification/report-location-verification.md) für die Entscheidungsfelder. Platzieren Sie diesen Schritt nach Ausweisverifizierung oder Adressnachweis, wenn Sie die Entfernung zu einer Dokumentadresse benötigen, da die Entfernung nur gemessen wird, wenn eine Adresse hinterlegt ist. Wenn `geolocation_position_source` nicht gesetzt ist, erfordert die Entfernung zum IP-Standort einen Schritt zur Geräte- und IP-Analyse im selben Workflow. Jeder Schlüssel ist optional: Ein Schritt mit einer leeren `config` fragt beim Gerät eine auf 250 m genaue Position ab, die nicht älter als 120 Sekunden ist, gewährt der Person 3 Versuche und wendet keine Gebietsregel an. Jedes Ergebnis hat seinen eigenen Aktionsschlüssel. Ein nicht gesetzter Aktionsschlüssel übernimmt den Standardwert des gewählten `geolocation_preset` oder den unten aufgeführten Standardwert pro Schlüssel, falls keines gewählt wurde. Bei einem ungenauen oder verweigerten Standort wird standardmäßig `REVIEW` verwendet, niemals `DECLINE`, da eine verweigerte Berechtigung oder ein großer Radius kein Betrugsnachweis ist. Eine explizit festgelegte Aktion hat immer Vorrang vor dem Preset. Eine wieder abgespielte Challenge (`LOCATION_REPLAY_DETECTED`) und eine fehlgeschlagene Geräte-Attestierung (`LOCATION_INTEGRITY_FAILED`) führen immer zu einer Ablehnung und haben keinen Aktionsschlüssel. | Config-Feld | Typ | Beschreibung | | - | - | - | | `geolocation_position_source` | string | Gibt an, woher die Position stammt. `device_and_ip` fragt die Geräteposition ab und vergleicht sie mit dem IP-Standort der Verbindung, von der sie übermittelt wird (eine IP-Intelligence-Abfrage, falls diese IP noch nicht zwischengespeichert ist). Nicht gesetzt (Standardeinstellung) fragt ebenfalls die Geräteposition ab und vergleicht sie – wie vor der Einführung dieses Schlüssels – mit dem IP-Standort, den der Schritt zur Geräte- und IP-Analyse der Sitzung ermittelt hat; ohne diesen Schritt gibt es also keine Entfernungsberechnung und die Verbindung wird niemals nachgeschlagen. Die Ausnahme bildet ein Knoten, der auf ein VPN-, Proxy- oder Tor-Ergebnis reagiert (über seine eigene Aktion oder sein Preset): Er schlägt die Verbindung für dieses Ergebnis nach und vergleicht das Gerät damit, genau wie `device_and_ip`. `device_only` gleicht niemals mit dem IP-Standort ab und schlägt die Verbindung nur für diese Befunde nach; `ip_only` fragt die Person niemals ab und bewertet stattdessen den IP-Standort der Verbindung, auf Stadtebene mit einem Radius von 50 km, ohne Regeln für Genauigkeit, Aktualität oder die Erteilung einer ungefähren Position; bei `geolocation_areas` wird eine Küstenstadt als innerhalb ihres Landes liegend gewertet, es sei denn, ein anderes Land befindet sich innerhalb dieses Radius. Bei einem Knoten, der das Gerät abfragt, wird ein Versuch ohne Geräteposition als die jeweilige Verweigerung oder das jeweilige Fehlschlagen gewertet: Der IP-Standort dient niemals als Ersatz dafür. | | `geolocation_preset` | string | Die Standardwerte, die jede nicht gesetzte Aktion dieses Knotens übernimmt. `licensing`: außerhalb eines Gebiets, in einem blockierten Gebiet, ein VPN, Tor oder ein Emulator führt zur Ablehnung; ein Proxy und die übrigen Ergebnisse werden geprüft, und eine fehlende Geräte-Attestierung bleibt bei Keine Aktion. `fraud_screening`: dasselbe, außer dass das, was bei Licensing abgelehnt wird, in die Prüfung geht. Null behält die bisherigen Standardwerte bei. Eine explizit festgelegte Aktion hat immer Vorrang. | | `geolocation_accuracy_mode` | string | Was vom Gerät angefordert wird. `precise` fordert beim Betriebssystem eine genaue Position an; gewährt eine Person nur eine ungefähre Position, wird sie erneut dazu aufgefordert, solange Versuche verbleiben, und anschließend anhand von `geolocation_approximate_action` bewertet; `approximate_allowed` akzeptiert eine nur ungefähre Standortfreigabe ohne diese Beurteilung. `geolocation_max_accuracy_radius_m` gilt in beiden Fällen. `precise`, wenn nicht gesetzt. | | `geolocation_max_accuracy_radius_m` | integer | Der größte Unsicherheitsradius in Metern, den eine Geräteposition haben darf, um noch gewertet zu werden. Von 10 bis 50000 Metern; 250, wenn nicht gesetzt. Eine Position mit größerem Radius oder eine, die keinen Radius meldet, verhält sich gemäß `geolocation_low_accuracy_behavior` und wird nach `geolocation_low_accuracy_action` bewertet. Ein `ip_only`-Knoten hat keinen Geräteradius und wendet diesen Wert nie an. | | `geolocation_max_accuracy_radius_unit` | string | Die Einheit, in der die Konsole `geolocation_max_accuracy_radius_m` anzeigt. Dient nur der Anzeige: Der gespeicherte Wert ist immer in Metern angegeben, keine Regel hängt davon ab und die Schrittdaten leiten ihn lediglich weiter, damit ein Client dieselbe Einheit anzeigen kann. | | `geolocation_low_accuracy_behavior` | string | Das Verhalten bei einer Position mit einem größeren Radius als `geolocation_max_accuracy_radius_m` oder ohne gemeldeten Radius: `ask_again` (Standardeinstellung) fordert die Person zu einem erneuten Versuch auf, solange noch Versuche verbleiben; `fail` beendet den Schritt bereits beim ersten Auftreten. | | `geolocation_max_age_seconds` | integer | Wie alt eine Geräteposition in Sekunden sein darf, wenn der Server sie empfängt. Von 5 bis 3600 Sekunden; 120, wenn nicht gesetzt. Bei einer älteren Position wird die Person erneut aufgefordert, solange Versuche verbleiben, und die Position wird anschließend nach `geolocation_stale_fix_action` bewertet. | | `geolocation_timeout_seconds` | integer | Wie lange in Sekunden der Client das Gerät bei jedem Versuch nach einer Position suchen lässt; der Server leitet diesen Wert in den Schrittdaten weiter und erzwingt selbst nichts. Von 5 bis 120 Sekunden; 20, wenn nicht gesetzt. Ein Versuch, bei dem rechtzeitig keine Position ermittelt werden kann, wird als `timeout` übermittelt, bei verbleibenden Versuchen wiederholt und anschließend nach `geolocation_unavailable_action` bewertet. | | `geolocation_max_attempts` | integer | Wie viele Versuche die Person an diesem Knoten erhält. Von 1 bis 5 Versuche; 3, wenn nicht gesetzt. Bei einem Versuch, den die Person noch ändern kann (eine Verweigerung, eine ungenaue, veraltete oder ungefähre Position oder ein Gebiets- oder Anonymisierer-Befund, auf den der Knoten reagiert), wird bei verbleibenden Versuchen erneut nachgefragt, und der letzte Versuch entscheidet über den Schritt. Eine simulierte Position oder ein Emulator, auf den der Knoten reagiert, beendet den Schritt sofort bei dem Versuch, der dies gemeldet hat. | | `geolocation_allow_qr_handoff` | boolean | Bietet an, per QR-Code auf einem Smartphone fortzufahren, solange der Schritt noch geöffnet ist (`allow_qr_handoff` in den Schrittdaten, `can_handoff` in jeder Antwort auf eine Übermittlung). Native SDKs laufen bereits auf dem Smartphone und zeigen den Code niemals an. Standardmäßig aktiviert. | | `geolocation_allow_skip` | boolean | Ermöglicht es der Person, jederzeit ohne Standort fortzufahren – entweder vom Einführungs- oder von einem Wiederholungsbildschirm aus (`skipped: true`). Das Überspringen beendet den Schritt und wird nach `geolocation_unavailable_action` bewertet, außer bei einem Überspringen als Reaktion auf eine Verweigerung bei einem `geolocation_refusal_path` von `continue_without_location`, was als entsprechende Verweigerung erfasst wird. Standardmäßig deaktiviert. | | `geolocation_deep_link_enabled` | boolean | Wird in den Schrittdaten als `deep_link_enabled` an den Client weitergeleitet: bietet an, stattdessen die eigene App des Kunden zu öffnen. Der Server wendet keine Regel darauf an. Standardmäßig deaktiviert. | | `geolocation_refusal_path` | string | Das angebotene Vorgehen, wenn der Zugriff auf den Standort verweigert wird. `retry_then_handoff` (Standard) fragt erneut nach, solange Versuche verbleiben, und bietet ein Telefon-Handoff an; `continue_without_location` lässt die Person fortfahren und erfasst die Verweigerung; `end_session` beendet den Schritt und die Sitzung bei der ersten Verweigerung und erfordert, dass `geolocation_permission_denied_action` auf Review oder Decline gesetzt ist sowie einen Workflow mit einem Ende auf Declined, In Review oder Final decision. Die Entscheidung für die Sitzung wird anhand der ausgeführten Schritte getroffen und ist niemals Approved: In einem Workflow, der nicht mit dieser Entscheidung enden kann, nimmt sie das jeweils andere nicht genehmigende Ende an (Declined statt In Review, In Review statt Declined). | | `is_geolocation_geofencing_enabled` | boolean | Aktiviert die Bereichsregeln: `geolocation_areas` oder das ältere `geolocation_geofencing_by_country` gelten nur, wenn dies true ist, und nur dann listen die Schrittdaten `available_areas` auf. Standardmäßig deaktiviert. Wenn aktiviert, erfordert eine `geolocation_areas`-Liste mindestens einen zulässigen Bereich. | | `geolocation_areas` | array | Zulässige und gesperrte Bereiche, die angewendet werden, solange `is_geolocation_geofencing_enabled` true ist. Nur eine Position innerhalb eines zulässigen Bereichs wird akzeptiert, und ein gesperrter Bereich hat immer Vorrang vor einem zulässigen. Eine Position wird anhand ihres gesamten Genauigkeitskreises bewertet: Ein Kreis, der eine entscheidungsrelevante Kante schneidet, gilt als unbestimmt, niemals als außerhalb. Ein Land oder eine Region endet dort, wo anderes Landgebiet beginnt, niemals an seiner Küstenlinie, und eine Position, die nach den Umrissen auf keinem Land liegt (eine Uferpromenade oder ein Pier, die durch die vereinfachte Küstenlinie abgeschnitten wurden), ist für jedes Land oder jede Region innerhalb des Radius der Position plus 12 Seemeilen unbestimmt. `id` ist die Bezeichnung, die von Verzweigungsregeln und `geolocation.inside_areas` / `geolocation.blocked_areas` verwendet wird; `kind` wählt die Form: ein ganzes `country` (ISO 3166-1 alpha-3 mit veröffentlichter Kontur: Ein Gebiet, das in den Konturen als Region eines anderen Landes gezeichnet ist, ist diese `region`, wie etwa Réunion als Frankreichs `FR-RE` oder Bonaire, Sint Eustatius und Saba als `NL-BQ1` bis `NL-BQ3`), `region` (ISO 3166-2-Codes eines Landes mit veröffentlichten Grenzen), `circle` (1 bis 500 km) oder `polygon` (3 bis 200 Punkte, ein Ring, dessen Kanten einander weder kreuzen noch berühren). Maximal 50 Bereiche, eindeutige IDs und mindestens ein zulässiger Bereich, solange Geofencing aktiviert ist. Kann nicht mit `geolocation_geofencing_by_country` kombiniert werden. | | `geolocation_geofencing_by_country` | object | Regeln zum Zulassen und Verweigern von Ländern und Regionen für die eigene Position des Geräts, die nur angewendet werden, wenn `is_geolocation_geofencing_enabled` true ist. Dieselbe Struktur wie `ip_geofencing_by_country` der IP-Analyse, mit der Ausnahme, dass die Schlüssel von `states` ISO-3166-2-Codes (`US-NJ`) und keine Bundesstaatennamen sind, da die Position zu einer Unterteilung und nicht zur Stadtbezeichnung eines Anbieters aufgelöst wird. Ein nicht aufgeführtes Land ist zulässig. Das Speichern einer Regionsregel für ein Land ohne veröffentlichte ISO-3166-2-Grenzen wird abgelehnt, anstatt stillschweigend ignoriert zu werden. | | `geolocation_ip_distance_km` | integer | Wie weit die Geräteposition und der IP-Standort in Kilometern voneinander entfernt sein dürfen (nach Abzug beider Unsicherheitsradien), bevor `geolocation_ip_distance_action` angewendet wird. 200, wenn der Schlüssel weggelassen wird; null schaltet den Abgleich aus. Nur ein Knoten, dessen `geolocation_position_source` auf `device_and_ip` gesetzt oder nicht gesetzt ist, führt einen Abgleich durch; dieser Schlüssel gibt an, mit welchem IP-Standort verglichen wird. | | `geolocation_ip_distance_unit` | string | Die Einheit, in der die Konsole `geolocation_ip_distance_km` anzeigt. Dient nur der Anzeige: Der gespeicherte Wert ist immer in Kilometern angegeben und keine Regel hängt davon ab. | | `geolocation_document_distance_km` | integer | Wie weit die Position (der IP-Standort bei einem `ip_only`-Knoten) in Kilometern von der durch `geolocation_document_distance_basis` angegebenen Adresse entfernt sein darf, bevor `geolocation_document_distance_action` angewendet wird. Nicht gesetzt oder null (Standard) ist deaktiviert. | | `geolocation_document_distance_unit` | string | Die Einheit, in der die Konsole `geolocation_document_distance_km` anzeigt. Dient nur der Anzeige: Der gespeicherte Wert ist immer in Kilometern angegeben und keine Regel hängt davon ab. | | `geolocation_document_distance_basis` | string | Von welcher Adresse aus `geolocation_document_distance_km` gemessen wird: `document` (Standard: die Adresse des Ausweisdokuments, dann der Adressnachweis), nur `proof_of_address` oder `declared` (die bei der Sitzungserstellung angegebene, geocodierte `expected_details.address`). | | `geolocation_travel_tolerance_enabled` | boolean | Die Entfernung zur Adresse wird nicht berücksichtigt, wenn dieselbe Person (gleiche `vendor_data`) innerhalb der letzten `geolocation_travel_max_days` Tage im Umkreis von `geolocation_travel_usual_area_km` darum registriert wurde. Sieht niemals über ein VPN, eine per Spoofing manipulierte Position, einen gesperrten Bereich oder den Aufenthalt außerhalb der zulässigen Bereiche hinweg. Nur eine vom Gerät gemessene Position zählt als dort registriert: Ein manipulierter oder simulierter Standortfix, ein Emulator oder eine fehlgeschlagene Attestierung zählen niemals. | | `geolocation_travel_usual_area_km` | integer | Radius um die Adresse, der als gewohnter Bereich der Person gilt. Von 10 bis 500 km; 100, wenn nicht festgelegt. | | `geolocation_travel_max_days` | integer | Wie lange nach dem Erfassen im gewohnten Bereich eine entfernte Position noch als Reise gilt. Von 1 bis 90 Tage; 14, wenn nicht festgelegt. | | `geolocation_consecutive_mismatch_count` | integer | Löst LOCATION\_CONSECUTIVE\_MISMATCHES aus, wenn diese Prüfung und vorherige Prüfungen derselben Person (gleiche `vendor_data`) so oft in Folge außerhalb der zulässigen Bereiche, in einem gesperrten Bereich oder zu weit von der Adresse entfernt lagen. Eine Prüfung, bei der nichts verglichen wurde, verlängert oder unterbricht die Serie nicht; dasselbe gilt für eine Position, die nicht vom Gerät gemessen wurde (ein manipulierter oder simulierter Standortfix, ein Emulator, eine fehlgeschlagene Attestierung). Von 2 bis 10; null (Standard) ist deaktiviert. | | `geolocation_approximate_action` | action | Entscheidung, wenn der Benutzer einen ungefähren Standort freigegeben hat, während `geolocation_accuracy_mode` einen präzisen anfordert. Standardmäßig `REVIEW`. | | `geolocation_blocked_area_action` | action | Entscheidung, wenn die Position und ihr gesamter Genauigkeitskreis innerhalb eines gesperrten Bereichs von `geolocation_areas` liegen. Standardmäßig Decline. | | `geolocation_consecutive_mismatch_action` | Aktion | Entscheidung, wenn die Anzahl der aufeinanderfolgenden Nichtübereinstimmungen `geolocation_consecutive_mismatch_count` erreicht. Standardmäßig Prüfung. | | `geolocation_document_distance_action` | Aktion | Entscheidung, wenn die Geräteposition weiter von der Dokumentadresse entfernt ist als `geolocation_document_distance_km`. Die Adresse wird grob geocodiert, daher ist dies ein schwaches Signal. Standardmäßig `REVIEW`. | | `geolocation_emulator_action` | Aktion | Entscheidung, wenn die App, die den Standort übermittelt hat, gemeldet hat, dass sie auf einem Emulator ausgeführt wird. Browser können dies nicht melden. Sofern nicht Keine Aktion festgelegt ist, beendet dies den Schritt bei diesem Versuch: Eine erneute Prüfung kann das Gerät nicht ändern. Keine Aktion, sofern nicht festgelegt oder durch eine Voreinstellung anders vorgegeben. | | `geolocation_geofence_undetermined_action` | Aktion | Entscheidung, wenn die Position nicht innerhalb oder außerhalb des Geofence bestimmt werden kann, da ihr Unsicherheitskreis die Begrenzung berührt. Unsicherheit wird niemals so gewertet, als befände sich die Position außerhalb. Standardmäßig `REVIEW`. | | `geolocation_geofencing_action` | Aktion | Entscheidung, wenn die Geräteposition und ihr gesamter Unsicherheitskreis außerhalb von `geolocation_geofencing_by_country` liegen. Standardmäßig `DECLINE`. | | `geolocation_integrity_missing_action` | Aktion | Entscheidung, wenn ein nativer Client eine Position ohne Geräte-Attestierungs-Token übermittelt hat. Standardmäßig Keine Aktion; Web-Clients werden als nicht unterstützt statt als fehlend erfasst, da kein Browser eine Attestierung durchführen kann. | | `geolocation_ip_distance_action` | Aktion | Entscheidung, wenn die Geräteposition und der IP-Standort der Sitzung nach Abzug beider Ungenauigkeitsradien weiter voneinander entfernt sind als `geolocation_ip_distance_km`. Standardmäßig `REVIEW`. | | `geolocation_low_accuracy_action` | Aktion | Entscheidung, wenn bei keinem Versuch die erforderliche Genauigkeit erreicht wurde: Die beste Position hat einen Ungenauigkeitsradius, der größer als `geolocation_max_accuracy_radius_m` ist, oder es wurde überhaupt kein Radius gemeldet. Eine Position ohne Radius wird niemals so gewertet, als erfülle sie das Limit. Standardmäßig `REVIEW`. | | `geolocation_mock_location_action` | Aktion | Entscheidung, wenn das Betriebssystem gemeldet hat, dass die Position simuliert statt gemessen wurde (Android-Mock-Provider, iOS-durch-Software-simuliert). Standardmäßig `REVIEW`. | | `geolocation_permission_denied_action` | Aktion | Entscheidung, wenn der Benutzer die Standortabfrage bei jedem zulässigen Versuch abgelehnt oder geschlossen hat. Standardmäßig Prüfung: Eine Ablehnung ist eine Entscheidung, kein Betrugssignal. | | `geolocation_proxy_action` | Aktion | Entscheidung, wenn die Verbindung, die den Standort übermittelt hat, über einen offenen, anonymen oder Private-Relay-Proxy läuft. Keine Aktion, sofern nicht festgelegt oder durch eine Voreinstellung anders vorgegeben. | | `geolocation_stale_fix_action` | Aktion | Entscheidung, wenn die Position mehr als `geolocation_max_age_seconds` vor dem Eintreffen auf dem Server gemessen wurde. Standardmäßig `REVIEW`. | | `geolocation_tor_action` | Aktion | Entscheidung, wenn die Verbindung, die den Standort übermittelt hat, ein Tor-Exit-Knoten ist. Keine Aktion, sofern nicht festgelegt oder durch eine Voreinstellung anders vorgegeben. | | `geolocation_unavailable_action` | Aktion | Entscheidung, wenn keine Position ermittelt werden konnte – Standortdienste deaktiviert oder eingeschränkt, das Positionierungssystem lieferte kein Ergebnis, das Zeitlimit des Versuchs wurde überschritten, der Benutzer hat den Schritt übersprungen oder der Client ist zu alt, um dies zu unterstützen. Standardmäßig `REVIEW`. | | `geolocation_vpn_action` | Aktion | Entscheidung, wenn die Verbindung, die den Standort übermittelt hat, ein kommerzielles VPN ist. Sofern nicht Keine Aktion festgelegt ist, wird die Person aufgefordert, es zu deaktivieren und die Prüfung erneut durchzuführen, solange Versuche verbleiben. Keine Aktion, sofern nicht festgelegt oder durch eine Voreinstellung anders vorgegeben. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. Sie können auf die `geolocation.*`-Felder abzielen, die unter [Standortverifizierungsbericht](https://docs.didit.me/de/core-technology/location-verification/report-location-verification.md#felder-für-statusregeln-und-verzweigungen) aufgeführt sind. | ### Gebietsformen Jedes Element von `geolocation_areas` besitzt eine `id` (1 bis 64 Zeichen aus `A-Z a-z 0-9 _ -`, eindeutig in der Liste), ein optionales `label` (bis zu 80 Zeichen), ein `type`-Feld mit dem Wert `allowed` oder `blocked` und ein `kind`-Feld, das die Form bestimmt. | `kind` | Zusätzliche Felder | Bedeutung | | - | - | - | | `country` | `country` (ISO 3166-1 alpha-3) | Ein ganzes Land, für das veröffentlichte Umrisse vorliegen. | | `region` | `country`, `regions` (ISO 3166-2-Codes dieses Landes) | Eine oder mehrere Unterteilungen eines Landes mit veröffentlichten Grenzen. | | `circle` | `center` (`latitude`, `longitude`), `radius_km` (1 bis 500) | Jeder Punkt innerhalb des Radius um das Zentrum. | | `polygon` | `points` (3 bis 200 Elemente aus `latitude`, `longitude`) | Ein geschlossener Ring, dessen Kanten sich weder kreuzen noch berühren. | Eine Liste umfasst maximal 50 Gebiete und erfordert mindestens ein `allowed`-Gebiet, wenn `is_geolocation_geofencing_enabled` den Wert `true` hat. `geolocation_areas` und `geolocation_geofencing_by_country` können nicht zusammen übermittelt werden, und `geolocation_refusal_path: "end_session"` erfordert, dass `geolocation_permission_denied_action` auf `REVIEW` oder `DECLINE` gesetzt ist. Die API lehnt ein Gebiet ab, das niemals übereinstimmen könnte, wie etwa eine Region eines Landes ohne veröffentlichte Grenzen, anstatt es zu speichern. Beispiel: ```json theme={null} { "feature": "GEOLOCATION", "config": { "geolocation_position_source": "device_and_ip", "geolocation_preset": "licensing", "geolocation_max_accuracy_radius_m": 250, "geolocation_max_attempts": 3, "is_geolocation_geofencing_enabled": true, "geolocation_areas": [ { "id": "spain", "label": "Spain", "type": "allowed", "kind": "country", "country": "ESP" }, { "id": "ceuta-melilla", "type": "blocked", "kind": "region", "country": "ESP", "regions": ["ES-CE", "ES-ML"] } ], "geolocation_ip_distance_km": 200, "geolocation_ip_distance_action": "REVIEW", "geolocation_vpn_action": "DECLINE" } } ``` ## Adressnachweis Feature-Wert: `PROOF_OF_ADDRESS`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `poa_documents_allowed` | object | ISO3-Ländercode zur POA-Dokumenttyp-Konfiguration. Mindestens ein gültiger Dokumenttyp sollte aktiviert sein. | | `poa_languages_allowed` | object | ISO-639-1-Sprachcode zu `0` oder `1`. Mindestens eine Sprache sollte aktiviert sein. | | `poa_name_or_address_mismatch_action` | action | Aktion, wenn der Name oder die Adresse nicht mit den erwarteten Daten übereinstimmt. | | `poa_document_issues_action` | action | Aktion, wenn das Dokument Qualitäts- oder Extraktionsprobleme aufweist. | | `poa_max_attempts_exceeded_action` | restricted action | Aktion, wenn der Benutzer die Wiederholungsversuche überschreitet. Verwenden Sie `DECLINE` oder `REVIEW`. | | `poa_document_authenticity_action` | restricted action | Aktion, wenn Echtheitsprüfungen fehlschlagen. Verwenden Sie `DECLINE` oder `REVIEW`. | | `poa_document_unproven_text_replacement_action` | action | Aktion, wenn ein Textfeld geleert und in einer anderen Schriftart neu eingegeben wurde und die Datei keinen Nachweis darüber enthält, ob ihr Inhalt geändert wurde (`POA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT`). | | `poa_unsupported_document_type_action` | action | Aktion, wenn der Dokumenttyp nicht unterstützt wird. | | `poa_unsupported_language_action` | action | Aktion, wenn die Dokumentsprache nicht unterstützt wird. | | `poa_issuer_not_identified_action` | action | Aktion, wenn der Dokumentaussteller nicht identifiziert werden kann. | | `poa_issue_date_not_detected_action` | action | Aktion, wenn das Ausstellungsdatum fehlt. | | `poa_unparsable_or_invalid_address_action` | action | Aktion, wenn die Adresse ungültig ist oder nicht geparst werden kann. | | `address_validation_enabled` | boolean | Validiert die von diesem Schritt ausgelesene Adresse (auf dem Adressnachweis gedruckt; nur ein Upload, der die Dokumentprüfungen bestanden hat, wird validiert) anhand von postalischen Referenzdaten: Es bestätigt, dass die Adresse existiert, und normalisiert sie, verknüpft sie jedoch niemals mit einer Person. Das Ergebnis ist das `address_validation`-Objekt des Schritts in der Entscheidung. **Kosten: \$0.10 pro validierter Adresse**; eine Validierung, die nicht ausgeführt werden konnte (`unavailable`), ist kostenlos. Standardmäßig deaktiviert. | | `address_not_verified_action` | action | Aktion, wenn die Adressvalidierung die Adresse nicht bis zum Gebäude bestätigen konnte (`ADDRESS_NOT_VERIFIED`: `partially_verified` oder `not_verified`). Gilt nur, wenn `address_validation_enabled` aktiviert ist. Der Standardwert ist `NO_ACTION`, wodurch lediglich die Warnung erfasst wird. | | `poa_name_match_score_threshold` | integer | Schwellenwert für die Namensübereinstimmung. | | `poa_max_retry_attempts` | integer | Wiederholungslimit, `2` bis `5`. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | ## Fragebögen Feature-Wert: `QUESTIONNAIRE`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `questionnaire_uuid` | UUID | Erforderlich. Verwenden Sie die von `POST /v3/questionnaires/` zurückgegebene `questionnaire_id`. | | `review_questionnaire_manually` | boolean | Sendet Fragebogenantworten zur manuellen Prüfung. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. Sie können `questionnaire.answers.`-Felder ansteuern. | ## KYB-Register Feature-Wert: `KYB_REGISTRY`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `kyb_accepted_countries` | object | Veraltete ISO3-Länder-Allowlist für die Unternehmensregister-Abfrage. Abgelöst durch `kyb_registry_countries_config`; weiterhin lesbar, für bestehende Workflows weiterhin daraus abgeleitet, jedoch nicht mehr zur Konfiguration neuer Workflows vorgesehen. | | `kyb_manual_company_action` | action | Aktion, wenn das Unternehmen eine manuelle Bearbeitung erfordert. | | `kyb_registry_fields_config` | object | Sichtbarkeit und Pflichtfeldstatus pro Feld für das Registerformular im gehosteten Ablauf. Siehe unten. | | `kyb_registry_countries_config` | object | Länderspezifisches Register-Routing als `{"": {"enabled": bool, "tier": "basic" \| "shareholders" \| "ubo"}}`. Jedes aktivierte Land wählt die Datenstufe aus, die abgerechnet wird, wenn ein Unternehmen ausgewählt wird (`basic` entspricht der Lite-Stufe), und es können nur Stufen aktiviert werden, die der [Preise-Endpoint](https://docs.didit.me/de/getting-started/kyb-registry-pricing.md) für dieses Land als verfügbar markiert. Mindestens ein Land muss aktiviert sein: Eine Registerprüfung, die nirgendwo sucht, wird abgelehnt. Manuell eingegebene Unternehmen werden separat abgerechnet und verwenden diese Konfiguration nicht. | | `kyb_registry_monitoring_enabled` | boolean | Hält den Registerdatensatz des Unternehmens nach einem Shareholders- oder UBO-Ergebnis unter fortlaufender Überwachung: Eine Änderung des Status, der Organmitglieder, der Eigentümerstruktur oder der Adresse versetzt die Sitzung zurück in Prüfung und löst einen Webhook aus. Nur verfügbar, wenn der Registeranbieter eine Überwachung anbietet. USD 2.00 pro Unternehmen pro Jahr, jederzeit kündbar. Standardmäßig deaktiviert. | | `kyb_vat_invalid_action` | action | Aktion, wenn die USt-IdNr. des Unternehmens die EU-VIES-Validierung nicht besteht. Der Standardwert ist `REVIEW`. | | `kyb_vat_unverified_action` | action | Aktion, wenn die USt-IdNr. nicht validiert werden konnte, weil VIES nicht verfügbar war. Der Standardwert ist `NO_ACTION`. | | `status_rules` | array | Optionale benutzerdefinierte Statusregeln. | `kyb_registry_fields_config` ordnet jeden konfigurierbaren Feldschlüssel `{"enabled": bool, "required": bool}` zu. `enabled: false` blendet das Feld aus, `enabled: true, required: false` zeigt es als optional an und `enabled: true, required: true` macht es beim Absenden zum Pflichtfeld. `company_name`, `country_code` und `region` werden immer angezeigt, sind Pflichtfelder und können nicht konfiguriert werden. Wenn das Objekt weggelassen wird, `null` oder `{}` ist, gilt der Standard: Nur `incorporation_date` ist erforderlich und jedes andere Feld ist optional. ```json theme={null} { "kyb_registry_fields_config": { "registration_number": { "enabled": true, "required": true }, "incorporation_date": { "enabled": true, "required": true }, "vat_number": { "enabled": true, "required": false }, "control_scheme": { "enabled": false, "required": false } } } ``` Konfigurierbare Feldschlüssel: `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`. Siehe [konfigurierbare Registerformularfelder](https://docs.didit.me/de/business-verification/company-data.md#konfigurierbare-felder-des-registrierungsformulars) für das Verhalten für Endbenutzer und [Validierung von USt-IdNr. und Steuernummer](https://docs.didit.me/de/business-verification/company-data.md#umsatzsteuer-id--und-steuernummernprüfung) dafür, wie `vat_number` und `tax_number` geprüft werden. ## KYB-Dokumente Funktionswert: `KYB_DOCUMENTS`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `kyb_required_document_groups` | Objekt oder Array | Erforderlich. Erforderliche KYB-Dokumentengruppen. | | `kyb_document_subtype_config` | Objekt | Aktivierung und Alterskonfiguration pro Dokumenten-Subtyp. | | `kyb_document_tampering_action` | eingeschränkte Aktion | Aktion, wenn eine Manipulation erkannt wird. Verwenden Sie `DECLINE` oder `REVIEW`. | | `kyb_document_unproven_text_replacement_action` | Aktion | Aktion, wenn ein Textfeld eines Unternehmensdokuments gelöscht und in einer anderen Schriftart neu eingegeben wurde und die Datei keinen Nachweis darüber enthält, ob der Inhalt geändert wurde (`KYB_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT`). | | `kyb_document_critical_mismatch_action` | eingeschränkte Aktion | Aktion bei kritischen Dokumenten-Diskrepanzen. Verwenden Sie `DECLINE` oder `REVIEW`. | | `kyb_document_non_critical_mismatch_action` | Aktion | Aktion bei unkritischen Dokumenten-Diskrepanzen. | | `kyb_document_age_action` | Aktion | Aktion, wenn Regeln zum Dokumentenalter fehlschlagen. | | `kyb_document_max_retry_attempts` | Integer | Limit für Wiederholungsversuche bei KYB-Dokumenten. | | `kyb_document_max_attempts_exceeded_action` | eingeschränkte Aktion | Aktion, wenn die maximale Anzahl an Versuchen überschritten wird. Verwenden Sie `DECLINE` oder `REVIEW`. | | `status_rules` | Array | Optionale benutzerdefinierte Statusregeln. | ## KYB-Schlüsselpersonen Funktionswert: `KYB_KEY_PEOPLE`. | Konfigurationsfeld | Typ | Beschreibung | | - | - | - | | `kyb_ubo_ownership_threshold` | Integer | UBO-Eigentumsschwellenwert, `0` bis `100`. | | `kyb_shareholder_ownership_threshold` | Integer | Gesellschafter-Eigentumsschwellenwert, `0` bis `100`. Er darf nicht höher sein als `kyb_ubo_ownership_threshold`. | | `kyb_key_people_ownership_required` | Boolean | Erfordert die Angabe eines Eigentumsanteils in Prozent für jede übermittelte Schlüsselperson. Wird bei der Übermittlung durchgesetzt und auf der gehosteten UI angezeigt, die das Feld als erforderlich markiert. Standardmäßig `false`. | | `kyb_require_ubo_kyc` | Boolean | Erfordert, dass UBOs einen Workflow zur Personenverifizierung abschließen. | | `kyb_ubo_verification_workflow` | UUID | Erforderlich, wenn `kyb_require_ubo_kyc` auf `true` gesetzt ist. Muss auf einen Nicht-KYB-Workflow in derselben Anwendung verweisen. | | `kyb_require_officer_kyc` | Boolean | Erfordert, dass Organmitglieder eine Personenverifizierung abschließen. | | `kyb_shareholder_verification_workflow` | UUID | Workflow zur Personenverifizierung für Gesellschafter. | | `kyb_officer_verification_workflow` | UUID | Workflow zur Personenverifizierung für Organmitglieder. | | `kyb_require_corporate_ubo_kyb` | Boolean | Erfordert, dass juristische UBOs KYB abschließen. | | `kyb_corporate_ubo_verification_workflow` | UUID | Erforderlich, wenn `kyb_require_corporate_ubo_kyb` auf `true` gesetzt ist. Muss auf einen KYB-Workflow in derselben Anwendung verweisen. | | `kyb_reject_if_ubo_rejected` | Boolean | Lehnt das Unternehmen ab, wenn eine erforderliche UBO-Verifizierung abgelehnt wird. | | `kyb_wait_for_all_ubos` | Boolean | Wartet auf alle erforderlichen UBO-Verifizierungen, bevor über die KYB-Sitzung entschieden wird. | | `kyb_role_config` | Objekt oder Array | Konfiguration pro Rolle. Jede erforderliche KYC-Rolle muss einen `verification_workflow` enthalten. | | `kyb_reuse_verified_individuals` | Boolean | Verwendet bereits verifizierte Personen wieder, sofern möglich. | | `kyb_notify_parties_by_email` | Boolean | Sendet E-Mail-Benachrichtigungen an eingeladene Schlüsselpersonen. | | `kyb_key_people_company_fields` | Objekt | Welche Unternehmensdaten für eine juristische Person als Schlüsselperson (CORPORATE) erfasst werden. Dieselbe Struktur einer Liste von Deskriptoren und dieselben Regeln wie bei `kyb_key_people_person_fields`. Format: `[{"key": "", "label": "