Datenbankvalidierung: Warnungen und Skip-Codes

Didits Funktion Datenbankvalidierung gleicht Identitätsdaten mit maßgeblichen Personenstandsregistern ab – RENAPER (Argentinien), Receita Federal (Brasilien), Tribunal Electoral (Panama, biometrisch), Junta Central Electoral (Dominikanische Republik) und weiteren – abgerechnet pro erfolgreicher Abfrage ohne monatliche Mindestgebühren. Wenn kein Dienst ausgeführt werden kann (erforderliche Felder fehlen oder sind fehlerhaft, Register nicht verfügbar), das Dokument selbst nicht geprüft werden kann (es enthält nicht die Kennung, die die konfigurierten Dienste benötigen – z. B. ein Reisepass ohne nationale ID-Nummer) oder das Gesamtergebnis nicht eindeutig ist (teilweise Übereinstimmung, keine Übereinstimmung), gibt die Funktion eine Warnung für die Sitzung aus. Wenn das Ausstellungsland im Workflow überhaupt nicht aktiviert ist, wird der Schritt stillschweigend ohne Warnung und ohne Berechnung übersprungen. Diese Seite dokumentiert jeden Warnungscode, was ihn auslöst und wie die Workflow-Reaktion konfiguriert wird.

Übersicht

Warnungen werden sowohl in Workflow-Sitzungen als auch von der eigenständigen API (POST /v3/database-validation/) generiert. Alle fünf Risiken sind mit der Funktion DATABASE_VALIDATION gekennzeichnet, erscheinen im Bericht unter database_validations[].warnings[] und folgen der standardmäßigen Struktur des Warnungsobjekts (feature, risk, additional_data, log_type, short_description, long_description, node_id). Es gibt keine festen automatischen Ablehnungsauslöser für die Datenbankvalidierung. Die beiden Übereinstimmungsergebnis-Risiken, das Risiko für abgelöste Dokumente und das Risiko „Nicht anwendbar“ sind einer konfigurierbaren Aktion (DECLINE, REVIEW oder NO_ACTION) zugeordnet; COULD_NOT_PERFORM_DATABASE_VALIDATION ist das einzige feste Verhalten – es setzt die Funktion immer auf in Prüfung.

Konfigurierbare Risiken

Einstellung	Risiko-Code	Verhalten
Aktion bei keiner Übereinstimmung	`DATABASE_VALIDATION_NO_MATCH`	`REVIEW` (Workflow-Standard) setzt die Funktion auf in Prüfung; `DECLINE` lehnt ab; `NO_ACTION` erfasst die Warnung, ohne den Status zu beeinflussen. Der Parameter `no_match_action` der eigenständigen API verwendet stattdessen standardmäßig `DECLINE`.
Aktion bei teilweiser Übereinstimmung	`DATABASE_VALIDATION_PARTIAL_MATCH`	`NO_ACTION` (Standard) erfasst die Warnung, ohne den Status zu beeinflussen; `REVIEW` setzt die Funktion auf in Prüfung; `DECLINE` lehnt ab.
Aktion bei keiner Übereinstimmung	`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Teilt sich die Einstellung Aktion bei keiner Übereinstimmung – es gibt keinen separaten Schalter. Das Register widersprach den übermittelten Daten, sodass eine Organisation, die bei Nicht-Übereinstimmung ablehnt, auch bei einem veralteten Nachweis ablehnt.
Aktion bei Nichtanwendbarkeit	`DATABASE_VALIDATION_NOT_APPLICABLE`	`NO_ACTION` (Standard) erfasst die Warnung, ohne den Status zu beeinflussen; `REVIEW` setzt die Funktion auf in Prüfung; `DECLINE` lehnt ab. Wird ausgelöst, wenn das Dokument überhaupt nicht geprüft werden kann – es enthält nicht die Kennung, mit der die konfigurierten Dienste die Abfrage durchführen (z. B. ein Reisepass ohne nationale ID-Nummer).

Die konfigurierte Aktion steuert auch den log_type der Warnung: DECLINE → error, REVIEW → warning, NO_ACTION → information. Das Übereinstimmungsergebnis selbst wird aus den validation-Einträgen pro Dienst aggregiert (mindestens eine vollständige Übereinstimmung → full_match; andernfalls mindestens eine teilweise → partial_match; andernfalls no_match) – siehe Abgleichsmethoden für die vollständige Entscheidungslogik, die 1×1- / 2×2-Ergebnisse ableitet.

Erzeugte Warnungen

Tag	Kurzbeschreibung	Beschreibung
`COULD_NOT_PERFORM_DATABASE_VALIDATION`	Datenbankvalidierung konnte nicht durchgeführt werden	Kein Dienst hat ein verwertbares Ergebnis zurückgegeben (`match_type` bleibt `null`) – typischerweise, weil erforderliche Felder fehlen oder fehlerhaft formatiert sind oder das Register einen Fehler zurückgegeben hat. `additional_data` enthält die Zusammenfassung der Übersprünge pro Dienst (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); die eigenständige API verwendet stattdessen `{ "validation_errors": [...] }`. Ihnen werden keine Kosten berechnet, wenn diese Warnung ausgelöst wird; die Funktion wechselt auf In Prüfung, bis die Daten korrigiert sind.
`DATABASE_VALIDATION_NOT_APPLICABLE`	Datenbankvalidierung für dieses Dokument nicht anwendbar	Das vorgelegte Dokument enthält nicht die Kennung, die die konfigurierten Datenbankdienste erfordern (`match_type` bleibt `null`) – beispielsweise enthält ein brasilianischer Reisepass keine CPF, sodass das CPF-Register nicht abgefragt werden kann. Dies wird für den Dokumenttyp erwartet und weist nicht auf ein Problem mit dem Dokument hin. `additional_data` enthält die Zusammenfassung der Übersprünge pro Dienst. Ihnen werden keine Kosten berechnet, wenn diese Warnung ausgelöst wird. Aktion konfigurierbar (Standardwert `NO_ACTION`).
`DATABASE_VALIDATION_PARTIAL_MATCH`	Teilweise Übereinstimmung bei Datenbankvalidierung	Der aggregierte `match_type` ist `partial_match` – einige überprüfte Felder stimmten mit dem Register überein, aber nicht alle. Aktion konfigurierbar (Standardwert `NO_ACTION`).
`DATABASE_VALIDATION_NO_MATCH`	Keine Übereinstimmung bei Datenbankvalidierung	Der aggregierte `match_type` ist `no_match` – das Register konnte die geprüfte Identität nicht bestätigen. Aktion konfigurierbar (Standardwert `REVIEW` in Workflows, `DECLINE` in der eigenständigen API).
`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Ersetzte Dokumentversion	Ein Dienst hat `DOCUMENT_SUPERSEDED` zurückgegeben: Das Register hat die Person bestätigt, aber die vorgelegte Version des Dokuments ist nicht die hinterlegte – inzwischen wurde eine neuere Version ausgestellt. Wird unabhängig von `match_type` ausgelöst, der auf `full_match` bleibt, da jedes persönliche Feld übereinstimmte, sodass der Befund andernfalls unsichtbar bliebe. `additional_data` benennt die Dienste, die dies gemeldet haben. Folgt der Einstellung No Match Action.

