I Workflow orchestrati di Didit sono il modo più potente e flessibile per progettare e pubblicare percorsi di verifica dell’identità completi e articolati in più passaggi.
Questa lezione della Didit Academy mostra come costruire un flusso di verifica nella console reale, dal modello al flusso pubblicato: come scegliere i controlli su ciascun nodo, come impostare regole e soglie, come gestire le diramazioni AML, come usare i nodi webhook e come ripristinare una versione precedente.
Questo percorso di integrazione ti permette di sfruttare tutta l’intelligenza della piattaforma Didit V2, creando sequenze di verifica sofisticate con il builder visuale senza codice. Definisci la logica una sola volta nella tua Business Console, e Didit gestisce l’intera esperienza rivolta all’utente, la gestione dello stato e i passaggi condizionali.
Scegli questo percorso quando ti serve una soluzione completa dall’inizio alla fine per l’onboarding degli utenti (KYC), la verifica dell’età o la riautenticazione, e vuoi partire rapidamente con uno sforzo di sviluppo minimo, mantenendo al tempo stesso il massimo controllo sul processo.
Metodi di identità per paese
In Verifica dell’identità, apri Paesi e metodi di identificazione consentiti per configurare, per ciascun paese, l’acquisizione del documento, la ricerca senza documento e i wallet di identità digitale.
Impostazioni aggiuntive contengono i sottotipi di documento, i tentativi di ricerca e le regole di fallback.
La ricerca senza documento utilizza il prezzo del servizio Validazione su database della tua organizzazione.
Ogni tentativo completato viene addebitato separatamente, inclusi i riscontri parziali e quelli senza corrispondenza: due tentativi completati significano due addebiti.
Gli errori di formato e gli errori del provider che non restituiscono alcuna risposta non vengono addebitati.
Se più servizi di database rispondono a un unico tentativo, i prezzi applicabili di tali servizi vengono sommati.
Il valore predefinito è un tentativo prima del fallback, configurabile da uno a cinque.
L’acquisizione del documento viene addebitata in aggiunta quando una ricerca completata ricorre al documento come fallback.
Le applicazioni in produzione possono abilitare solo i wallet disponibili per la produzione.
I wallet in attesa di lancio restano disabilitati.
Le applicazioni in sandbox possono testare tutti i wallet del catalogo con risultati simulati; la disponibilità in sandbox non indica la disponibilità in produzione.
Consulta Test in sandbox per gli scenari di errore della ricerca e dei wallet.
Gestione delle versioni dei workflow
I workflow supportano la gestione delle versioni delle bozze e delle pubblicazioni. Questo significa che puoi modificare il tuo workflow in modo sicuro senza influire sulle sessioni attive:
- Le versioni bozza sono completamente modificabili: aggiungi, rimuovi o ristruttura i nodi liberamente
- Pubblicare una bozza crea una versione immutabile che le nuove sessioni utilizzeranno
- Le versioni precedenti vengono conservate, così puoi ispezionare la configurazione esatta usata per qualsiasi sessione passata
- Le sessioni fanno sempre riferimento alla versione specifica con cui sono state create, garantendo coerenza anche dopo la pubblicazione di aggiornamenti
Per modificare un workflow pubblicato, crea una nuova bozza a partire dalla versione pubblicata, modificala e pubblicala quando è pronta. La cronologia delle versioni è disponibile tramite la Management API.
Due modi per creare i workflow
Didit offre due approcci distinti per creare i workflow di verifica, così puoi scegliere il livello di complessità più adatto alle tue esigenze:
1. Modalità semplice: builder basato su modelli
La Modalità semplice è ideale per iniziare rapidamente. Seleziona un modello predefinito, attiva o disattiva le funzionalità che ti servono, e sei pronto.
Ideale per:
- Configurazione e messa in produzione rapide
- Flussi di verifica standard
- Team che si avvicinano per la prima volta alla verifica dell’identità
- Casi d’uso che rientrano in schemi comuni
Come funziona:
- Scegli un modello di workflow (KYC, verifica dell’età, ecc.)
- Attiva o disattiva le funzionalità (Rilevamento della vitalità, Confronto facciale, Screening AML, ecc.)
- Configura le impostazioni di base per ciascuna funzionalità
- Pubblica e inizia a verificare
2. Modalità avanzata: builder visuale a grafo
La Modalità avanzata sblocca tutta la potenza del motore di orchestrazione di Didit. Crea flussi di verifica complessi e condizionali con il nostro editor visuale a grafo, con nodi trascinabili, rami e logiche personalizzate.
Ideale per:
- Percorsi di verifica complessi con più strade possibili
- Logiche condizionali basate sui dati dell’utente o sui risultati della verifica
- Regole di business personalizzate e diramazioni
- Requisiti di compliance di livello enterprise
Funzionalità principali:
- Editor visuale dei nodi: trascina, rilascia e collega i nodi su una tela infinita
- Connessioni intelligenti: trascina da un punto di collegamento di un nodo fino a uno spazio vuoto per creare e collegare subito un nuovo nodo
- Rami condizionali: instrada gli utenti in base ai dati estratti, allo stato della verifica, al paese, al tipo di documento, al sottotipo di documento, alla data di emissione, all’età, ai percorsi della risposta JSON del webhook o a regole personalizzate
- Automazione delle azioni: aggiungi tag, imposta metadati o instrada alla revisione manuale in base agli esiti del flusso
- Scorciatoie da tastiera: Annulla (Ctrl/Cmd+Z), Ripeti (Ctrl/Cmd+Maiusc+Z), Elimina (Canc/Backspace)
- Zoom e panoramica: naviga nei flussi complessi con lo zoom tramite scroll e lo spostamento trascinando
Tipi di nodo del builder a grafo
Categorie di funzionalità dei nodi
Funzionalità interattive con l’utente (possono avviare un workflow):
- Verifica dell’identità (OCR)
- Rilevamento della vitalità (Liveness Detection)
- Confronto facciale (Face Match)
- Stima dell’età
- Verifica telefonica
- Verifica email
- Questionario
- Prova di residenza
- Document AI
- NFC / ePassport
Funzionalità solo backend (vengono eseguite automaticamente, senza interazione con l’utente):
- Screening AML (richiede prima un passaggio di Verifica dell’identità, Registro delle imprese KYB o Document AI, vedi Entità sottoposta a screening)
- Validazione su database (richiede prima l’OCR)
- Analisi dispositivo e IP
Nota: le funzionalità solo backend sono contrassegnate da un indicatore specifico nel builder e vengono eseguite automaticamente, senza interazione con l’utente, una volta soddisfatte le dipendenze.
La prima scheda di configurazione di ogni nodo funzione si apre con il controllo Motore di verifica: esegui il controllo con il motore di Didit oppure passa a un provider di terze parti che colleghi da Marketplace, con fallback automatico su Didit se quel provider non è disponibile.
Entità sottoposta a screening
Lo Screening AML di solito ricava il soggetto da sottoporre a screening dal passaggio che lo precede: la persona che un passaggio Verifica dell’identità ha ricavato da un documento, oppure l’azienda restituita da un passaggio registro delle imprese KYB. Alcuni flussi non hanno né l’uno né l’altro. Un flusso costruito interamente su Document AI, con documenti non standardizzati come un certificato fiscale o un atto costitutivo notarile, contiene già nome, data di nascita, numero del documento e paese, ma sotto le tue chiavi di campo personalizzate.
La scheda Avanzate del nodo AML è dove puoi indicare a quali chiavi fare riferimento per lo screening:
- Tipo di entità: sottoponi a screening una persona, oppure l’azienda indicata in un documento caricato. Un nodo azienda cerca nei registri delle aziende e non tra le persone.
- Origini dei campi: associa ciascuno dei quattro input di screening (nome, data di nascita, paese, numero del documento) a un campo di Document AI, a una risposta del questionario o a un valore che invii alla creazione della sessione (
expected_details / metadata). Un campo di Document AI che hai già chiamato full_name viene riconosciuto automaticamente.
- Dati di screening incompleti: cosa succede quando lo screening viene eseguito con dati identificativi incompleti. La revisione è l’impostazione predefinita; scegli No action solo quando il flusso contiene consapevolmente soltanto un nome.
Due cose vale la pena sapere prima di affidarti a questo flusso. Senza un passaggio di Verifica dell’identità o di KYB Registry, il nome è obbligatorio: il workflow non può essere pubblicato finché non viene inserito un nome, perché non esiste ricerca senza un nome. E la precisione dello Screening AML dipende direttamente da quanti identificativi fornisci: uno screening basato solo sul nome è ciò che genera il volume di falsi positivi di cui si lamentano i revisori, quindi associa la data di nascita e il paese ogni volta che il documento li riporta.
Come leggere le condizioni dei rami sui dati di sessione
Quale record legge una condizione. Una condizione di ramo è associata al nodo della funzionalità da cui è stata creata e legge il risultato di quel nodo. Quando un singolo nodo ha prodotto più record, la condizione legge quello più recente. Questo conta soprattutto per Analisi dispositivo e IP: Didit registra un’osservazione per ogni dispositivo e indirizzo da cui una sessione viene aperta, quindi un utente che cambia telefono o rete a metà sessione lascia più record sullo stesso nodo. Una regola come IP COUNTRY is in [...] viene quindi valutata rispetto all’osservazione più recente, cioè lo stesso record mostrato per primo nel pannello Analisi dispositivo e IP della sessione e nell’array ip_analyses del payload della decisione. Le sessioni con più di un’osservazione riportano anche l’avviso MULTIPLE_DEVICES_IN_SESSION, che segnala di esaminare l’elenco completo invece del solo esito del ramo.
Valori dei paesi. Le condizioni sui paesi vengono confrontate sul paese stesso, non sulla notazione. Scegli i paesi dal selettore dei campi e Didit normalizza entrambi i lati del confronto, quindi una regola scritta in ISO 3166-1 alpha-3 (UKR) corrisponde comunque a un valore acquisito in alpha-2 (UA).
Valori mancanti, valori vuoti e confronti negativi. Un campo senza alcun valore (il documento non lo riporta, la chiave dei metadati non è stata inviata, la funzionalità non è stata eseguita) corrisponde solo a is empty e equals not_defined; ogni altro confronto - equals, contains, greater than, e anche not equals e not in - non corrisponde, e il nodo di ramificazione passa al ramo successivo. Un campo che contiene una stringa vuota è un valore, non un campo mancante: una sessione creata con "metadata": {"credential_state": ""} non supera metadata.credential_state equals IL, ma supera not equals IL, not in [IL, MA, NJ] e equals "" (is empty corrisponde a entrambi i casi). Un ramo che approva su un confronto negativo approva quindi una sessione il cui stato è stato inviato vuoto, mentre la stessa sessione senza la chiave prende il ramo di fallback. Quando instradi su not equals o not in, aggiungi metadata.<key> is not empty allo stesso ramo (logica AND) in modo che entrambi i casi terminino dove dovrebbe terminare un valore assente. I rami vengono valutati in ordine e vince il primo che corrisponde; il ramo di fallback (il ramo senza condizioni) viene seguito solo quando nessun altro ramo ha corrisposto, quindi assegna a ogni nodo di ramificazione un fallback che termini dove vuoi che finisca un valore inatteso. Una sessione che arriva in In revisione senza avvisi su alcuna funzionalità è stata instradata lì da un nodo di stato nel grafo, non da un controllo; il ramo di fallback di un nodo di ramificazione è la causa più comune.
Metadati di sessione. I valori che invii in metadata alla creazione della sessione sono disponibili a ogni ramo come metadata.<key> e possono essere confrontati con un valore fisso o con un altro campo della sessione (ad esempio metadata.min_age <= Age). I numeri vengono confrontati come numeri, quindi 18 e "18" si comportano allo stesso modo.
Sandbox / modalità di test. Le condizioni dei rami, i metadati e i nodi di stato funzionano in sandbox esattamente come in produzione, e la sandbox non porta mai una sessione in revisione da sola. La differenza riguarda il documento: una sessione in sandbox contiene un documento fittizio senza stato / regione degli Stati Uniti, quindi le condizioni Region non possono corrispondere. Consulta cosa non contiene il documento fittizio per sapere come testare i flussi che dipendono dallo stato.
Reinvii. I nodi di ramificazione vengono valutati a ogni tentativo, compreso un reinvio. Quando rimandi una sessione per passaggi specifici, i rami e le azioni posti tra questi passaggi vengono eseguiti di nuovo mentre l’utente li completa nuovamente, sui dati del nuovo tentativo. Un utente che si sposta in una giurisdizione soggetta a restrizioni tra un tentativo e l’altro viene quindi instradato dal ramo che la copre, e un ramo che termina con un esito rifiutato chiude lì la sessione reinviata.
Come vedere quale ramo ha preso una sessione. Ogni decisione di ramificazione che il workflow prende durante l’esecuzione di una sessione, e ogni nodo di esito raggiunto, viene registrato nella cronologia degli eventi della sessione (Console session detail > Events, e GET /v3/session/{id}/decision/?include=events). Una riga Instradamento del flusso indica il nodo di ramificazione, la condizione che ha corrisposto e il nodo verso il quale la sessione è proseguita, oppure segnala che nessuna condizione ha corrisposto e che è stato seguito l’arco di fallback del nodo. Una riga Esito del flusso indica il nodo di stato che ha impostato lo stato della sessione. Quando un workflow porta una sessione in In revisione senza che alcuna funzionalità la segnali, quelle righe mostrano il percorso seguito, incluso qualsiasi arco di fallback e il nodo di esito a cui ha condotto. Le successive decisioni manuali non riscrivono questi eventi del workflow. Un input mancante è una possibile causa: le condizioni che richiedono un valore metadata.* presente non sono soddisfatte quando la chiave è stata omessa alla creazione della sessione. Le condizioni che verificano esplicitamente l’assenza di input, come is_empty o equals con not_defined, possono corrispondere a quella stessa chiave assente. L’arco di fallback viene seguito solo quando nessun ramo corrisponde, compreso un eventuale ramo else, e porta al nodo collegato all’uscita predefinita. Consulta eventi di sessione per i payload degli eventi.
Modelli di workflow: il tuo punto di partenza
Considera i modelli non come tipi rigidi, ma come punti di partenza predefiniti e intelligenti pensati per i casi d’uso più comuni. In modalità semplice sono subito pronti all’uso. In modalità avanzata costituiscono una base che puoi personalizzare in modo approfondito.
Modelli disponibili
1. Workflow KYC
La soluzione completa per l’onboarding di nuovi utenti e per soddisfare tutti i requisiti di conformità Know Your Customer (KYC).
- Inizia con: Verifica di base del documento d’identità.
- Funzionalità spesso aggiunte:
[+] Rilevamento della vitalità: Assicura che l’utente sia fisicamente presente e previene lo spoofing.[+] Confronto facciale 1:1: Confronta biometricamente il selfie dell’utente con la foto del suo documento d’identità.[+] Screening AML: Confronta gli utenti con le liste globali di sanzioni, PEP e notizie negative.[+] Verifica NFC: Aggiunge un livello di sicurezza di livello governativo leggendo i chip dei passaporti elettronici e delle carte d’identità elettroniche.[+] Prova di residenza (PoA): Verifica l’indirizzo di residenza dell’utente.[+] Verifica telefonica: Convalida la titolarità del numero di telefono come fattore aggiuntivo.[+] Verifica email: Convalida la titolarità dell’indirizzo email come fattore aggiuntivo.[+] Validazione su database: Convalida i dati rispetto a database governativi e di credito ufficiali.[+] Questionario: Raccoglie attestazioni strutturate e documenti di supporto tramite moduli personalizzabili.[+] Analisi dispositivo e IP: Analizza il rischio legato alla posizione e alla connessione.
2. Workflow di verifica dell’età adattivo
Un flusso a basso attrito e rispettoso della privacy per i servizi con limiti d’età.
- Inizia con: Stima dell’età basata su selfie.
- Logica chiave:
- Se l’età stimata è chiaramente superiore alla tua soglia (ad esempio, un’età stimata di 25+ per un servizio 18+), l’utente supera la verifica immediatamente.
- Se la stima è inferiore alla soglia o rientra in una “zona di tolleranza” (ad esempio, stimata tra 16-20 anni), puoi configurare il workflow in modo che attivi automaticamente un fallback alla verifica completa dell’identità per confermare la data di nascita esatta.
- Funzionalità spesso aggiunte:
[+] Analisi dispositivo e IP: Limita l’accesso in base alla posizione geografica.
3. Workflow di autenticazione biometrica
Un modo rapido e sicuro per riverificare gli utenti che tornano, senza chiedere di nuovo i loro documenti.
- Inizia con: Un controllo di Rilevamento della vitalità per confermare che l’utente è presente.
- Logica principale:
- Il sistema esegue un Confronto facciale tra il nuovo selfie acquisito dal vivo e il modello biometrico affidabile ottenuto dalla verifica KYC iniziale approvata dell’utente.
- Se l’utente ha già un volto memorizzato sotto lo stesso
vendor_data (volto acquisito durante un Rilevamento della vitalità approvato, foto del passaporto elettronico, ritratto del documento d’identità o volto di un profilo registrato), puoi omettere portrait_image quando crei la sessione e Didit riutilizza automaticamente il volto memorizzato. Altrimenti passa portrait_image (immagine codificata in Base64, massimo 2MB); senza l’uno o l’altro, la creazione della sessione non riesce con 400.
- Funzionalità spesso aggiunte:
[+] Verifica telefonica: Collega l’indirizzo a un numero di telefono verificato.[+] Verifica email: Convalida la titolarità dell’indirizzo email come fattore aggiuntivo.[+] Analisi dispositivo e IP: Segnala i tentativi di accesso sospetti da nuove posizioni.
4. Workflow di verifica dell’indirizzo
Un flusso dedicato per i casi in cui la Prova di residenza (PoA) è il requisito principale.
- Inizia con: L’invio da parte dell’utente di un documento di Prova di residenza (ad esempio, una bolletta di un servizio o un estratto conto bancario).
- Logica principale: La nostra AI estrae e convalida il nome e l’indirizzo dal documento.
- Funzionalità spesso aggiunte:
[+] Verifica telefonica: Collega l’indirizzo a un numero di telefono verificato.[+] Verifica email: Convalida la titolarità dell’indirizzo email come fattore aggiuntivo.[+] Analisi dispositivo e IP: Confronta l’indirizzo del documento con la geolocalizzazione attuale dell’utente per una maggiore sicurezza.
5. Workflow di verifica tramite questionario
Un flusso mirato per quando il tuo obiettivo principale è raccogliere attestazioni strutturate e documenti di supporto tramite moduli personalizzabili.
- Inizia con: Questionario.
- Logica principale: Il sistema presenta il questionario configurato (sezioni, contenuti tradotti, campi obbligatori, caricamenti).
- Funzionalità spesso aggiunte:
[+] Analisi dispositivo e IP: Aggiungi il contesto relativo alla posizione e alla connessione agli invii del questionario.
Personalizzazione completa
Ogni funzionalità all’interno di un workflow può essere ulteriormente personalizzata con parametri specifici per soddisfare i tuoi requisiti esatti. Esplora le impostazioni di ogni controllo nel generatore di workflow.
Regole di costruzione in base allo stato civile
In modalità avanzata puoi usare il campo OCR kyc.marital_status nei rami condizionali e nelle regole di stato personalizzate. Scegli il valore dal selettore dei campi in modo che la regola utilizzi l’enumerazione supportata e non testo libero. Se il documento non riporta lo stato civile, il valore è vuoto e si applica il tuo ramo di ripiego.
Il copilota del workflow può anche creare e configurare i passaggi di Validazione su database in un’unica azione. Quando gli chiedi di aggiungere questo controllo, specifica i paesi che ti servono: la console individua il servizio supportato per ciascun paese e mostra la configurazione salvata nell’area di lavoro.
Confronto tra modalità Semplice e Avanzata
Flusso di integrazione
Integrare un workflow orchestrato è semplice. Il tuo server crea una sessione con Didit, riceve un URL univoco e reindirizza l’utente a quell’URL. Didit gestisce il resto e comunica al tuo server i risultati tramite webhook.
Casi d’uso comuni
| Caso d’uso | Modello consigliato | Modalità consigliata | Funzionalità suggerite |
|---|
| Verifica dell’identità di base | KYC | Semplice | Rilevamento della vitalità, Confronto facciale |
| Onboarding ad alta sicurezza | KYC | Avanzata | NFC, Rilevamento della vitalità, Confronto facciale, AML, Verifica telefonica |
| Contenuti o servizi con limiti di età | Verifica dell’età adattiva | Semplice | Fallback su verifica dell’identità |
| Autenticazione degli utenti abituali | Autenticazione biometrica | Semplice | Analisi dispositivo e IP |
| Verifica dell’indirizzo | Prova di residenza | Semplice | Verifica telefonica |
| Onboarding per servizi finanziari | KYC | Avanzata | Rilevamento della vitalità, Confronto facciale, Prova di residenza, AML, Validazione su database |
| Conformità specifica per regione | KYC | Avanzata | Instradamento condizionale per paese, controlli diversi per regione |
| Verifica basata sul rischio | KYC | Avanzata | Rami condizionali basati sui punteggi di rischio, percorsi di escalation |
Per iniziare
- Non conosci ancora Didit? Inizia con la Modalità Semplice e un modello predefinito
- Hai bisogno di personalizzazione? Passa alla Modalità Avanzata per aggiungere logica condizionale
Contatta il nostro team commerciale per discutere configurazioni personalizzate dei workflow o per ricevere indicazioni sulla soluzione più adatta alle tue esigenze specifiche.
Ultima modifica il 7 novembre 2026
Inizia
Integrazione / SDK
Verifica degli utenti
Verifica aziendale
Monitoraggio delle transazioni
Changelog
