Vai al contenuto principale
La Validazione su database di Didit verifica i dati di identità di una persona rispetto alla fonte autorevole di quel paese: l’anagrafe nazionale, l’autorità fiscale, le liste elettorali, la centrale rischi o il registro biometrico che ha originariamente emesso il documento. Ogni controllo restituisce una corrispondenza campo per campo (identification_number, first_name, last_name, date_of_birth e campi relativi all’indirizzo quando il servizio li utilizza), oltre a un esito aggregato e ai dettagli del record sottostante, se disponibili. È la difesa più efficace contro le frodi basate su identità sintetiche: un DNI o un CPF reale rubato non supererà la ricerca nel registro, e un numero fabbricato non sarà affatto presente nel database ufficiale. La Validazione su database si abbina al nostro confronto facciale biometrico nei paesi in cui il registro conserva una foto ufficiale (Argentina tramite RENAPER, Panama tramite Tribunal Electoral SIB / SIB Plus), permettendoti di confermare non solo che il numero è reale, ma anche che la persona davanti alla fotocamera ne è la titolare.

​
Perché Didit

  • Prezzi per chiamata più bassi. Da $0.05 per controllo (Repubblica Dominicana) fino a $7.00 per le fonti specialistiche più costose. Il prezzo è stabilito per servizio, non per paese: il prezzo del servizio è adeguato di conseguenza quando il registro applica una tariffa all’ingrosso elevata (la carta d’identità nazionale della Finlandia costa $2.10). Consulta sempre la tariffa per l’esatto servizio che intendi chiamare nella tabella dei prezzi per servizio. Nessun minimo mensile, nessun costo di piattaforma, nessuna fatturazione per postazione: vengono addebitate solo le richieste riuscite.
  • La più rapida da integrare. Registrati, ottieni una chiave API dalla console e puoi chiamare POST /v3/database-validation/ in pochi minuti. Nessuna chiamata commerciale, nessun ciclo di approvvigionamento, nessuna trafila burocratica per la prova di concetto: Didit è completamente autonoma.
  • Interrogazioni dirette alla fonte autorevole. 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 — non dati estratti da aggregatori.
  • Confronto facciale biometrico dove il registro dispone di una foto ufficiale archiviata. Affidabilità superiore all’OCR senza alcun lavoro di integrazione aggiuntivo.
  • Latenza pronta per la produzione. p95 tipicamente inferiore a 1.5 s complessiva, disponibilità trimestrale del 99.9%.
La lezione dell’Academy sulla lettura dei risultati di verifica affronta la validazione su database al minuto 11:05 e mostra gli esiti di corrispondenza totale, parziale e assente.

​
Copertura globale

Passa il cursore su qualsiasi paese evidenziato per visualizzare ogni servizio di Validazione su database disponibile, il dominio dei dati (Identità, Finanziario, Biometrico, Indirizzo, Telecomunicazioni, …) e il prezzo per chiamata. I paesi attivi sono già pronti per la produzione; i restanti vengono collegati su richiesta non appena un cliente ne fa domanda.
Non trovi il tuo paese? Contattaci: il nostro catalogo copre 60+ paesi con centinaia di servizi che attiviamo su richiesta quando un cliente ne ha bisogno. Le nuove integrazioni diventano tipicamente operative in 2–3 settimane.

​
Come viene eseguita una Validazione su database

Una Validazione su database non viene mai eseguita in modo speculativo. Viene eseguita solo quando tutte le seguenti condizioni sono vere:
  1. La sessione ha determinato un paese da interrogare — a partire dall’issuing_state di una Verifica dell’identità oppure, quando il workflow non contiene un passaggio di Verifica dell’identità, dal singolo paese per cui è configurato il passaggio di Validazione su database.
  2. Quel paese ha almeno un servizio di Validazione su database abilitato nel workflow.
  3. I passaggi precedenti al passaggio di Validazione su database hanno fornito ogni campo richiesto necessario per il servizio scelto.