COULD_NOT_PERFORM_DATABASE_VALIDATION deckt zwei verschiedene Situationen ab, und die long_description der Warnung (sowie bei einem dienstspezifischen Fehler database_validation_errors[].message) gibt nun an, welche Situation zutraf, anstatt einen einzelnen generischen Satz zu verwenden: Die geprüften Daten fehlten oder waren fehlerhaft formatiert, bevor ein Dienst abgefragt werden konnte, oder ein Dienst wurde abgefragt und lieferte kein verwertbares Ergebnis. Im zweiten Fall gilt: Wenn das Register für diesen Versuch eigene Diagnosedetails gemeldet hat, sind diese Details in der Nachricht enthalten, sodass Sie sich nicht an den Support wenden müssen, um den Grund zu erfahren. Der vorgeschaltete Dienst wird in der Antwort niemals namentlich genannt.

Wenn COULD_NOT_PERFORM_DATABASE_VALIDATION oder DATABASE_VALIDATION_NOT_APPLICABLE in einer Workflow-Sitzung ausgelöst wird, wird die Prüfung automatisch erneut angestoßen, sobald die fehlenden Daten auf der Sitzungsdetailseite in der Konsole ausgefüllt werden – das Speichern des Feldes führt die Validierung erneut aus, und die Warnung wird bei Erfolg entfernt. Dies funktioniert auch, wenn die Aktion für „nicht anwendbar“ die Sitzung abgelehnt hat, sodass eine abgelehnte Sitzung durch Korrektur der Daten behoben werden kann. Bei DATABASE_VALIDATION_NOT_APPLICABLE hilft die erneute Ausführung, wenn das Dokument die Kennung enthalten kann, diese jedoch nicht gelesen wurde (beispielsweise ein Aufenthaltstitel, dessen nationale Ausweisnummer nicht extrahiert wurde); bei Dokumenttypen, die die Kennung grundsätzlich nicht enthalten (beispielsweise Reisepässe ohne nationale Ausweisnummer), bleibt die Warnung bestehen. Keine Kosten fallen für übersprungene Dienste an; Sie zahlen nur, wenn ein Dienst ein abrechenbares Ergebnis liefert.

Beispiel

{
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "DATABASE_VALIDATION_NO_MATCH",
      "additional_data": null,
      "log_type": "warning",
      "short_description": "Database validation no match",
      "long_description": "The system identified a no match in the database validation, requiring further investigation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}

Warnungstypen

Jedem Risiko wird basierend auf der Konfiguration Ihrer Anwendung ein Schweregrad zugewiesen. Die Schweregrade fallen in drei Kategorien:

Authentifizierung

Verifizierung

Überwachung

Plattform

Datenbankvalidierung: Warnungen und Skip-Codes

Übersicht

Konfigurierbare Risiken

Erzeugte Warnungen

Beispiel

Warnungstypen

Verwandte Themen

​Übersicht

​Konfigurierbare Risiken

​Erzeugte Warnungen

​Beispiel

​Warnungstypen

​Verwandte Themen

Übersicht

Konfigurierbare Risiken

Erzeugte Warnungen

Beispiel

Warnungstypen

Verwandte Themen