Vai al contenuto principale
Usa questi campi config all’interno di ogni elemento dell’array features per POST /v3/workflows/ e PATCH /v3/workflows/{settings_uuid}/.
L’API dei workflow v3 costruisce un workflow lineare basato su nodi a partire dall’array ordinato features. Invia le funzionalità nell’esatto ordine di esecuzione.
Il motore che esegue una funzionalità, quello di Didit o quello di un provider di terze parti, non è uno dei campi config qui sotto. Viene gestito tramite il Marketplace della console, che imposta per te provider_key e fallback_to_native nell’oggetto config della funzionalità.

Regole di validazione

  • OCR usa tutti i paesi e tutti i tipi di documento supportati quando config.documents_allowed è omesso, null o {}. Se invii un oggetto documents_allowed personalizzato, deve contenere almeno un paese valido e un tipo di documento abilitato. Ogni configurazione del documento può impostare sides a 1 per l’acquisizione solo del fronte o a 2 per l’acquisizione di fronte e retro.
  • QUESTIONNAIRE richiede config.questionnaire_uuid.
  • KYB_DOCUMENTS richiede config.kyb_required_document_groups.
  • SIGNATURE rifiuta signature_level: "qes" con qes_not_available finché le firme qualificate non saranno disponibili, e un nuovo passaggio con signature_level: "aes" con aes_not_available finché signature_availability.aes è false sul workflow. I suoi documenti devono esistere al momento della creazione di una sessione: con signature_documents_source impostato su workflow, il passaggio richiede documenti caricati nella console, e un passaggio senza documenti può restare in bozza ma non può essere attivato; con session, ogni chiamata di creazione deve inviare sign.documents.
  • FACE_MATCH deve venire dopo OCR nelle richieste di workflow semplici.
  • NFC e DATABASE_VALIDATION richiedono OCR quando compaiono nello stesso workflow. AML richiede uno tra OCR, KYB_REGISTRY o DOCUMENT_AI prima di sé; se davanti ha solo DOCUMENT_AI, il full_name da sottoporre a screening deve poter essere compilato, o da un campo Document AI a monte già associato a full_name, che viene mappato automaticamente, oppure da una voce esplicita config.aml_field_sources (vedi AML).
  • Le sottofunzionalità KYB, come KYB_DOCUMENTS e KYB_KEY_PEOPLE, richiedono KYB_REGISTRY più in alto nel workflow.
  • Un workflow è un workflow per persone (KYC) oppure un workflow per aziende (KYB), mai entrambi. Un workflow che usa una funzionalità KYB (KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE) può combinarla solo con AML, DOCUMENT_AI, QUESTIONNAIRE, PHONE_VERIFICATION, EMAIL_VERIFICATION, IP_ANALYSIS e SIGNATURE. Non può includere funzionalità riservate alle persone come OCR, LIVENESS, FACE_MATCH, NFC, PROOF_OF_ADDRESS, DATABASE_VALIDATION o AGE_ESTIMATION, e un workflow per persone non può includere funzionalità KYB. In un workflow per aziende DOCUMENT_AI confronta qualsiasi campo contrassegnato con is_full_name con l’azienda verificata, non con una persona. Per verificare le persone dietro un’azienda, crea un workflow KYC separato e fai riferimento ad esso dal nodo KYB_KEY_PEOPLE usando kyb_ubo_verification_workflow, kyb_officer_verification_workflow o kyb_shareholder_verification_workflow.
  • I campi di azione usano DECLINE, REVIEW o NO_ACTION, a meno che il campo qui sotto non indichi una restrizione.
  • I campi di punteggio e di soglia sono numeri da 0 a 100, a meno che non sia indicato un intervallo più ristretto.

Regole comuni sullo stato