Se un servizio è abilitato ma i campi richiesti non sono mai arrivati (ad es. non è stato possibile estrarre il CPF da un RG brasiliano sbavato), il servizio viene saltato, non ti viene addebitato alcun costo e viene generato un avviso sulla sessione: DATABASE_VALIDATION_NOT_APPLICABLE quando il documento semplicemente non contiene l’identificativo con cui il servizio effettua l’interrogazione, COULD_NOT_PERFORM_DATABASE_VALIDATION quando avrebbe dovuto essere disponibile e non lo era. Entrambi sono elencati nel catalogo degli avvisi. Qualcuno nel tuo team con accesso di revisione alla sessione può quindi inserire manualmente il campo mancante dalla pagina dei dettagli della sessione nella Console, e il salvataggio riattiva automaticamente il controllo. Questa è un’azione del revisore, non qualcosa che l’utente finale possa fare — per consentire all’utente di fornire un campo non presente sul suo documento, richiedilo tramite un Questionario (oppure ottienilo tramite un’estrazione di Document AI o usa un valore che invii quando crei la sessione) e mappalo nel passaggio di Validazione su database, come descritto di seguito.

​
La Validazione su database non richiede la Verifica dell’identità

In passato, un passaggio di Validazione su database implicava necessariamente un passaggio di Verifica dell’identità a monte, poiché l’OCR di un documento d’identità era l’unico modo integrato per ottenere i dati dell’utente finale. Oggi non è più così: ogni campo richiesto dichiara quali passaggi possono fornirlo, e un servizio diventa disponibile non appena il tuo workflow contiene un passaggio che fornisce tutti i campi necessari. Ciò significa che un servizio biometrico facciale può essere eseguito a partire dal solo passaggio di Rilevamento della vitalità, senza alcun documento d’identità nel workflow, e un servizio basato su un identificativo fiscale, un numero di telefono o un indirizzo email può essere soddisfatto dalla risposta a un questionario, da un passaggio di Verifica telefonica o Verifica email o da un’estrazione di Document AI. Due regole garantiscono la sicurezza di questo approccio:
  • Un workflow senza Verifica dell’identità deve configurare esattamente un paese nel passaggio di Validazione su database. Senza un issuing_state fornito da un documento, questo è l’unico segnale univoco per determinare quale registro nazionale interrogare; pertanto, una configurazione multi-paese senza Verifica dell’identità non esegue alcuna operazione invece di tentare di indovinare.
  • Il controllo dei campi richiesti resta invariato. Un servizio i cui campi non sono tutti presenti al momento dell’esecuzione viene saltato prima di interrogare qualsiasi provider, garantendo così che non ti venga mai addebitato un database che non è mai stato interrogato.

​
Mappatura dei campi di Document AI e dei questionari

I campi di estrazione di Document AI e le domande dei questionari utilizzano i tuoi nomi di chiave, non quelli di Didit. Una chiave che corrisponde esattamente al nome di input di una Validazione su database (tax_number, date_of_birth, phone, …) viene mappata automaticamente e non richiede alcuna configurazione. Per tutto il resto, l’editor del workflow mostra un selettore nel passaggio di Validazione su database per i campi ancora non compilati, dove puoi collegare ciascuno di essi alla chiave di campo di Document AI o alla risposta del questionario che lo fornisce. Nella Console, un servizio che il tuo workflow non può ancora eseguire viene mostrato disabilitato con il relativo motivo — quali campi mancano e quale passaggio li fornirebbe — e l’editor propone di aggiungere tale passaggio per te. L’aggiunta del passaggio attiva immediatamente ogni servizio sbloccato.
Esempio pratico — un identificativo non presente sul documento. Il servizio National ID della Nigeria effettua l’interrogazione tramite il NIN di 11 cifre, che spesso non è stampato sui documenti caricati dagli utenti; affidarsi al solo documento d’identità fa sì che il controllo venga saltato come non applicabile per una quota consistente di utenti. Inserisci un passaggio di tipo Questionario prima del passaggio di Validazione su database per richiedere il NIN, quindi mappa national_id su tale domanda nel passaggio di Validazione su database. Questa stessa mappatura rende utilizzabile all’interno di un workflow qualsiasi identificativo che non compare mai su un documento, come un numero di verifica bancaria o un numero di registrazione aziendale.
Per i servizi basati sull’indirizzo, Didit suddivide automaticamente il singolo campo address del documento d’identità in elementi di indirizzo strutturati: Quando chiami l’API autonoma, puoi inviare un singolo campo address oppure direttamente questi campi strutturati. Quando sono presenti entrambi, i campi strutturati hanno la precedenza. I servizi che richiedono la ricerca dell’indirizzo necessitano di address_element_1 oltre ad almeno un altro elemento di indirizzo; se Didit non riesce a ricavarli dal documento d’identità o dalla Prova di residenza nel workflow, il servizio viene saltato e non fatturato. Se il paese determinato non è affatto abilitato, il passaggio viene saltato silenziosamente, senza alcun avviso e senza alcun addebito.
Flusso di validazione su database Didit che verifica i dati utente rispetto ai registri di identità governativi

