config all’interno di ogni elemento dell’array features per POST /v3/workflows/ e PATCH /v3/workflows/{settings_uuid}/.
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
OCRusa tutti i paesi e tutti i tipi di documento supportati quandoconfig.documents_allowedè omesso,nullo{}. Se invii un oggettodocuments_allowedpersonalizzato, deve contenere almeno un paese valido e un tipo di documento abilitato. Ogni configurazione del documento può impostaresidesa1per l’acquisizione solo del fronte o a2per l’acquisizione di fronte e retro.QUESTIONNAIRErichiedeconfig.questionnaire_uuid.KYB_DOCUMENTSrichiedeconfig.kyb_required_document_groups.SIGNATURErifiutasignature_level: "qes"conqes_not_availablefinché le firme qualificate non saranno disponibili, e un nuovo passaggio consignature_level: "aes"conaes_not_availablefinchésignature_availability.aesèfalsesul workflow. I suoi documenti devono esistere al momento della creazione di una sessione: consignature_documents_sourceimpostato suworkflow, il passaggio richiede documenti caricati nella console, e un passaggio senza documenti può restare in bozza ma non può essere attivato; consession, ogni chiamata di creazione deve inviaresign.documents.FACE_MATCHdeve venire dopoOCRnelle richieste di workflow semplici.NFCeDATABASE_VALIDATIONrichiedonoOCRquando compaiono nello stesso workflow.AMLrichiede uno traOCR,KYB_REGISTRYoDOCUMENT_AIprima di sé; se davanti ha soloDOCUMENT_AI, ilfull_nameda sottoporre a screening deve poter essere compilato, o da un campo Document AI a monte già associato afull_name, che viene mappato automaticamente, oppure da una voce esplicitaconfig.aml_field_sources(vedi AML).- Le sottofunzionalità KYB, come
KYB_DOCUMENTSeKYB_KEY_PEOPLE, richiedonoKYB_REGISTRYpiù 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 conAML,DOCUMENT_AI,QUESTIONNAIRE,PHONE_VERIFICATION,EMAIL_VERIFICATION,IP_ANALYSISeSIGNATURE. Non può includere funzionalità riservate alle persone comeOCR,LIVENESS,FACE_MATCH,NFC,PROOF_OF_ADDRESS,DATABASE_VALIDATIONoAGE_ESTIMATION, e un workflow per persone non può includere funzionalità KYB. In un workflow per aziendeDOCUMENT_AIconfronta qualsiasi campo contrassegnato conis_full_namecon 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 nodoKYB_KEY_PEOPLEusandokyb_ubo_verification_workflow,kyb_officer_verification_workflowokyb_shareholder_verification_workflow. - I campi di azione usano
DECLINE,REVIEWoNO_ACTION, a meno che il campo qui sotto non indichi una restrizione. - I campi di punteggio e di soglia sono numeri da
0a100, a meno che non sia indicato un intervallo più ristretto.
Regole comuni sullo stato
Ogni funzionalità supporta un array facoltativostatus_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.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à. Convalue_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.
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.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.
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_documentin un paese in cuidocument.enabledèfalseporta al rifiuto a runtime, perché non c’è un’alternativa a cui ricorrere. document.fallback_only: trueviene rifiutato con HTTP 400, a meno chedocument.enablednon siatruee almeno un wallet o una ricerca dell’identità in quel paese ricada sull’acquisizione del documento.
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:
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:
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 propriobank_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 accettaDECLINE, 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 accettaDECLINE, 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:
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 passaggioOCR (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:
Analisi dispositivo e IP
Valore della funzionalità:IP_ANALYSIS.
Esempio:
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 digeolocation_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.
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: