Avvisi di validazione su database e codici di salto

La funzionalità Validazione su database di Didit verifica i dati di identità rispetto ad anagrafi civili ufficiali — RENAPER (Argentina), Receita Federal (Brasile), Tribunal Electoral (Panama, biometrico), Junta Central Electoral (Repubblica Dominicana) e altri ancora — fatturata per query riuscita senza minimi mensili. Quando nessun servizio può essere eseguito (campi obbligatori mancanti o malformati, registro non disponibile), il documento stesso non può essere verificato (non riporta l’identificativo richiesto dai servizi configurati — ad esempio un passaporto senza numero identificativo nazionale), o l’esito aggregato non è conclusivo (corrispondenza parziale, nessuna corrispondenza), la funzionalità emette un avviso sulla sessione. Se il paese di emissione non è abilitato affatto nel workflow, il passaggio viene ignorato in modo silente senza avvisi e senza alcun addebito. Questa pagina documenta ogni codice di avviso, cosa lo attiva e come configurare la risposta del workflow.

Panoramica

Gli avvisi vengono generati sia nelle sessioni di workflow che tramite l’API autonoma (POST /v3/database-validation/). Tutti e cinque i rischi sono contrassegnati con la funzionalità DATABASE_VALIDATION, compaiono nel report sotto database_validations[].warnings[] e seguono la struttura standard dell’oggetto avviso (feature, risk, additional_data, log_type, short_description, long_description, node_id). Non ci sono trigger rigidi di rifiuto automatico per Validazione su database. I due rischi relativi all’esito della corrispondenza, il rischio del documento sostituito e il rischio di non applicabilità sono mappati su un’azione configurabile (DECLINE, REVIEW o NO_ACTION); COULD_NOT_PERFORM_DATABASE_VALIDATION è l’unico rischio con un comportamento fisso — indirizza sempre la funzionalità a In revisione.

Rischi configurabili

Impostazione	Codice di rischio	Comportamento
Azione in caso di mancata corrispondenza	`DATABASE_VALIDATION_NO_MATCH`	`REVIEW` (valore predefinito del workflow) imposta la funzionalità su In revisione; `DECLINE` rifiuta; `NO_ACTION` registra l’avviso senza influire sullo stato. Il parametro `no_match_action` dell’API autonoma è invece impostato in modo predefinito su `DECLINE`.
Azione in caso di corrispondenza parziale	`DATABASE_VALIDATION_PARTIAL_MATCH`	`NO_ACTION` (valore predefinito) registra l’avviso senza influire sullo stato; `REVIEW` imposta la funzionalità su In revisione; `DECLINE` rifiuta.
Azione in caso di mancata corrispondenza	`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Condivide l’impostazione Azione in caso di mancata corrispondenza — non esiste un’impostazione separata. Il registro è in contrasto con quanto inviato, pertanto un’organizzazione che rifiuta in caso di assenza di corrispondenza rifiuta anche in presenza di una credenziale obsoleta.
Azione in caso di non applicabilità	`DATABASE_VALIDATION_NOT_APPLICABLE`	`NO_ACTION` (valore predefinito) registra l’avviso senza influire sullo stato; `REVIEW` imposta la funzionalità su In revisione; `DECLINE` rifiuta. Si attiva quando il documento non può essere verificato affatto — non riporta l’identificativo utilizzato per la query dai servizi configurati (ad es. un passaporto senza numero identificativo nazionale).

L’azione configurata determina anche il log_type dell’avviso: DECLINE → error, REVIEW → warning, NO_ACTION → information. L’esito della corrispondenza viene aggregato dalle voci validation di ciascun servizio (qualsiasi corrispondenza completa → full_match; altrimenti qualsiasi corrispondenza parziale → partial_match; altrimenti no_match) — consulta Metodi di corrispondenza per la logica decisionale completa che ricava gli esiti 1×1 / 2×2.

Avvisi generati

Tag	Descrizione breve	Descrizione
`COULD_NOT_PERFORM_DATABASE_VALIDATION`	Impossibile eseguire la validazione su database	Nessun servizio ha restituito un risultato utilizzabile (`match_type` rimane `null`) — in genere perché i campi obbligatori sono mancanti o non corretti, oppure il registro ha restituito un errore. `additional_data` include il riepilogo delle esclusioni per servizio (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); l’API autonoma utilizza invece `{ "validation_errors": [...] }`. Non ti viene addebitato alcun costo quando si attiva questo avviso; la funzionalità passa a In revisione finché i dati non vengono corretti.
`DATABASE_VALIDATION_NOT_APPLICABLE`	Validazione su database non applicabile per questo documento	Il documento fornito non contiene l’identificativo richiesto dai servizi di database configurati (`match_type` rimane `null`) — ad esempio, un passaporto brasiliano non riporta il CPF, quindi il registro CPF non può essere interrogato. Questo comportamento è previsto per tale tipologia di documento e non indica un problema con il documento. `additional_data` include il riepilogo delle esclusioni per servizio. Non ti viene addebitato alcun costo quando si attiva questo avviso. Azione configurabile (valore predefinito `NO_ACTION`).
`DATABASE_VALIDATION_PARTIAL_MATCH`	Corrispondenza parziale nella validazione su database	Il `match_type` aggregato è `partial_match` — alcuni campi sottoposti a screening corrispondono al registro ma non tutti. Azione configurabile (valore predefinito `NO_ACTION`).
`DATABASE_VALIDATION_NO_MATCH`	Nessuna corrispondenza nella validazione su database	Il `match_type` aggregato è `no_match` — il registro non ha potuto confermare l’identità sottoposta a screening. Azione configurabile (valore predefinito `REVIEW` nei workflow, `DECLINE` nell’API autonoma).
`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Versione del documento obsoleta	Un servizio ha restituito `DOCUMENT_SUPERSEDED`: il registro ha confermato la persona, ma la versione del documento presentata non è quella registrata — nel frattempo è stata emessa una versione più recente. Viene generato indipendentemente da `match_type`, che rimane `full_match` perché ogni campo personale corrispondeva, quindi il riscontro sarebbe altrimenti invisibile. `additional_data` indica i servizi che lo hanno segnalato. Segue l’impostazione No Match Action.