Ogni funzionalità supporta un array facoltativo status_rules. Usalo per sovrascrivere lo stato della funzionalità quando una condizione su un campo è soddisfatta.
Leggi l’esempio sopra così: kyc.extra_fields.profession corrisponde in modo fuzzy a Soft. Engineer con un punteggio minimo di 80 → imposta lo stato della funzionalità su Declined. Per la Verifica dell’identità, punta ai valori estratti in extra_fields, come kyc.extra_fields.profession, alle date di validità della classe della patente di guida, come kyc.extra_fields.dl_class_code_b_from e kyc.extra_fields.dl_class_code_b_to, oppure ai codici di restrizione o informazione per classe, come kyc.extra_fields.dl_class_code_b_notes (colonna 12 delle patenti britanniche). Questi valori provengono dall’oggetto extra_fields del risultato OCR; non fanno parte di expected_details.
I campi dl_class_code_*_from e dl_class_code_*_to sono sempre una data ISO valida oppure sono assenti da extra_fields: Didit non restituisce mai testo OCR illeggibile in un campo data. Se la cella della tabella delle classi non può essere letta, il campo viene omesso invece di essere inviato come stringa grezza. Usa quindi l’operatore is_empty per instradare le date di classe illeggibili, invece di presumere che il campo sia sempre presente.
Per i campi data, usa value_type: "relative_date" con un oggetto per il valore nella forma { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }. Ad esempio, operator: "less_than" con { "direction": "past", "amount": 3, "unit": "years" } corrisponde alle date più vecchie di tre anni da oggi.

Confronto con un passaggio specifico

Un workflow basato su un grafo può eseguire la stessa funzionalità più di una volta, ad esempio tre passaggi di Verifica dell’identità. Con value_type: "field", aggiungi @<node_id> al valore per leggerlo da un passaggio specifico. Il nodo di riferimento deve essere un passaggio di una funzionalità che viene sempre eseguito prima del passaggio della regola, su ogni percorso che vi arriva, oppure il passaggio della regola stesso. Un valore senza il suffisso viene letto dal passaggio della regola.
Leggi questa regola, impostata sul terzo passaggio di Verifica dell’identità, così: il kyc.full_name di questo passaggio corrisponde in modo fuzzy al nome completo letto dal passaggio ocr_1 con un punteggio minimo di 80 → imposta lo stato della funzionalità su Declined. Nella console, il selettore delle variabili elenca ogni passaggio idoneo con il suo numero sul canvas e salva il suffisso per te.

OCR / Verifica dell’identità

Valore della funzionalità: OCR.
La vitalità del documento si configura con le sei soglie document_liveness_* indicate sopra, non con campi di azione per segnale. portrait_replacement_action, printed_copy_action e screen_capture_action sono impostazioni a livello di account e non sono accettate in una configurazione di funzionalità del workflow: l’API rimuove le chiavi di configurazione sconosciute al salvataggio, quindi inviarle non ha alcun effetto. Ogni segnale ha una soglia di rifiuto e una soglia di revisione su una scala da 0 a 100, dove un punteggio più alto indica che il documento è più probabilmente autentico.
Esempio:

Metodi per paese

methods è indicizzato per codice paese ISO 3166-1 alpha-3. Ogni paese prevede fino a tre oggetti metodo; ciò che si omette assume il valore predefinito.
wallet.on_failure può essere fallback_to_document, decline o retry. retry (solo per wallet, con acquisizione del documento disattivata per il paese) permette a un utente il cui accesso non è stato completato nel passaggio del wallet di riprovare; la sessione non viene mai rifiutata per questo motivo e resta aperta finché l’utente non completa il processo o finché non scade. Gli interruttori id_lookup accettano solo fallback_to_document o decline. Per tenere i documenti fuori dalla prima schermata e proporli solo quando un wallet o una ricerca non va a buon fine, imposta document.fallback_only. L’esempio usa la Finlandia, dove la Finnish Trust Network viene per prima e l’acquisizione del documento è il ripiego. La Finlandia richiede inoltre che i suoi tipi di documento siano abilitati in documents_allowed (ad esempio passaporto e carta d’identità), così il ripiego ha documenti da proporre.
Entrambe le ricerche sopra risultano available nel catalogo attuale, quindi questa configurazione viene salvata così come scritta. Il blocco del wallet è stato escluso da questo esempio di proposito: la configurazione di un wallet viene salvata solo in un paese in cui il catalogo lo indica come available, e wallet.enabled: true in qualsiasi altro paese viene rifiutato e fa fallire l’intero salvataggio, configurazione delle ricerche compresa. Dove il catalogo indica un wallet come available, aggiungilo a quel paese:
Validazione applicata dall’API al salvataggio:
  • Un codice paese sconosciuto, una chiave sconosciuta all’interno di un paese o una chiave sconosciuta all’interno di un metodo vengono rifiutati: nulla viene eliminato in silenzio.
  • Un paese in cui non è attivato alcun metodo viene rifiutato: nessuno in quel paese potrebbe completare la verifica.
  • Un wallet o una ricerca possono ricadere sull’acquisizione del documento solo se l’acquisizione del documento è attiva per quel paese. fallback_to_document in un paese in cui document.enabled è false porta al rifiuto a runtime, perché non c’è un’alternativa a cui ricorrere.
  • document.fallback_only: true viene rifiutato con HTTP 400, a meno che document.enabled non sia true e almeno un wallet o una ricerca dell’identità in quel paese ricada sull’acquisizione del documento.
