Vai al contenuto principale

Panoramica

La verifica della prova di residenza (POA) accetta un singolo PDF o un’immagine (TIFF, JPG, JPEG, PNG, WEBP, eventualmente compresso in ZIP) fino a 15 MB, esegue la classificazione del tipo di documento, l’estrazione basata su LLM e l’analisi forense PDF/EXIF, e restituisce:
  • L’indirizzo estratto — sia grezzo che strutturato (street_1, city, region, postal_code, lat/lng).
  • Metadati del documento — dimensioni del file, tipo di contenuto, date di creazione e modifica, date EXIF, informazioni sulla firma ed eventuali prove di manipolazione tramite sovrapposizioni derivanti dall’analisi forense del PDF.
  • Punteggi di corrispondenza del nome rispetto al documento d’identità verificato e rispetto ai dettagli previsti forniti alla creazione della sessione.
  • Campi aggiuntivi relativi alla banca (numero di conto, IBAN, codice di smistamento, numero di instradamento, SWIFT/BIC, filiale) quando il documento è un estratto conto bancario.
Screenshot del report di prova di residenza di Didit che mostra i campi dell'indirizzo estratto e il tipo di documento
L’estrazione della POA esegue la lettura di testo non strutturato, introducendo una latenza di 5–15 secondi per documento. I webhook vengono attivati solo al completamento dell’intero passaggio del workflow — non effettuare il polling dell’endpoint di decisione a intervalli inferiori a 5 s durante questo intervallo.

Dove appare nelle risposte API

L’endpoint di decisione restituisce la POA come array plurale poa_verifications[] in GET /v3/session/{sessionId}/decision/. Ciascuna voce rappresenta un’esecuzione del nodo POA nel tuo workflow; le sessioni con più passaggi POA (ad es. estratto conto bancario + bolletta delle utenze) generano una voce per ciascuna esecuzione con il rispettivo node_id.
La struttura seguente rispecchia lo schema canonico — vedi Modelli di dati.

Schema

Consulta Prova di residenza nel riferimento ai modelli di dati per lo schema canonico.
Ciascuna voce in warnings[] è un oggetto di avviso: { feature, risk, additional_data, log_type, short_description, long_description, node_id }, con feature sempre impostato su "PROOF_OF_ADDRESS" per questo report.

Valori di status

status utilizza l’enum di stato a livello di funzionalità (FeatureStatusChoices). Le regole di stato personalizzate configurate sul nodo del workflow possono regolare ulteriormente lo stato calcolato; le regole si combinano con la precedenza Declined > In Review > Approved. Consulta Avvisi della prova di residenza per la mappatura completa da rischio ad azione, incluso il comportamento di nuovo tentativo solo nel workflow di FUTURE_ISSUE_DATE.

Evidenze di manipolazione delle sovrapposizioni nel PDF

Quando il documento inviato è un PDF, document_metadata.overlay_manipulation può contenere evidenze forensi di possibili overlay di testo:
  • detected — true quando il controllo rileva evidenze di manipolazione.
  • analyzed — true quando è stato possibile analizzare il PDF.
  • analysis_incomplete — presente e true solo quando non è stato possibile controllare il file per intero. I risultati relativi a ciò che è stato verificato vengono mantenuti ove possibile, e il documento genera POA_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT.
  • signals — i controlli che sono scattati (duplicate_font_subset, glyph_fragmentation).
  • manipulated_regions — rettangoli in coordinate di pagina attorno al testo sospetto modificato. Ogni rettangolo usa lo spazio di coordinate della pagina PDF (x, y, width, height, page_width, page_height), così i revisori possono evidenziare l’area interessata in un’anteprima del PDF.
Il campo è null quando il documento non è un PDF o quando non è stato possibile analizzare il PDF. Quando detected=true, il sistema emette anche un avviso SUSPECTED_DOCUMENT_MANIPULATION il cui additional_data riflette i segnali e i rettangoli descritti sopra (a meno che non sia prevalso un segnale più forte, ossia la modifica dopo la firma digitale, is_tampered=true; in tal caso additional_data descrive invece la manomissione della firma).

Codici QR e codici a barre

Ogni report POA include detected_codes, che copre ogni pagina elaborata. Ciascun elemento contiene: detected_codes è un array vuoto se non viene trovato alcun codice supportato. Didit non tenta mai di indovinare un payload: i codici danneggiati o illeggibili possono essere restituiti con la loro posizione e parsed_payload: null, mentre gli errori nel rilevamento del codice non causano il fallimento della verifica POA.

Esempi

Approvata — estratto conto bancario

Rifiutata — manipolazione tramite sovrapposizione + mancata corrispondenza del nome

Correlati

document_file ed extra_files[] sono URL pre-firmati che scadono dopo circa 4 ore. Richiama l’endpoint di decisione per aggiornare gli URL. Memorizza solo lo stato di verifica e i campi dell’indirizzo analizzati dal tuo lato — riduci al minimo i dati dei documenti conservati.
Ultima modifica il 7 novembre 2026