Inizia
Integrazione / SDK
Verifica degli utenti
Verifica aziendale
Monitoraggio delle transazioni
ChangelogImpostazioni generali
Soglie di punteggio
Le soglie di punteggio determinano come il punteggio di rischio cumulativo delle regole corrispondenti viene associato allo stato di una transazione:
Le transazioni con punteggio inferiore alla soglia di revisione vengono automaticamente
APPROVED. Se una regola ha un’azione change_status esplicita, quello stato ha la priorità sulle soglie basate sul punteggio: DECLINED prevale sempre.
Abbassare la soglia di revisione aumenta il numero di transazioni segnalate per la revisione da parte degli analisti. Regola il valore in base alla capacità del tuo team e alla propensione al rischio.
Monitoraggio crypto
Abilita o disabilita lo screening crypto automatico per le transazioni in criptovalute. Quando è abilitato, Didit controlla gli indirizzi dei wallet e gli hash delle transazioni con i provider di analisi blockchain per tutte le transazioni concurrency_kind: "crypto". Lo screening dell’hash di una transazione richiede sia l’hash sia l’indirizzo del wallet correlato.
Preferenze dei provider
Seleziona e configura il provider di analisi blockchain che preferisci:
Quando colleghi una tua chiave del provider, utilizzi il tuo contratto esistente con il provider e paghi la commissione infrastrutturale indicata per ogni screening tramite Didit.
Il monitoraggio della Lightning Network è disponibile solo con una connessione BYOK di Elliptic o Chainalysis aggiunta tramite Marketplace.
Se
LIGHTNING viene inviato mentre è attivo un altro provider, oppure prima di aver aggiunto una delle due connessioni supportate, la richiesta di screening restituisce 400 con le indicazioni di configurazione del Marketplace.
Workflow di remediation
Il workflow di remediation (remediation_workflow_id nell’API delle impostazioni) è il predefinito a livello di applicazione per le azioni AWAITING_USER delle regole che non indicano un proprio workflow, cioè, in pratica, le regole della libreria integrata (le regole personalizzate hanno sempre una selezione propria, che ha la precedenza).
Il campo accetta un ID del workflow (oppure un UUID di una versione specifica) in scrittura e restituisce sempre l’ID stabile del workflow in lettura; le sessioni vengono create con l’ultima versione pubblicata.
Quando una regola di questo tipo imposta una transazione su AWAITING_USER, Didit crea la sessione di verifica collegata con il primo workflow trovato in quest’ordine:
- Il workflow di remediation configurato qui.
- Il workflow Autenticazione biometrica della tua applicazione, quando il soggetto ha già un volto di riferimento memorizzato.
- Il workflow predefinito della tua applicazione.
action_required e remediation della transazione e in entrambi i webhook delle transazioni, così puoi reindirizzare l’utente per completare la verifica richiesta.
Quando viene presa una decisione per la sessione, lo stato della transazione segue automaticamente tale decisione (approvata, rifiutata o in revisione) e viene inviato il webhook transaction.status.updated.
Un workflow di Autenticazione biometrica è la scelta consigliata in questo caso: l’utente dimostra di nuovo la propria identità con un singolo selfie acquisito in tempo reale e confrontato con il volto acquisito durante l’onboarding originale.
Richiede che il soggetto abbia un volto di riferimento memorizzato da una verifica approvata. Gli utenti che non ne hanno uno vengono invece invitati a completare il workflow predefinito della tua applicazione, con una nota sulla transazione che registra la sostituzione.
Dove trovarle
Vai su Transazioni > Impostazioni nella Business Console per configurare queste opzioni. Le impostazioni hanno effetto immediato su tutte le nuove transazioni.Prossimi passi
Valutazione del rischio
Come le soglie di punteggio vengono associate agli stati.
Screening crypto
Screening dei wallet e dettagli dei provider.
Arricchimento IP
Quali dati IP sono disponibili per le regole.