Progettazione di un criterio di rischio

Cosa fa

Il Progettatore dei criteri di flusso di lavoro consente di decidere come una verifica viene approvata, rifiutata o inviata alla revisione manuale: visivamente, senza codice. Si trascinano blocchi di regole su una tela, si impostano le condizioni sui segnali prodotti da ogni verifica (punteggio di affidabilità, corrispondenza con le sanzioni, controlli sui documenti, paese del richiedente, rischio di rete, prova della fotocamera in tempo reale e altro) e li si collegano agli esiti Approva, Rifiuta, Inoltra oppure Richiedi la verifica dal vivo.

Ogni organizzazione parte da un criterio predefinito integrato, che riproduce esattamente la decisione standard basata sul punteggio di affidabilità a 17 fattori di Certivant. Quindi attivare la funzionalità non cambia nulla finché non si sceglie di personalizzarla: i risultati esistenti restano identici.

Prima di iniziare

• Il piano deve includere il Progettatore dei criteri di flusso di lavoro (Pro o superiore). Se la voce Criteri di verifica dell'identità nel menu Sviluppatore mostra il badge "Richiede Pro", chiedere al proprietario dell'account di effettuare l'upgrade: consultare Fatturazione e crediti.
• Occorre conoscere come viene calcolata una verifica, per sapere su quali segnali scrivere le regole. Consultare Esaminare le richieste di verifica KYC e KYB.
• Pubblicare un criterio cambia come vengono decise le verifiche future per l'intera organizzazione. Non decide di nuovo le richieste passate.

Concetti chiave