L’attuale implementazione di staging applica id_lookup.response_fields all’output di confronto, al genere facoltativo e ai ritratti del registro conservati. I campi di identità obbligatori restano parte del record della verifica. Non è una garanzia che ogni payload intermedio del provider venga escluso dal trattamento. Il rilascio in produzione di questa modifica non è stato verificato: prima di affidarti alla selezione dei campi per i requisiti di conservazione, verifica il comportamento nel tuo ambiente di destinazione.
Leggi il catalogo delle funzionalità prima di scrivere methods, nella scheda Paesi della console oppure con lo strumento MCP didit_workflow_get_id_verification_methods_catalog. Comportamento, copertura e fatturazione sono descritti in Metodi di verifica dell’identità.

NFC / ePassport

Valore della funzionalità: NFC.

Rilevamento della vitalità

Valore della funzionalità: LIVENESS.

Confronto facciale

Valore della funzionalità: FACE_MATCH.

Stima dell’età

Valore della funzionalità: AGE_ESTIMATION.

Verifica telefonica

Valore della funzionalità: PHONE_VERIFICATION. La Verifica telefonica è disattivata finché l’organizzazione non completa la prima ricarica.
L’arricchimento con l’intelligence sul telefono è un componente aggiuntivo facoltativo. Quando phone_enrichment_enabled è true, ogni verifica telefonica completata viene arricchita con l’intelligence sul telefono ed è addebitata $0.05 per richiesta oltre al costo standard della verifica telefonica. Le azioni basate sul punteggio si attivano solo quando il punteggio di arricchimento è disponibile; le azioni basate sull’indice di affidabilità, sul tipo di telefono e sulla portabilità si applicano non appena l’arricchimento viene eseguito.Il controllo della presenza sui social è un secondo componente aggiuntivo, separato dal primo. Quando phone_social_enabled è true, ogni verifica telefonica completata segnala anche su quali piattaforme online è registrato il numero (messaggistica, social media, e-commerce e servizi professionali) ed è addebitata $0.05 per richiesta. Può essere attivato con o senza phone_enrichment_enabled: i due componenti aggiuntivi hanno prezzi e addebiti indipendenti. Una ricerca che non trova il numero su nessuna delle piattaforme coperte è una risposta valida e fatturabile e attiva phone_no_social_presence_action. Usa phone.social_profiles_registered (il numero di piattaforme su cui il numero è registrato) per ramificare il risultato in un grafo di workflow.

Verifica email

