Zum Hauptinhalt springen
Didits Datenbankvalidierung verifiziert die Identitätsdaten einer Person anhand der maßgeblichen Quelle für das jeweilige Land — dem nationalen Personenstandsregister, der Steuerbehörde, dem Wählerverzeichnis, der Wirtschaftsauskunftei oder dem biometrischen Register, bei der bzw. dem das Dokument ursprünglich ausgestellt wurde. Jede Prüfung liefert einen feldweisen Abgleich (identification_number, first_name, last_name, date_of_birth und Adressfelder, sofern der Dienst diese verwendet) sowie ein aggregiertes Ergebnis und die zugrunde liegenden Datensatzdetails, sofern verfügbar. Sie ist der stärkste Schutz gegen Betrug durch synthetische Identitäten: Eine gestohlene echte DNI oder CPF scheitert bei der Registerabfrage, und eine frei erfundene Nummer ist in der offiziellen Datenbank überhaupt nicht vorhanden. Die Datenbankvalidierung lässt sich mit unserem biometrischen Gesichtsabgleich in Ländern kombinieren, in denen das Register ein offizielles Foto bereithält (Argentinien über RENAPER, Panama über Tribunal Electoral SIB / SIB Plus). So können Sie nicht nur bestätigen, dass eine Nummer echt ist, sondern auch, dass die Person vor der Kamera Inhaberin dieser Nummer ist.

​
Warum Didit

  • Günstigste Preise pro Aufruf. Ab $0.05 pro Prüfung (Dominikanische Republik) bis zu $7.00 für die teuersten Spezialquellen. Der Preis wird pro Dienst festgelegt, nicht pro Land — ein Register, das eine hohe Großhandelsgebühr verlangt, wird entsprechend bepreist (finnische National-ID liegt bei $2.10). Entnehmen Sie den Tarif für den genauen Dienst, den Sie aufrufen möchten, stets der Preistabelle pro Dienst. Keine monatlichen Mindestabnahmen, keine Plattformgebühren, keine Abrechnung nach Seats — berechnet werden nur erfolgreiche Anfragen.
  • Am schnellsten zu integrieren. Registrieren Sie sich, holen Sie sich einen API-Schlüssel aus der Konsole, und Sie können POST /v3/database-validation/ innerhalb weniger Minuten aufrufen. Kein Verkaufsgespräch, kein Beschaffungsprozess, kein Papierkram für einen Machbarkeitsnachweis — Didit ist vollständig Self-Service.
  • Direkte Treffer bei der maßgeblichen Quelle. RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — kein Scraping durch Aggregatoren.
  • Biometrischer Gesichtsabgleich, wo das Register ein offizielles Foto gespeichert hat. Höherer Konfidenzwert als bei OCR ohne zusätzlichen Integrationsaufwand.
  • Produktionsreife Latenz. p95 typischerweise unter 1.5 s durchgehend, eine vierteljährliche Verfügbarkeit von 99.9%.
Die Academy-Lektion zum Lesen eines Verifizierungsergebnisses behandelt die Datenbankvalidierung ab 11:05 und zeigt vollständige, teilweise und nicht übereinstimmende Abgleichergebnisse.

​
Globale Abdeckung

Fahren Sie mit der Maus über ein hervorgehobenes Land, um alle dort verfügbaren Datenbankvalidierungsdienste, die Datendomäne (Identität, Finanzen, Biometrie, Adresse, Telekommunikation, …) und den Preis pro Aufruf anzuzeigen. Aktive Länder sind heute produktionsreif; die übrigen werden bei Bedarf auf Kundenanfrage angebunden.
Ihr Land ist nicht dabei? Sprechen Sie uns an — unser Katalog umfasst 60+ Länder mit Hunderten von Diensten, die wir bei Bedarf aktivieren, sobald ein Kunde sie benötigt. Neue Integrationen gehen in der Regel innerhalb von 2–3 Wochen live.

​
Wie eine Datenbankvalidierung abläuft

Eine Datenbankvalidierung wird niemals spekulativ ausgelöst. Sie wird nur ausgeführt, wenn alle der folgenden Punkte zutreffen:
  1. Für die Sitzung wurde ein abzufragendes Land ermittelt – anhand des issuing_state einer Ausweisverifizierung oder, wenn der Workflow keinen Schritt zur Ausweisverifizierung enthält, anhand des einzelnen Landes, für das der Schritt zur Datenbankvalidierung konfiguriert ist.
  2. Für dieses Land ist mindestens ein Datenbankvalidierungsdienst im Workflow aktiviert.
  3. Die Schritte vor dem Schritt zur Datenbankvalidierung haben jedes erforderliche Feld geliefert, das der ausgewählte Dienst benötigt.