​
Il risultato della corrispondenza

Ogni servizio abilitato restituisce una validazione per singolo campo: Il valore aggregato di match_type si articola nei seguenti valori:
  • full_match — ogni campo richiesto corrisponde ad almeno una fonte.
  • partial_match — corrispondenza parziale; instrada verso una coda di revisione in base alle regole del tuo workflow.
  • no_match — nessuna fonte ha confermato i dati; solitamente rifiutata.

​
Come viene ricavata la corrispondenza (1×1 / 2×2)

Non ti chiediamo più di preselezionare “1×1” o “2×2”: questi valori vengono ricavati dal numero di servizi distinti che hanno trovato una corrispondenza completa con i dati inseriti:
  • Risultato 1×1 — un servizio ha restituito una corrispondenza completa (una singola fonte autorevole ha confermato i dati).
  • Risultato 2×2 — due o più servizi hanno restituito una corrispondenza completa (conferma indipendente; il livello massimo di affidabilità esprimibile).
Un workflow può abilitare qualsiasi numero di servizi per paese; la fatturazione avviene per ogni servizio che ha effettivamente restituito un risultato. I servizi i cui campi obbligatori non sono stati estratti vengono ignorati senza alcun addebito. ➡️ Consulta Metodi di corrispondenza per la logica decisionale completa e la sua interazione con partialMatchAction / noMatchAction.

​
Validazione su database biometrica

I registri civili di alcuni paesi rilasciano un modello biometrico (un ritratto o un’impronta digitale). Quando è disponibile, associamo la ricerca nel registro a un confronto facciale biometrico rispetto al selfie dell’utente:
  • Argentina (arg_renaper) — confronto facciale biometrico rispetto alla foto ufficiale RENAPER presente in archivio. Copertura della popolazione al 100%; ogni cittadino argentino dotato di DNI è presente nel database.
  • Panama (pan_cedula_sib, pan_cedula_sib_plus) — confronto facciale biometrico rispetto al servizio SIB del Tribunal Electoral. SIB Plus è la variante di livello superiore con soglie biometriche più restrittive e metadati di corrispondenza più dettagliati.
Per questi servizi il campo selfie è obbligatorio. All’interno del flusso di una sessione riutilizziamo il selfie del rilevamento della vitalità (massima qualità) e ricorriamo alla foto del documento come alternativa. Al di fuori di una sessione, quando chiami l’API standalone (POST /v3/database-validation/, Modalità B sopra descritta), fornisci tu stesso il file JPEG/PNG.

​
Arricchimento globale dell’identità

glb_identity_enrichment è un servizio di Validazione su database globale, solo standalone. A partire da un indirizzo email e/o un numero di telefono, risale alle persone associate (nomi, date di nascita, indirizzi, numeri di telefono, email e documenti di identità nazionali) e restituisce un punteggio di corrispondenza del nome, mappato sui codici di risultato standard MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (con il corrispondente match_type impostato su full_match / partial_match / no_match). Poiché si tratta di un servizio globale (GLB) basato su email/telefono anziché sul paese di emissione del documento, non è disponibile nel generatore di workflow. Chiamalo direttamente tramite l’API standalone impostando issuing_state su GLB:
Viene fatturato a $0.20 per richiesta (addebitato solo quando il provider restituisce un risultato).

​
Configurazione

La Validazione su database viene configurata per ciascun workflow dalla Console. Per ogni paese selezioni i servizi specifici da eseguire; i campi di input obbligatori e opzionali derivano dall’unione di tali servizi. L’azione intrapresa sui risultati partial_match e no_match viene configurata separatamente e può essere approve, review o decline.
Didit database validation console settings selecting per-country registry services and outcome rules

​
Notifiche di disponibilità