Valore della funzionalità: EMAIL_VERIFICATION.
L’arricchimento con intelligence delle email è un componente aggiuntivo facoltativo. Quando email_enrichment_enabled è true, ogni verifica email completata viene arricchita con intelligence delle email e fatturata $0.05 per richiesta, in aggiunta al costo standard della verifica email. L’azione basata sul punteggio ha effetto quando il punteggio di arricchimento è disponibile; le azioni sulle violazioni si applicano non appena l’arricchimento viene eseguito.La verifica della presenza sui social è un secondo componente aggiuntivo, separato. Quando email_social_enabled è true, ogni verifica email completata riporta anche su quali piattaforme online è registrato l’indirizzo (provider di posta elettronica, social media, servizi professionali, di e-commerce e di intrattenimento) ed è fatturata $0.05 per richiesta. Può essere attivata con o senza email_enrichment_enabled: i due componenti aggiuntivi hanno prezzi e fatturazione indipendenti. Una ricerca che non trova l’indirizzo su nessuna delle piattaforme coperte è una risposta valida e fatturabile e attiva email_no_social_presence_action. Usa email.social_profiles_registered (il numero di piattaforme su cui l’indirizzo è registrato) per diramare il risultato in un grafo del workflow.

Validazione su database

Valore della funzionalità: DATABASE_VALIDATION. Esempio:
database_validation_countries è ciò che consente a questo passaggio di eseguire controlli. Una funzionalità DATABASE_VALIDATION salvata senza di esso viene accettata e poi non esegue alcun controllo, quindi invia sempre almeno un paese con almeno un ID di servizio.
Un ID di servizio che il passaggio non può eseguire viene rifiutato con un 400 che lo indica e spiega il motivo, e non viene salvato nulla. Questo vale per un ID non presente nel catalogo, un ID appartenente a un altro paese, un servizio non ancora disponibile e un servizio offerto solo tramite l’endpoint autonomo POST /v3/database-validation/. Un servizio i cui input non sono forniti da nessun passaggio precedente viene rifiutato allo stesso modo, con l’elenco degli input mancanti. Un servizio già presente nel workflow salvato che non può più essere eseguito viene rimosso quando salvi di nuovo. Ad esempio, questo workflow dell’Argentina legge il numero di DNI e il sesso dalla Verifica dell’identità e li confronta con RENAPER senza selfie:
Usa invece arg_renaper dopo un passaggio LIVENESS per confrontare anche il selfie con la foto che RENAPER conserva. Per il punteggio di corrispondenza facciale e la soglia, consulta RENAPER.

Verifica del conto bancario

Valore della funzionalità: BANK_VERIFICATION. L’utente verifica un conto bancario e il titolare dichiarato dalla banca viene confrontato con l’identità stabilita da un passaggio precedente del workflow. L’utente lo fa con uno di due metodi: l’accesso bancario (open_banking), in cui accede alla propria banca, oppure il controllo del conto (account_lookup), in cui digita i dati del conto e la banca conferma il nome associato. bank_method_order e il methods di ciascun paese scelgono quali metodi un paese offre e quale viene per primo; vedi Metodi di verifica bancaria. Il passaggio produce delle prove (un punteggio sul nome del titolare, il confronto che lo ha prodotto, i codici delle motivazioni), e le chiavi bank_*_action trasformano tali prove in uno stato. Due elementi determinano se il nodo esegue un’operazione. bank_countries è una lista di autorizzazioni, quindi una mappa vuota non offre alcuna banca ed esegue nessun controllo. Inoltre il titolare deve avere qualcosa con cui essere confrontato: inserisci prima un passaggio OCR, DATABASE_VALIDATION o QUESTIONNAIRE, invia expected_details alla creazione della sessione, oppure mappa tu stesso i campi con bank_field_sources. Senza nessuno di questi, la titolarità può essere solo unknown, che è ciò che decide bank_reference_identity_missing_action.
La verifica del conto bancario è ancora in fase di rilascio, quindi un nodo BANK_VERIFICATION viene accettato solo su un account in cui è stato abilitato. Altrove il salvataggio viene rifiutato e lo indica. Anche il percorso che esegue il passaggio non si configura qui: lo impostano per te la coppia provider_key e fallback_to_native, che il Marketplace della console imposta per te.

Collegamento di un conto

Quando l’utente non può verificare