Wenn ein Dienst aktiviert ist, die erforderlichen Felder jedoch nie übermittelt wurden (z. B. wenn die CPF aus einer verschmierten brasilianischen RG nicht extrahiert werden konnte), wird der Dienst übersprungen, Ihnen wird nichts in Rechnung gestellt und für die Sitzung wird eine Warnung ausgelöst: DATABASE_VALIDATION_NOT_APPLICABLE, wenn das Dokument die Kennung, nach der dieser Dienst abfragt, schlicht nicht enthält; COULD_NOT_PERFORM_DATABASE_VALIDATION, wenn sie hätte verfügbar sein sollen, dies aber nicht der Fall war. Beide sind im Warnungskatalog aufgeführt. Jemand in Ihrem Team mit Prüfungszugriff auf die Sitzung kann das fehlende Feld dann auf der Sitzungsdetailseite in der Console manuell ausfüllen; beim Speichern wird die Prüfung automatisch erneut ausgelöst. Dies ist eine Aktion für Prüfer, nichts, was der Endbenutzer tun kann – um dem Benutzer die Eingabe eines Feldes zu ermöglichen, das sein Dokument nicht enthält, fragen Sie es in einem Fragebogen (oder einer Document AI-Extraktion bzw. einem Wert, den Sie beim Erstellen der Sitzung übermitteln) ab und ordnen Sie es im Schritt zur Datenbankvalidierung wie unten beschrieben zu.

​
Datenbankvalidierung erfordert keine Ausweisverifizierung

Früher setzte ein Schritt zur Datenbankvalidierung einen vorgelagerten Schritt zur Ausweisverifizierung voraus, da die OCR eines Ausweisdokuments die einzige vorgesehene Möglichkeit war, die Daten des Endbenutzers zu erfassen. Das ist nicht mehr der Fall: Jedes erforderliche Feld deklariert, welche Schritte es liefern können, und ein Dienst wird verfügbar, sobald Ihr Workflow einen Schritt enthält, der jedes benötigte Feld bereitstellt. Das bedeutet, dass ein gesichtsbiometrischer Dienst allein auf Basis eines Liveness-Schritts ausgeführt werden kann, ohne dass sich irgendwo im Workflow ein Ausweisdokument befindet, und ein Dienst, der auf einer Steuernummer, Telefonnummer oder E-Mail basiert, kann durch eine Fragebogenantwort, einen Schritt zur Telefon-/E-Mail-Verifizierung oder eine Document AI-Extraktion erfüllt werden. Zwei Regeln sorgen für Sicherheit:
  • Ein Workflow ohne Ausweisverifizierung muss genau ein Land im Schritt zur Datenbankvalidierung konfigurieren. Ohne einen issuing_state aus einem Dokument ist dies das einzige eindeutige Signal dafür, welches nationale Register abgefragt werden soll. Daher führt eine Konfiguration für mehrere Länder ohne Ausweisverifizierung lieber gar nichts aus, anstatt zu raten.
  • Die Prüfung auf erforderliche Felder bleibt unverändert. Ein Dienst, dessen Felder zur Laufzeit nicht alle vorhanden sind, wird übersprungen, bevor ein Anbieter abgefragt wird. Ihnen wird somit niemals eine Datenbank in Rechnung gestellt, die gar nicht abgefragt wurde.

​
Zuordnung von Document AI- und Fragebogenfeldern

