Zum Hauptinhalt springen

Übersicht

Die Adressnachweis-Verifizierung (POA) akzeptiert ein einzelnes PDF oder Bild (TIFF, JPG, JPEG, PNG, WEBP, optional ZIP-komprimiert) bis zu 15 MB, führt eine Dokumenttyp-Klassifizierung, LLM-basierte Extraktion sowie PDF/EXIF-Forensik durch und gibt Folgendes zurück:
  • Die extrahierte Adresse – sowohl als Rohdaten als auch strukturiert (street_1, city, region, postal_code, lat/lng).
  • Dokumenten-Metadaten – Dateigröße, Inhaltstyp, Erstellungs- und Änderungsdaten, EXIF-Daten (Datum/Uhrzeit), Signaturinformationen und etwaige Beweise für Overlay-Manipulationen aus der PDF-Forensik.
  • Übereinstimmungswerte für Namen im Abgleich mit dem verifizierten Ausweisdokument und mit den bei der Sitzungserstellung angegebenen erwarteten Angaben.
  • Bankbezogene Zusatzfelder (Kontonummer, IBAN, Sort Code, Routing Number, SWIFT/BIC, Filiale), wenn es sich bei dem Dokument um einen Kontoauszug handelt.
Screenshot des Didit-Adressnachweis-Berichts mit extrahierten Adressfeldern und Dokumenttyp
Die POA-Extraktion liest unstrukturierten Text aus, was zu einer Latenz von 5–15 Sekunden pro Dokument führt. Webhooks werden erst ausgelöst, wenn der gesamte Workflow-Schritt abgeschlossen ist – rufen Sie den Entscheidungs-Endpoint während dieses Fensters nicht häufiger als alle 5 s ab.

Wo es in API-Antworten erscheint

Der Entscheidungs-Endpoint gibt POA als Plural-Array poa_verifications[] in GET /v3/session/{sessionId}/decision/ zurück. Jeder Eintrag entspricht einer Ausführung des POA-Knotens in Ihrem Workflow; Sitzungen mit mehreren POA-Schritten (z. B. Kontoauszug + Verbrauchsabrechnung) erzeugen einen Eintrag pro Ausführung mit eigener node_id.
Die folgende Struktur spiegelt das kanonische Schema wider – siehe Datenmodelle.

Schema

Siehe Adressnachweis in der Datenmodell-Referenz für das kanonische Schema.
Jeder Eintrag in warnings[] ist ein Warnungsobjekt: { feature, risk, additional_data, log_type, short_description, long_description, node_id }, wobei feature für diesen Bericht immer "PROOF_OF_ADDRESS" ist.

Statuswerte

status verwendet das Status-Enum auf Feature-Ebene (FeatureStatusChoices). Benutzerdefinierte Statusregeln, die auf dem Workflow-Knoten konfiguriert sind, können den berechneten Status weiter anpassen; Regeln werden mit der Rangfolge Declined > In Review > Approved kombiniert. Siehe Adressnachweis-Warnungen für das vollständige Mapping von Risiken zu Aktionen, einschließlich des reinen Workflow-Wiederholungsverhaltens von FUTURE_ISSUE_DATE.

PDF-Nachweise zur Overlay-Manipulation

Wenn das eingereichte Dokument eine PDF-Datei ist, kann document_metadata.overlay_manipulation forensische Nachweise für vermutete Text-Overlays enthalten:
  • detected: true, wenn die Prüfung Nachweise für eine Manipulation gefunden hat.
  • analyzed: true, wenn die PDF-Datei überhaupt analysiert werden konnte.
  • analysis_incomplete: Das Feld ist vorhanden und nur dann true, wenn die Datei nicht vollständig geprüft werden konnte. Die Ergebnisse der tatsächlich durchgeführten Prüfungen bleiben, soweit möglich, erhalten, und das Dokument löst POA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT aus.
  • signals: die Prüfungen, die ausgelöst wurden (duplicate_font_subset, glyph_fragmentation).
  • manipulated_regions: Rechtecke in Seitenkoordinaten um den vermutlich bearbeiteten Text. Jedes Rechteck verwendet das Seitenkoordinatensystem der PDF-Datei (x, y, width, height, page_width, page_height), damit Prüfer den betroffenen Bereich in einer PDF-Vorschau hervorheben können.
Das Feld ist null, wenn das Dokument keine PDF-Datei ist oder die PDF-Datei nicht analysiert werden konnte. Wenn detected=true gesetzt ist, gibt das System außerdem eine Warnung SUSPECTED_DOCUMENT_MANIPULATION aus, deren additional_data die oben genannten Signale und Rechtecke widerspiegelt. Ausgenommen ist der Fall, dass ein stärkeres Signal Vorrang hat, etwa eine Änderung nach der digitalen Signatur oder is_tampered=true. In diesem Fall beschreibt additional_data stattdessen die Manipulation der Signatur.

QR-Codes und Barcodes

Jeder POA-Bericht enthält detected_codes, die jede verarbeitete Seite abdecken. Jeder Eintrag enthält: detected_codes ist ein leeres Array, wenn kein unterstützter Code gefunden wird. Didit errät niemals eine Payload: Beschädigte oder unleserliche Codes können mit ihrer Position und parsed_payload: null zurückgegeben werden, während Fehler bei der Code-Erkennung nicht zum Fehlschlagen der POA-Verifizierung führen.

Beispiele

Genehmigt – Kontoauszug

Abgelehnt – Overlay-Manipulation + Namensdiskrepanz

Verwandte Themen

document_file und extra_files[] sind vorab signierte URLs, die nach etwa 4 Stunden ablaufen. Rufen Sie den Entscheidungs-Endpoint erneut auf, um URLs zu aktualisieren. Speichern Sie auf Ihrer Seite nur den Verifizierungsstatus und die geparsten Adressfelder – minimieren Sie die gespeicherten Dokumentdaten.
Zuletzt geändert am 7. November 2026