L’utente può sempre continuare senza una banca, e il passaggio non lo lascia mai bloccato. Vedi Quando la persona non può verificare la propria banca. Ciò che accade alla sessione quando l’utente prosegue è determinato da bank_unsupported_action, bank_attempts_exhausted_action o bank_skipped_action, a seconda del motivo per cui ha proseguito, a meno che un tentativo valutato in precedenza non abbia già deciso il passaggio: vedi Azioni del verdetto.

Confronto del titolare

Verifica del conto

Queste chiavi si applicano solo alla verifica del conto. L’accesso bancario mantiene le proprie corrispondenze quasi esatte e il proprio bank_max_attempts.

Dati finanziari

bank_expected_currencies funziona da solo con il consenso predefinito ownership. Le altre tre chiavi leggono dati finanziari reali, quindi ognuna richiede il corrispondente ambito di consenso in bank_scopes, e il salvataggio viene rifiutato senza di esso.

Cosa viene memorizzato

Azioni di esito

Ogni chiave qui elencata accetta DECLINE, REVIEW o NO_ACTION, salvo che sia contrassegnata come limitata, e ricade sul valore predefinito indicato sotto quando la si omette o si invia null. Nessuna evidenza di titolarità non positiva approva per impostazione predefinita, e solo una prova dimostrabile contro l’utente porta al rifiuto.

Altri controlli

Queste chiavi sono facoltative. Ogni chiave di azione accetta DECLINE, REVIEW o NO_ACTION. Esempio di oggetto config, per un account in cui la Verifica bancaria è attiva e il percorso selezionato copre il paese che indichi:
bank_countries è ciò che fa funzionare questo passaggio, e viene verificato rispetto al percorso su cui gira il nodo, non rispetto a un elenco globale. Un paese in cui quel percorso non può stabilire l’assetto proprietario del conto viene rifiutato al salvataggio e indicato nell’errore, quindi leggi l’errore invece di presumere che il paese sia stato accettato e verrà saltato in fase di esecuzione.

AML

Valore della funzionalità: AML. Per lo screening delle persone nel KYC, usa questi campi: Per lo screening delle aziende nel KYB, usa questi campi:

Screening di un’entità estratta da un passaggio Document AI

Un passaggio AML legge normalmente chi sottopone a screening dal passaggio OCR (una persona) o dal passaggio KYB_REGISTRY (un’azienda). Un workflow il cui unico passaggio di estrazione è DOCUMENT_AI, cioè documenti non standardizzati come un certificato fiscale o un atto costitutivo, non ha nessuno dei due, quindi deve indicare da dove provengono gli input di ogni screening. Esempio: screening dell’azienda indicata in un’acta constitutiva messicana, senza alcun documento d’identità nel workflow:
Senza un passaggio OCR e senza un passaggio KYB_REGISTRY prima di esso, un passaggio AML deve poter compilare full_name: senza un nome non c’è ricerca presso il provider. Un workflow che non mappa nulla, o che mappa una chiave Document AI che nessun passaggio a monte estrae, viene rifiutato al salvataggio invece di essere salvato e lasciato a eseguire uno screening vuoto. La precisione dell’AML dipende direttamente da quanti identificatori fornisci: uno screening basato solo sul nome è ciò che genera un alto volume di falsi positivi.

Analisi dispositivo e IP

Valore della funzionalità: IP_ANALYSIS. Esempio:
Usa recovered_device_action separatamente da duplicated_device_action quando vuoi monitorare i dispositivi recuperati con alta affidabilità prima di rifiutarli automaticamente. Questo è utile durante il rilascio, perché le corrispondenze dei dispositivi recuperati sono progettate per individuare reti fraudolente, ma vanno comunque calibrate sul tuo traffico.

Verifica della posizione