Extraktionsfelder von Document AI und Fragen in Fragebögen verwenden Ihre Schlüsselnamen, nicht die von Didit. Ein Schlüssel, der exakt mit einem Eingabenamen der Datenbankvalidierung übereinstimmt (tax_number, date_of_birth, phone, …), wird automatisch zugeordnet und erfordert keine Konfiguration. Für alle anderen Felder zeigt der Workflow-Editor beim Schritt zur Datenbankvalidierung eine Auswahlliste für die noch nicht ausgefüllten Felder an, in der Sie jedes Feld auf den Document AI-Feldschlüssel oder die Fragebogenantwort verweisen, die es bereitstellt. In der Console wird ein Dienst, den Ihr Workflow noch nicht ausführen kann, als deaktiviert angezeigt – zusammen mit der Begründung, welche Felder fehlen und welcher Schritt sie bereitstellen würde. Der Editor bietet Ihnen an, diesen Schritt für Sie hinzuzufügen. Sobald er hinzugefügt wurde, werden alle dadurch freigeschalteten Dienste sofort aktiviert.
Praxisbeispiel – eine Kennung, die das Dokument nicht enthält. Nigerias National-ID-Dienst fragt anhand der 11-stelligen NIN ab, die häufig nicht auf den von Personen hochgeladenen Dokumenten aufgedruckt ist. Wenn man sich also allein auf das Ausweisdokument verlässt, wird die Prüfung für einen großen Teil der Benutzer als nicht anwendbar übersprungen. Platzieren Sie einen Fragebogen-Schritt vor dem Schritt zur Datenbankvalidierung, der die NIN abfragt, und ordnen Sie national_id dann im Schritt zur Datenbankvalidierung dieser Frage zu. Dieselbe Zuordnung sorgt auch dafür, dass eine Kennung, die sich überhaupt nicht auf einem Dokument befindet – etwa eine Bankverifizierungsnummer oder eine Registernummer eines Unternehmens –, innerhalb eines Workflows verwendet werden kann.
Für adressbasierte Dienste unterteilt Didit die einzelne address des Ausweisdokuments automatisch in strukturierte Adresselemente: Beim Aufruf der eigenständigen API können Sie entweder eine einzelne address oder diese strukturierten Felder direkt übermitteln. Wenn beide vorhanden sind, haben die strukturierten Felder Vorrang. Dienste, die eine Adresssuche erfordern, benötigen address_element_1 sowie mindestens ein weiteres Adresselement. Kann Didit diese nicht aus dem Ausweisdokument oder dem Adressnachweis im Workflow ableiten, wird der Dienst übersprungen und nicht abgerechnet. Wenn das ermittelte Land überhaupt nicht aktiviert ist, wird der Schritt stillschweigend ohne Warnung und ohne Gebühren übersprungen.
Didit-Ablauf für die Datenbankvalidierung zum Abgleich von Benutzerdaten mit staatlichen Identitätsregistern

​
Das Abgleichergebnis

Jeder aktivierte Dienst gibt eine feldbezogene Validierung zurück: Der aggregierte match_type wird wie folgt zusammengefasst:
  • full_match — jedes angefragte Feld stimmt mit mindestens einer Quelle überein.
  • partial_match — teilweise Übereinstimmung; Weiterleitung an eine Prüfwarteschlange gemäß Ihren Workflow-Regeln.
  • no_match — keine Quelle hat die Daten bestätigt; in der Regel abgelehnt.

​
Wie der Abgleich abgeleitet wird (1×1 / 2×2)

Sie müssen „1×1“ oder „2×2“ nicht mehr vorab auswählen – diese Werte werden daraus abgeleitet, wie viele verschiedene Dienste eine vollständige Übereinstimmung für die Eingabedaten zurückgegeben haben:
  • 1×1-Ergebnis — ein Dienst hat eine vollständige Übereinstimmung zurückgegeben (eine einzelne maßgebliche Quelle hat die Daten bestätigt).
  • 2×2-Ergebnis — zwei oder mehr Dienste haben eine vollständige Übereinstimmung zurückgegeben (unabhängige Bestätigung; die höchste Konfidenz, die wir ausdrücken können).
Ein Workflow kann beliebig viele Dienste pro Land aktivieren; abgerechnet wird pro Dienst, der tatsächlich ein Ergebnis zurückgegeben hat. Dienste, deren erforderliche Felder nicht extrahiert werden konnten, werden ohne Berechnung übersprungen. ➡️ Siehe Abgleichmethoden für die vollständige Entscheidungslogik und wie sie mit partialMatchAction / noMatchAction zusammenwirkt.

​
Biometrische Datenbankvalidierung