COULD_NOT_PERFORM_DATABASE_VALIDATION copre due situazioni distinte e la long_description dell’avviso (e, per gli errori specifici di un servizio, database_validation_errors[].message) ora indica quale si è verificata invece di fornire una singola frase generica: i dati sottoposti a screening erano mancanti o non corretti prima che qualsiasi servizio potesse essere interrogato, oppure un servizio è stato interrogato ma non ha restituito un risultato utilizzabile. Nel secondo caso, quando il registro ha segnalato dettagli diagnostici propri per tale tentativo, questi dettagli vengono inclusi nel messaggio in modo da non dover contattare l’assistenza per comprenderne il motivo. Il servizio a monte non viene mai menzionato nella risposta.

Quando COULD_NOT_PERFORM_DATABASE_VALIDATION o DATABASE_VALIDATION_NOT_APPLICABLE si attiva in una sessione di workflow, il controllo viene riavviato automaticamente una volta compilati i dati mancanti nella pagina dei dettagli della sessione nella Console — salvando il campo viene rieseguita la validazione e, in caso di esito positivo, l’avviso viene rimosso. Questo funziona anche quando l’azione per esito non applicabile ha rifiutato la sessione, consentendo di correggere una sessione rifiutata modificando i dati. Per DATABASE_VALIDATION_NOT_APPLICABLE, la nuova esecuzione è utile quando il documento può contenere l’identificativo ma questo non è stato letto (ad esempio, un permesso di soggiorno di cui non è stato estratto il numero di identificazione nazionale); i tipi di documento che non contengono mai l’identificativo (ad esempio, i passaporti senza numero di identificazione nazionale) mantengono l’avviso. Nessun addebito viene applicato per i servizi saltati; paghi solo quando un servizio restituisce un risultato fatturabile.

Esempio

{
  "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"
    }
  ]
}

Tipologie di avviso

A ciascun rischio viene assegnata una gravità in base alla configurazione della tua applicazione. I livelli di gravità rientrano in tre categorie:

Risorse correlate

Panoramica sulla validazione su database — funzionamento completo della funzionalità e registri supportati.
Report di validazione su database — struttura completa della risposta, incluso validations[] per servizio.
Metodi di corrispondenza — come vengono derivati i risultati 1×1 / 2×2 (validation_type: one_by_one / two_by_two) dalle corrispondenze dei singoli servizi.
Codici di esito — tassonomia completa dei risultati con codici di dettaglio specifici per paese.
Paesi e servizi supportati — tutti i registri attivi, campi obbligatori e prezzo per chiamata.
Modelli di dati — validazione su database — schema canonico campo per campo.

Autenticazione

Verifica

Monitoraggio

Piattaforma

Avvisi di validazione su database e codici di salto

Panoramica

Rischi configurabili

Avvisi generati

Esempio

Tipologie di avviso

Risorse correlate

​Panoramica

​Rischi configurabili

​Avvisi generati

​Esempio

​Tipologie di avviso

​Risorse correlate

Panoramica

Rischi configurabili

Avvisi generati

Esempio

Tipologie di avviso

Risorse correlate