I registri governativi e le altre fonti possono presentare interruzioni di tanto in tanto. Quando un database non è raggiungibile, i controlli eseguiti su di esso non restituiscono alcuna risposta e non vengono fatturati. All’interno di un workflow il servizio si risolve in REGISTRY_UNAVAILABLE. Sull’API autonoma la stessa interruzione si presenta in una di tre forme, quindi leggi gli esiti per servizio e database_validation.errors[], mai il solo stato HTTP:
  • 200 con outcome_code: "REGISTRY_UNAVAILABLE" su quel servizio in validations, quando Didit ha mantenuto un risultato da segnalare al riguardo.
  • 200 con quel servizio in database_validation.errors[] come code: "empty_provider_response", retryable: true, quando non ha prodotto alcuna risposta utilizzabile e un altro servizio selezionato l’ha fatto. Il servizio non riuscito è quindi assente da validations e da services_used, per cui errors[] è l’unico punto in cui compare.
  • 502 con validation_errors[].code: "empty_provider_response" e retryable: true, quando nessun servizio selezionato ha restituito un risultato utilizzabile (vedi dati di input rifiutati e risultati non disponibili).
Lo status complessivo segue i servizi che hanno risposto, quindi non è un segnale affidabile di interruzione se considerato da solo. Una richiesta rimasta senza nulla con cui effettuare il confronto passa a In Review, ma una richiesta che ha selezionato più servizi può tornare come Approved sulla corrispondenza di un altro servizio mentre una delle sue fonti non era disponibile. Riprova il servizio non riuscito da errors[] anziché l’intera richiesta. Nessuna di queste forme indica alcunché sulla persona sottoposta a verifica. Didit monitora i risultati in tempo reale dei controlli effettivi, database per database, e invia un’email alla tua organizzazione quando un’interruzione è prolungata anziché trattarsi di una singola richiesta non riuscita: Le notifiche vengono inviate ai membri e ai contatti di fatturazione di ogni organizzazione che ha eseguito un controllo su quello specifico database nelle 48 ore precedenti. Non è necessario configurare nulla e non è richiesto alcun consenso esplicito. Il traffico di sandbox non le attiva mai, così come non le attivano gli errori causati dai dati inviati (input rifiutato o malformato) o da servizi che utilizzano credenziali collegate dalla tua organizzazione. Un controllo a cui è stata fornita risposta tramite una fonte alternativa conta come disponibile, così come una mancata corrispondenza definitiva.

​
Prezzi - paga solo per ciò che usi

La Validazione su database viene fatturata per query riuscita, per servizio, alla tariffa pubblicata per tale servizio. Le tariffe vanno da $0.05 per controllo (Repubblica Dominicana tramite Junta Central Electoral) fino a $7.00 per le fonti specialistiche più costose. Molte consultazioni di registri governativi si collocano nella fascia da USD 0.20 a USD 0.30, ma un buon numero costa notevolmente di più perché la fonte stessa applica un prezzo più elevato - Finland National ID (fin_national_id) costa $2.10 per query riuscita. Determina il prezzo per un paese in base alla relativa riga nella tabella dei prezzi, mai da una fascia. Non sono previsti minimi mensili, impegni o costi di piattaforma. Paghi solo quando un servizio restituisce un risultato. I servizi ignorati a causa di dati di input mancanti non vengono fatturati, così come non viene fatturato un servizio la cui chiamata alla fonte fallisce - un errore del registro o un registro non raggiungibile (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) indica che alla query non è mai stata data risposta, quindi non è un risultato fatturabile. Ogni query del registro riuscita viene addebitata fin dalla prima, sia che venga eseguita all’interno di un workflow sia tramite l’API autonoma POST /v3/database-validation/. Viene pagata tramite il credito del tuo piano o il saldo delle ricariche come qualsiasi altro controllo, e lo sconto del tuo piano si applica all’intero prezzo. Consulta la pagina dei prezzi. ➡️ Prezzi della Validazione su database · Registrati e ottieni una chiave API

​
Tutti i servizi

​
Continua a leggere

  • Metodi di corrispondenza - come vengono derivati gli esiti 1×1 / 2×2 e come reagire ad essi.
  • Codici di esito - l’elenco completo dei codici di risposta del fornitore (deceduto, minore, documento non trovato, mancata corrispondenza biometrica, …) e come corrispondono alle decisioni della sessione.
  • Avvisi - cosa segnaliamo quando un servizio non può essere eseguito a causa di dati mancanti.
  • Report - esportazioni mensili di fatturazione per servizio con paese, ID servizio, utilizzo, prezzo unitario e costo totale.
  • Paesi supportati - una visualizzazione tabellare statica di ogni paese coperto attualmente.
Ultima modifica il 7 novembre 2026