Die Personenstandsregister einiger Länder stellen ein biometrisches Template bereit (ein Porträtfoto oder einen Fingerabdruck). Wenn dieses verfügbar ist, kombinieren wir die Registerabfrage mit einem biometrischen Gesichtsabgleich gegen das Selfie des Benutzers:
  • Argentinien (arg_renaper) — biometrischer Gesichtsabgleich gegen das offizielle, hinterlegte RENAPER-Foto. 100% Abdeckung der Bevölkerung; jeder argentinische Staatsbürger mit einem DNI ist in der Datenbank erfasst.
  • Panama (pan_cedula_sib, pan_cedula_sib_plus) — biometrischer Gesichtsabgleich gegen den SIB-Dienst des Tribunal Electoral. SIB Plus ist die höherwertige Variante mit strengeren biometrischen Schwellenwerten und umfangreicheren Metadaten zum Abgleich.
Für diese Dienste ist das Feld selfie erforderlich. Innerhalb eines Sitzungsablaufs verwenden wir das Liveness-Selfie wieder (höchste Qualität) und greifen andernfalls auf das Dokumentporträt zurück. Außerhalb einer Sitzung, beim Aufruf der Standalone-API (POST /v3/database-validation/, dem oben beschriebenen Modus B), übermitteln Sie das JPEG/PNG selbst.

​
Globale Identitätsanreicherung

glb_identity_enrichment ist ein globaler, reiner Standalone-Dienst für die Datenbankvalidierung. Aus einer E-Mail-Adresse und/oder einer Telefonnummer ermittelt er zugehörige Personen (Namen, Geburtsdaten, Adressen, Telefonnummern, E-Mails und nationale Ausweisnummern) und gibt einen Übereinstimmungswert für den Namen zurück, der den Standard-Ergebniscodes MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (mit dem entsprechenden match_type von full_match / partial_match / no_match) zugeordnet ist. Da es sich um einen globalen Dienst (GLB) handelt, der auf E-Mail/Telefon statt auf das Ausstellungsland eines Dokuments bezogen ist, steht er im Workflow-Builder nicht zur Verfügung. Rufen Sie ihn direkt über die Standalone-API auf, indem Sie issuing_state auf GLB setzen:
Er wird mit $0.20 pro Anfrage abgerechnet (abgerechnet wird nur, wenn der Anbieter ein Ergebnis zurückgibt).

​
Konfiguration

Die Datenbankvalidierung wird pro Workflow in der Konsole konfiguriert. Für jedes Land wählen Sie die spezifischen Dienste aus, die ausgeführt werden sollen; die erforderlichen und optionalen Eingabefelder ergeben sich aus der Vereinigung dieser Dienste. Die Aktion, die bei den Ergebnissen partial_match und no_match ausgeführt wird, wird separat konfiguriert und kann approve, review oder decline sein.
Didit-Konsole-Einstellungen für die Datenbankvalidierung zur Auswahl länderspezifischer Registerdienste und Ergebnisregeln

​
Benachrichtigungen zur Verfügbarkeit

Behördenregister und andere Quellen fallen von Zeit zu Zeit aus. Während eine Datenbank nicht erreichbar ist, liefern Prüfungen dagegen keine Antwort und werden nicht abgerechnet. Innerhalb eines Workflows wird der Dienst auf REGISTRY_UNAVAILABLE aufgelöst. Bei der eigenständigen API tritt derselbe Ausfall in einer von drei Formen auf. Lesen Sie daher die Ergebnisse pro Dienst und database_validation.errors[], niemals den HTTP-Status allein:
  • 200 mit outcome_code: "REGISTRY_UNAVAILABLE" für diesen Dienst in validations, wenn Didit für diesen Dienst noch ein Ergebnis zu melden hat.
  • 200 mit diesem Dienst in database_validation.errors[] als code: "empty_provider_response", retryable: true, wenn er überhaupt keine verwertbare Antwort geliefert hat und ein anderer ausgewählter Dienst dies tat. Der fehlgeschlagene Dienst fehlt dann in validations und in services_used, sodass errors[] die einzige Stelle ist, an der er aufgeführt wird.
  • 502 mit validation_errors[].code: "empty_provider_response" und retryable: true, wenn kein ausgewählter Dienst ein verwertbares Ergebnis zurückgegeben hat (siehe abgelehnte Eingaben und nicht verfügbare Ergebnisse).