Valore della funzionalità: GEOLOCATION. Verifica dove si trova la persona durante la verifica, in base alla posizione del dispositivo o alla posizione IP della connessione, confrontandola con le aree consentite e bloccate, la posizione IP e l’indirizzo del documento. Consulta Verifica della posizione per il comportamento del passaggio e il relativo report per i campi della decisione. Inseriscilo dopo Verifica dell’identità o Prova di residenza se vuoi la distanza dall’indirizzo del documento, perché la distanza viene misurata solo quando è presente un indirizzo registrato. Con geolocation_position_source non impostato, la distanza dalla posizione IP richiede un passaggio Analisi dispositivo e IP nello stesso workflow. Tutte le chiavi sono facoltative: un passaggio con config vuoto chiede al dispositivo una posizione con precisione di 250 m, non più vecchia di 120 secondi, concede alla persona 3 tentativi e non applica alcuna regola sulle aree. Ogni rilevamento ha una propria chiave di azione; una chiave di azione lasciata non impostata assume il valore predefinito del geolocation_preset scelto oppure, se non ne hai scelto alcuno, il valore predefinito per chiave indicato di seguito. Una posizione incerta o negata viene impostata su REVIEW per impostazione predefinita, mai su DECLINE, perché un’autorizzazione negata o un raggio ampio non sono prova di frode. Un’azione impostata esplicitamente prevale sempre sul preset. Una sfida riprodotta (LOCATION_REPLAY_DETECTED) e un’attestazione del dispositivo non riuscita (LOCATION_INTEGRITY_FAILED) causano sempre un rifiuto e non hanno una chiave di azione.

Forme delle aree

Ogni elemento di geolocation_areas ha un id (da 1 a 64 caratteri di A-Z a-z 0-9 _ -, univoco nell’elenco), un label facoltativo (fino a 80 caratteri), un type pari a allowed o blocked, e un kind che determina la forma. Un elenco contiene al massimo 50 aree e richiede almeno un’area allowed quando is_geolocation_geofencing_enabled è true. geolocation_areas e geolocation_geofencing_by_country non possono essere inviati insieme, e geolocation_refusal_path: "end_session" richiede che geolocation_permission_denied_action sia REVIEW o DECLINE. L’API rifiuta un’area che non potrebbe mai corrispondere, ad esempio una regione di un paese senza confini pubblicati, invece di salvarla. Esempio:

Prova di residenza

Valore della funzionalità: PROOF_OF_ADDRESS.

Questionario

Valore della funzionalità: QUESTIONNAIRE.

Registro KYB

Valore della funzionalità: KYB_REGISTRY. kyb_registry_fields_config associa ogni chiave di campo configurabile a {"enabled": bool, "required": bool}. enabled: false nasconde il campo, enabled: true, required: false lo mostra come facoltativo, e enabled: true, required: true lo rende obbligatorio all’invio. company_name, country_code e region sono sempre mostrati e obbligatori e non possono essere configurati. Quando l’oggetto viene omesso, è null oppure è {}, si applica il valore predefinito: solo incorporation_date è obbligatorio e tutti gli altri campi sono facoltativi.
Chiavi di campo configurabili: registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. Vedi campi configurabili del modulo di registro per il comportamento lato utente finale e validazione della partita IVA e dell’identificativo fiscale per come vengono controllati vat_number e tax_number.

Documenti KYB

Valore della funzionalità: KYB_DOCUMENTS.

Persone chiave KYB

Valore della funzionalità: KYB_KEY_PEOPLE.

Document AI

Valore della funzionalità: DOCUMENT_AI. Richiede all’utente uno o più documenti ed estrae con un modello di visione i campi che definisci. Ogni campo configurato diventa un valore utilizzabile per le diramazioni, document_ai.<key>, e l’esito del passaggio è document_ai.status. Ogni voce di document_ai_documents è un documento: Ogni voce di fields di un documento è un campo: Esempio:

E-signature

Valore della funzionalità: SIGNATURE. Consente alla persona verificata o alle persone chiave di un’azienda di firmare i documenti, al livello Simple (predefinito) o Advanced (AES). Inseriscila dopo i passaggi che verificano il firmatario: Verifica dell’identità e, per il codice, Verifica email o Verifica telefonica. Vedi Firma elettronica. I campi su un documento del workflow si inseriscono nell’editor dei modelli della console. Per i documenti di sessione, inviali in sign.documents[].fields e invia i valori dei campi api.<key> in sign.field_values. Vedi Crea sessione. Esempio, per documenti inviati con ogni sessione:
Ultima modifica il 7 novembre 2026