• Nodi: i blocchi sulla tela. Un nodo Inizio avvia il flusso; i nodi Condizione contengono le regole; i nodi Fine sono gli esiti (Approvata / Rifiutata / Inoltrata / Revisione manuale / Richiedi la verifica dal vivo / Passaggio a un altro criterio). I nodi di azione (Modulo, Convalida ID, Email, SMS, Webhook, Conferenza dal vivo) documentano i passaggi di orchestrazione attorno alla decisione: per eseguire passaggi, usare Workflow di automazione.
• Condizioni: un nodo Condizione verifica i segnali della verifica, per esempio overallScore >= 75, sanctions.isMatch = true, applicant.country IN ["IR","KP","SY"] oppure redFlags CONTAINS "network_vpn_detected". È possibile combinare i test con AND / OR / NOT e annidare gruppi, incluse condizioni concatenate dopo altre condizioni sulla tela.
• Vince la prima corrispondenza: le regole vengono valutate dall'alto verso il basso a partire dall'Inizio; la prima Condizione il cui test è vero fornisce la decisione. Un ramo finale raccoglie tutto il resto (in caso di dubbio passa a Inoltra, mai a un'approvazione silenziosa).
• Motivazioni: assegnare a una condizione una motivazione (per esempio "Paese ad alto rischio"). Viene registrata con la decisione, così il revisore vede perché la richiesta è stata inoltrata, non solo quale regola è scattata.
• Versioni: ogni criterio salvato è una bozza finché non viene pubblicato. Pubblicare congela quella versione (diventa immutabile) e la rende attiva; la versione precedentemente attiva di quel criterio viene archiviata. Per modificare un criterio pubblicato, fare clic su Nuova versione: così si dispone sempre di una cronologia completa e verificabile.
• Dove si applica: un criterio pubblicato decide le richieste di ogni modulo che lo associa. Rendere un criterio predefinito dell'organizzazione per fargli decidere anche tutte le altre richieste, comprese quelle create tramite API. Senza nessuno dei due, decide il criterio predefinito integrato di Certivant.

Passaggi

Cosa avvia il criterio

Un criterio di flusso di lavoro viene eseguito automaticamente: non c'è un pulsante "esegui" separato, né lo si avvia a mano. Due elementi lo attivano:

1. La pubblicazione lo arma. Quando si pubblica un criterio, quella versione diventa attiva (una sola versione attiva per criterio; la pubblicazione archivia la precedente). Decide le richieste di ogni modulo che lo associa, e anche tutte le altre richieste una volta reso il predefinito dell'organizzazione.
2. Ogni nuova verifica lo fa scattare. Ogni volta che viene eseguita una verifica (il richiedente invia i propri documenti, si invia una richiesta di verifica oppure un revisore usa Riverifica), Certivant esegue l'intera pipeline dei controlli (OCR, biometria, sanzioni, frode, controlli di rete e di acquisizione, punteggio di affidabilità a 17 fattori) e poi passa i risultati al criterio decisionale. L'esito del criterio (Approva / Rifiuta / Inoltra / Richiedi la verifica dal vivo) diventa lo stato finale della richiesta.

Quale criterio decide una richiesta, in quest'ordine:

1. il criterio associato dal modulo;
2. altrimenti il criterio predefinito dell'organizzazione;
3. altrimenti il predefinito integrato di Certivant.

Un criterio associato o predefinito senza versione attiva (per esempio perché lo si è archiviato) ricade sul predefinito integrato, mai su un altro criterio.

flowchart LR
    A[Applicant submits<br/>verification] --> B[Checks run:<br/>OCR · biometrics ·<br/>sanctions · fraud]
    B --> C[17-factor<br/>trust score]
    C --> D{Active policy<br/>evaluates the<br/>score + signals}
    D -->|first matching rule| E[Approve]
    D --> F[Reject]
    D --> G[Escalate to<br/>manual review]

Come cambia le proprie verifiche

Dopo la pubblicazione, ogni nuova verifica viene decisa dal criterio attivo invece che dal predefinito integrato. Per ogni richiesta, Certivant registra:

• l'id, il nome e la versione del criterio che l'ha decisa, e
• l'elenco delle regole scattate,

entrambi nella traccia di audit della richiesta e nel payload del webhook (data.policy su kyc.request.approved / rejected / escalated). In questo modo i sistemi a valle vedono quale criterio e quali regole hanno guidato ogni decisione. Consultare Webhook.

Quando una salvaguardia successiva modifica l'esito del criterio (una richiesta KYB ancora in attesa del controllo nel registro, oppure una richiesta in modalità di test), la traccia di audit registra la sostituzione e lo stato finale, così la traccia non mostra mai una decisione che non ha retto.

Richiedere la verifica dal vivo

Scegliere Richiedi la verifica dal vivo come esito di un nodo Fine per inviare una richiesta a una videochiamata invece di decidere solo sui documenti: per esempio quando il punteggio è al limite, il richiedente usa una VPN oppure il selfie non è risultato provenire dalla fotocamera in tempo reale:

overallScore >= 60 AND overallScore < 80 → Richiedi la verifica dal vivo
network.vpn = true OR capture.tokenMismatch = true → Richiedi la verifica dal vivo

La richiesta passa a Inoltrata, e la sua pagina mostra un banner Verifica d'identità dal vivo richiesta con la motivazione della regola, così il team sa di dover prenotare la chiamata. Il webhook riporta data.policy.decision = "live_verification" e liveVerificationRequired: true.

Per prenotare la chiamata automaticamente, aggiungere un Workflow di automazione sul trigger Verifica dal vivo richiesta con l'azione Pianifica una verifica dell'identità dal vivo. Quando il conduttore registra una decisione nella chiamata, la richiesta viene approvata o rifiutata e si attivano i consueti eventi di approvazione / rifiuto. Riverificando in seguito, il criterio può leggere l'esito della chiamata, per esempio liveVerification.hostDecision = "approved", così una regola può approvare una richiesta che ha superato il controllo dal vivo.

Segnali che puoi verificare

Oltre al punteggio di affidabilità e ai risultati per singolo controllo (checks.*, sanctions.*, document.*, applicant.*), una condizione può leggere:

Un campo che la richiesta non possiede (nessuna chiamata tenuta, nessun codice a barre letto...) non corrisponde mai, nemmeno a !=, NOT IN o NOT CONTAINS. Quindi document.issuingCountry != "US" è falso quando non è stato letto alcun documento, invece di risultare vero in silenzio.

Opzioni e campi

Risoluzione dei problemi

Non vedo "Criteri di flusso di lavoro" nel menu

È nel menu Sviluppatore ed è una funzionalità Pro. Se la voce Criteri di verifica dell'identità mostra il badge "Richiede Pro", il piano non la include: chiedere al proprietario di effettuare l'upgrade in Fatturazione e crediti. Se manca del tutto il menu Sviluppatore, potrebbe non trattarsi di un account da amministratore o proprietario; se la voce è semplicemente scomparsa, aggiornare la pagina: il controllo del piano è memorizzato nella cache per alcuni minuti.

Non posso modificare un criterio: i campi sono bloccati

Le versioni pubblicate sono immutabili per progettazione. Aprire la versione e fare clic su Nuova versione nella barra degli strumenti: copia il criterio nella bozza modificabile successiva. Apportare le modifiche e pubblicare: la versione precedente continua a decidere finché non lo si fa.

Il pulsante Simula è disattivato

La Simulazione richiede che il criterio sia stato salvato almeno una volta. Fare clic su Salva bozza; da quel momento la Simulazione esegue ciò che è sulla tela, comprese le modifiche non salvate.

Il mio criterio pubblicato non decide nulla

Un criterio pubblicato decide solo le richieste dei moduli che lo associano. Associarlo nel modulo (impostazioni del modulo → Criterio decisionale), oppure fare clic su Usa per tutte le richieste nell'editor per renderlo il predefinito dell'organizzazione.

Una richiesta è stata inoltrata con "Verifica dell'identità dal vivo richiesta"

Il criterio ha corrisposto a una regola Richiedi la verifica dal vivo: il banner sulla richiesta mostra la motivazione della regola. Prenotare una chiamata dal vivo dalla pagina della richiesta, oppure automatizzarla con un workflow (consultare Richiedere la verifica dal vivo).

Una condizione mostra un badge rosso "non valido"

L'espressione non può essere interpretata. Aprire la condizione, verificare il nome del campo e l'operatore, e controllare che gli elenchi di valori siano separati da virgole. La scheda DSL non elaborato mostra l'esatto messaggio del parser.

Come avvio il mio workflow / quando viene eseguito?

Non va avviato manualmente. Una volta pubblicato e associato a un modulo (oppure reso predefinito dell'organizzazione), viene eseguito automaticamente su ogni nuova verifica che copre: quando un richiedente invia i documenti, quando si invia una richiesta di verifica o quando un revisore usa Riverifica. Consultare Cosa avvia il criterio.

Ho pubblicato ma sembra che non accada nulla

Tre cause comuni. Primo, un criterio decide solo le verifiche che vengono eseguite dopo che è diventato attivo: le richieste esistenti, già completate, non vengono toccate (vedi sotto). Avviare una nuova verifica (oppure Riverificare una esistente) per vedere il proprio criterio decidere. Secondo, verificare che la versione modificata abbia davvero lo stato attivo nella tabella della dashboard: salvare una bozza non la attiva; occorre Pubblicare. Terzo, controllare che il modulo della richiesta associ il criterio, oppure che il criterio sia il predefinito dell'organizzazione.

La pubblicazione non ha cambiato nulla per una richiesta in corso

I criteri decidono solo le verifiche nuove. Una richiesta già inviata mantiene la decisione presa dal criterio attivo in quel momento. Rieseguirla solo se si intende deciderla di nuovo: aprire la richiesta e usare Riverifica.

Cronologia delle versioni, ripristino e test A/B

Ogni salvataggio di un criterio pubblicato avvia una nuova versione in bozza; Pubblica la congela come versione immutabile e archivia quella che sostituisce. Ogni decisione registra l'esatto id e la versione del criterio che l'ha presa (sulla richiesta, nel registro di audit e nel blocco policy del payload del webhook), quindi si può sempre sapere quale versione ha deciso una verifica.

Fare clic su Versioni e test A/B nell'intestazione dell'editor per:

• Vedere ogni versione del criterio (bozza, attiva e archiviata) e aprirne una in sola lettura.
• Ripristinare come nuova bozza: copia una versione precedente in una nuova bozza dello stesso nome. Pubblicarla quando la si vuole attiva. Non viene mai modificato nulla di ciò che era pubblicato.
• Eseguire un test A/B: confronta la versione attiva (variante A) con una sfidante (variante B, una bozza o una versione precedente dello stesso criterio). Scegliere la quota di verifiche nuove che va a B (0–100 %); il resto resta su A. La suddivisione è automatica e stabile: una verifica finisce sempre sulla stessa variante, anche se viene rieseguita.

Durante un test la bozza sfidante è congelata (modificarla invaliderebbe il confronto). La tabella Risultati mostra, per ciascuna variante, quante verifiche sono state instradate, la quota approvata, rifiutata e inoltrata, e quante hanno raggiunto una decisione. Il confronto dei tassi di approvazione indica "significativo" solo quando ciascuna variante ha almeno 30 verifiche decise. Per adottare B, pubblicare la sfidante: il test termina automaticamente. Per abbandonarlo, fare clic su Interrompi test; ogni nuova verifica torna alla versione attiva.

Correlati

• Esaminare le richieste KYC e KYB: da qui provengono i segnali che le regole verificano.
• Webhook: il blocco policy aggiunto agli eventi di decisione.
• Workflow di automazione: reagire alla decisione: prenotare la chiamata dal vivo, notificare, instradare.
• Verifica dell'identità dal vivo: la videochiamata richiesta da una regola Richiedi la verifica dal vivo.
• Fatturazione e crediti: effettuare l'upgrade per sbloccare il Progettatore dei criteri di flusso di lavoro.