Der übergeordnete status richtet sich nach den Diensten, die geantwortet haben, sodass er allein kein verlässliches Ausfallsignal ist. Eine Anfrage, bei der nichts zum Abgleichen übrig bleibt, geht auf In Review, aber eine Anfrage, bei der mehrere Dienste ausgewählt wurden, kann bei der Übereinstimmung eines anderen Dienstes als Approved zurückkommen, während eine ihrer Quellen nicht verfügbar war. Führen Sie den Wiederholungsversuch für den fehlgeschlagenen Dienst aus errors[] durch und nicht für die gesamte Anfrage. Keine dieser Formen sagt etwas über die zu verifizierende Person aus. Didit überwacht die Live-Ergebnisse echter Prüfungen, Datenbank für Datenbank, und sendet Ihrer Organisation eine E-Mail, wenn eine Unterbrechung anhält und es sich nicht nur um eine einzelne fehlgeschlagene Anfrage handelt: Die Benachrichtigungen gehen an die Mitglieder und Abrechnungskontakte jeder Organisation, die in den vorangegangenen 48 Stunden eine Prüfung gegen genau diese Datenbank durchgeführt hat. Es muss nichts konfiguriert werden und es gibt kein Opt-in. Sandbox-Traffic löst sie niemals aus, und ebenso wenig tun dies Fehler, die durch die von Ihnen gesendeten Daten (abgelehnte oder fehlerhafte Eingaben) oder durch Dienste verursacht wurden, die mit Zugangsdaten laufen, die Ihre eigene Organisation anbindet. Eine Prüfung, die über eine Fallback-Quelle beantwortet wurde, gilt als verfügbar, ebenso wie ein eindeutiger Nicht-Treffer.

​
Preise — zahlen Sie nur für das, was Sie nutzen

Die Datenbankvalidierung wird pro erfolgreicher Abfrage, pro Dienst zu dem für diesen Dienst veröffentlichten Preis abgerechnet. Die Preise reichen von $0.05 pro Prüfung (Dominikanische Republik über die Junta Central Electoral) bis zu $7.00 für die teuersten Spezialquellen. Viele Abfragen von Behördenregistern liegen im Bereich von USD 0.20 bis USD 0.30, aber eine beträchtliche Anzahl kostet deutlich mehr, da die Quelle selbst mehr verlangt — der finnische Personalausweis (fin_national_id) kostet $2.10 pro erfolgreicher Abfrage. Bestimmen Sie den Preis für ein Land anhand der jeweiligen Zeile in der Preistabelle, niemals anhand einer Spanne. Es gibt keine monatlichen Mindestbeträge, Verpflichtungen oder Plattformgebühren. Sie zahlen nur, wenn ein Dienst ein Ergebnis zurückgibt. Dienste, die aufgrund fehlender Eingabedaten übersprungen werden, werden nicht in Rechnung gestellt, ebenso wenig wie ein Dienst, dessen Quellaufruf selbst fehlschlägt - ein Registerfehler oder ein nicht erreichbares Register (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) bedeutet, dass die Abfrage nie beantwortet wurde, sodass es sich nicht um ein kostenpflichtiges Ergebnis handelt. Jede erfolgreiche Registerabfrage wird ab der ersten abgerechnet, unabhängig davon, ob sie innerhalb eines Workflows oder über die eigenständige API POST /v3/database-validation/ ausgeführt wird. Sie wird wie jede andere Prüfung von Ihrem Tarifguthaben oder dem Guthaben aus Aufladungen bezahlt, und Ihr Tarifrabatt gilt für den gesamten Preis. Siehe die Preisseite. ➡️ Preise für Datenbankvalidierung · Registrieren und API-Schlüssel erhalten

​
Alle Dienste

​
Weiterführende Themen

  • Abgleichsmethoden — wie 1×1- / 2×2-Ergebnisse abgeleitet werden und wie darauf reagiert wird.
  • Ergebniscodes — die vollständige Liste der Antwortcodes von Anbietern (verstorben, minderjährig, Dokument nicht gefunden, biometrische Nicht-Übereinstimmung, …) und wie sie auf Sitzungsentscheidungen abgebildet werden.
  • Warnungen — was angezeigt wird, wenn ein Dienst aufgrund fehlender Daten nicht ausgeführt werden kann.
  • Berichte — monatliche Abrechnungsexporte pro Dienst mit Land, Dienst-ID, Nutzung, Einheitspreis und Gesamtkosten.
  • Unterstützte Länder — eine statische Tabellenansicht aller Länder, die wir heute abdecken.
Zuletzt geändert am 7. November 2026