Regole KYT e scoring: velocità e condizioni

Ogni transazione inviata a Didit viene valutata rispetto a tutte le regole attive per la tua applicazione. Le regole definiscono condizioni, controlli sulla frequenza delle transazioni e azioni che determinano lo stato finale e il punteggio della transazione. Questo capitolo della lezione di Didit Academy sul motore di regole antifrode riprende dalla creazione di una regola. La lezione di Academy sul motore di regole mostra in video la creazione di una regola al minuto 7:54: trigger, condizioni, azioni e punteggio, poi il test retrospettivo prima della messa in produzione.

​

Pacchetti di regole integrati

Didit fornisce una libreria di regole preconfigurate che copre le tipologie normative più comuni. Installa le preimpostazioni (o interi pacchetti) che ti interessano dalla libreria - nella console, tramite l’API di installazione oppure con gli strumenti MCP - e controlla la modalità di ciascuna preimpostazione installata. Per il catalogo completo di tutte le regole preimpostate, con soglie e azioni, consulta la Libreria delle regole.

​

Fonti delle regole

Ogni regola ha una source che indica chi la gestisce:

​

Struttura di una regola

Ogni regola è composta da:

​

Azioni

Quando una regola corrisponde a una transazione, vengono eseguite una o più azioni. Ogni regola può avere più azioni, tutte applicate insieme: La maggior parte delle regole predefinite combina Aggiungi punteggio con Cambia stato: ad esempio, una regola sulla controparte sanzionata aggiunge 90 punti al punteggio e rifiuta immediatamente la transazione.

​

Richiesta di verifica dell’utente (AWAITING_USER)

L’azione Cambia stato → AWAITING_USER fa più che impostare uno stato: Didit crea automaticamente una sessione di verifica ospitata per il soggetto della transazione (stesso vendor_data) nel momento in cui la regola scatta. La sessione viene restituita nel blocco action_required della transazione (e nell’oggetto remediation) nella risposta di creazione e in ogni lettura successiva, e in entrambi i webhook delle transazioni, così puoi reindirizzare subito l’utente; vedi azioni richieste all’utente. Le regole personalizzate devono indicare il workflow nell’azione stessa (workflow_id): sia il generatore di regole della console sia l’API delle regole lo richiedono. Le regole della libreria integrata non includono un workflow; per queste il workflow della sessione viene determinato nel seguente ordine:

1. Il workflow di intervento configurato nelle tue impostazioni delle transazioni.
2. Il workflow Autenticazione biometrica della tua applicazione, quando il soggetto ha già un volto di riferimento memorizzato da una verifica approvata.
3. Il workflow predefinito della tua applicazione.

Ciò significa che le regole della libreria con AWAITING_USER producono sempre, già pronta all’uso, una sessione utilizzabile: un passaggio di autenticazione biometrica aggiuntiva per gli utenti già verificati, una verifica completa per gli altri. Le transazioni Travel Rule sono escluse da questo ripiego automatico: la loro attesa AWAITING_USER serve a fornire la prova della proprietà del wallet, che ha un proprio flusso. La scelta più solida per le transazioni ad alto rischio è un workflow Autenticazione biometrica: poiché il soggetto è l’utente già sottoposto a KYC, Didit riutilizza il volto di riferimento verificato dall’onboarding (il selfie per il rilevamento della vitalità approvato, la foto del chip del passaporto o il ritratto del documento). All’utente basta scattare un solo selfie dal vivo, e Didit esegue il rilevamento della vitalità e un confronto facciale 1:1 con l’identità che ha aperto l’account. Credenziali rubate, OTP ottenuti con phishing e SIM swap falliscono tutti a questo controllo. Guida completa: step-up biometrico per un prelievo di alto valore. Quando la sessione raggiunge una decisione, la transazione la segue automaticamente e viene inviato il webhook transaction.status.updated: una sessione approvata approva la transazione (decision_reason_code: user_action_approved), una sessione rifiutata la rifiuta (user_action_declined), e una sessione che termina in revisione porta la transazione in IN_REVIEW (user_action_in_review). Una sessione scaduta o abbandonata lascia la transazione in AWAITING_USER.

​

Punteggio

Quando una transazione corrisponde a una o più regole, i punteggi vengono combinati:

1. Ogni corrispondenza a una regola contribuisce al punteggio di rischio complessivo della transazione tramite l’azione add_score
2. Il punteggio finale determina lo stato della transazione in base alle soglie di punteggio della tua applicazione
3. Se una regola contiene un’azione change_status, quello stato viene applicato direttamente: DECLINED ha sempre la priorità

Soglie di punteggio predefinite (configurabili nella console):

​

Creazione di regole personalizzate

Puoi creare regole personalizzate dalla Console Aziendale oppure tramite la API di gestione (raggiungibile anche dal Didit MCP e da qualsiasi assistente AI collegato tramite MCP). Le regole in modalità Active hanno effetto immediato su tutte le nuove transazioni. I titoli sono univoci per applicazione.

​

Backtesting

Prima di attivare una regola, puoi verificarla con i dati storici:

• Imposta una regola sulla modalità Test: la regola viene valutata su ogni nuova transazione, ma i risultati non modificano lo stato né il punteggio della transazione. Le statistiche di esecuzione (numero di corrispondenze, entità interessate) si accumulano, così puoi valutarne l’impatto prima di attivarla.
• Usa la funzionalità backtest - nella console oppure tramite POST /v3/transactions/rules/backtest/ - per valutare retroattivamente le condizioni e l’aggregazione di una regola su transazioni di un periodo specificato. Il backtest restituisce il numero di transazioni valutate e di quelle corrispondenti, nonché le entità interessate, senza modificare alcun dato storico. Invia gli stessi conditions, aggregation, evaluation_mode e scope della regola che intendi attivare: un ambito omesso significa nessuna restrizione, quindi il backtest conterebbe transazioni che la regola salvata ignora.

​

Finestre di frequenza (aggregazione)

Le regole di velocità aggregano i dati storici delle transazioni su un periodo per individuare schemi che i controlli su singola transazione non rileverebbero: Ogni aggregazione specifica:

• Una finestra temporale: <N>m (minuti), <N>h (ore) oppure <N>d (giorni), ad esempio 30m, 6h, 7d, 30d. Attenzione: m indica minuti, non mesi.
• Filtri per restringere le transazioni storiche incluse. Le chiavi sono percorsi di campo del catalogo dei campi. Il valore speciale "__current__" corrisponde al valore dello stesso campo sulla transazione valutata (ad esempio "subject_vendor_data": "__current__" limita la finestra allo stesso soggetto). Un valore di tipo lista indica l’appartenenza a un insieme. I filtri confrontano solo per uguaglianza o appartenenza: non esistono filtri lt o gte, quindi un intervallo come transazioni sotto 10,000 non si può esprimere con un filtro. Inserisci l’intervallo nella metrica (max sotto 10,000, min sopra 1,000) e ricorda che una condizione vincola la transazione valutata, mai la finestra.
• Un operatore e una soglia (eq, ne, gt, gte, lt, lte rispetto a value, ad esempio conteggio >= 20)

​

Pattern di esempio

​

Catalogo dei campi

Le condizioni e i filtri di aggregazione fanno riferimento ai campi della transazione in base al percorso:

​

Operatori di condizione

Le regole supportano i seguenti operatori di confronto per le condizioni: Ogni altro operatore richiede un value non vuoto, altrimenti l’API risponde con 400. contains, not_contains e regex accettano una sola stringa, non un elenco o un oggetto; contains_any accetta un elenco di stringhe.

​

Tipi di valore delle condizioni

Un value_type facoltativo su una condizione modifica il modo in cui viene interpretato value:

​

Condizioni raggruppate

Un elenco piatto di condizioni viene combinato in base a evaluation_mode della regola (ALL/ANY). Per una logica mista, assegna alle condizioni un group_index: le condizioni con lo stesso indice formano un gruppo, group_logic (AND/OR, predefinito AND) combina le condizioni all’interno di un gruppo, e groups_logic sulla prima condizione (AND/OR, predefinito OR) combina gli esiti dei gruppi. Quando almeno una condizione ha un group_index, la valutazione per gruppi sostituisce evaluation_mode.

​

Riferimento alle proprietà personalizzate

Ogni chiave inviata nell’oggetto custom_properties di POST /v3/transactions/ viene memorizzata sulla transazione come custom_values e può essere usata nelle condizioni con il percorso di campo custom_values.<key>. Ad esempio, una transazione inviata con "custom_properties": {"channel": "mobile_app"} corrisponde alla condizione custom_values.channel eq "mobile_app". Tutti gli operatori sopra indicati funzionano con le proprietà personalizzate, che possono anche essere confrontate con altri campi o usate nei filtri di velocità. Nel generatore di regole della Console, le chiavi rilevate sulle transazioni acquisite di recente compaiono automaticamente nel selettore dei campi delle condizioni, sotto Proprietà personalizzate. Puoi anche fare riferimento a una chiave prima che una transazione la contenga: scegli Inserisci proprietà personalizzata nello stesso gruppo e digita la chiave esattamente come la invia la tua integrazione (le chiavi sono sensibili alle maiuscole e minuscole). Finché non arrivano transazioni con quella chiave, la regola viene semplicemente valutata come non corrispondente.

​

Rifiuto automatico per blocklist

Prima che vengano valutate le regole, Didit verifica le entità della transazione rispetto alle blocklist della tua applicazione. Se viene trovata una qualsiasi corrispondenza, la transazione viene rifiutata immediatamente: le regole non vengono valutate. Vengono controllate le seguenti entità: Quando si verifica una corrispondenza in blocklist:

• Lo stato della transazione viene impostato su DECLINED
• Il motivo della decisione viene impostato su blocklisted
• Viene creato un record di attività a fini di audit

​

Screening delle transazioni

Didit si integra con fornitori esterni di analisi AML e blockchain per arricchire le transazioni con informazioni sul rischio. Quando una transazione viene inviata, il sistema può:

• Effettuare lo screening delle controparti rispetto ai database globali di sanzioni e watchlist
• Valutare gli indirizzi dei wallet (per le transazioni crypto) rispetto ai dati di intelligence blockchain, inclusa l’esposizione a mixer, le connessioni con entità sanzionate e le interazioni con servizi ad alto rischio
• Verificare lo stato AML del richiedente confrontando l’utente collegato alla transazione con i risultati più recenti dello Screening AML

I risultati dello screening vengono allegati alla transazione e incidono sul punteggio del motore delle regole. Se una controparte o un wallet corrisponde a una lista delle sanzioni, la regola corrispondente contrassegna o rifiuta automaticamente la transazione.

​

Prossimi passi