ACTIVE, TEST o DISABLED). Condizioni, soglie e azioni dei preset sono fisse; crea una regola personalizzata quando ti servono logiche diverse. Disinstalla un preset per rimuoverlo dall’applicazione e reinstallalo in seguito, se necessario.
Le regole della libreria si possono sfogliare, installare e disinstallare da Transactions -> Rules -> Library nella Business Console, tramite l’API della libreria di regole (
GET /v3/transactions/rules/library/, POST/DELETE /v3/transactions/rules/install/), oppure con gli strumenti MCP didit_transaction_rule_library_list, didit_transaction_rule_install e didit_transaction_rule_uninstall. I preset installati accettano solo modifiche a mode (attiva, disattiva, test); le loro soglie sono fisse: per modificarne una, crea una regola personalizzata. Per capire come le regole contribuiscono allo scoring, vedi punteggio di rischio.Una regola della libreria le cui condizioni leggono dati che il motore delle regole non può ancora valutare è sospesa finché non può essere eseguita: la libreria non la elenca, una richiesta che la nomina in
library_keys restituisce 400 e non installa nulla (una chiave sconosciuta viene invece saltata), e un’installazione bundle la salta. Una copia installata in precedenza viene disattivata (DISABLED) e resta nell’elenco delle tue regole, e una richiesta che imposta il suo mode su un altro valore restituisce 400. Una regola sospesa torna disponibile da sola non appena il motore delle regole può valutarne le condizioni, quindi l’elenco della libreria mostra sempre le regole che puoi installare oggi.Come sono organizzati i preset
Ogni preset appartiene a un bundle (la sua famiglia funzionale) e a una categoria (il tema di rischio più ampio). I bundle ti permettono di attivare o disattivare insieme regole correlate dalla console; le categorie determinano il punteggio e il reporting.Come leggere questa pagina
Ogni regola elenca il suolibrary_key (identificatore stabile che puoi usare nell’API o nell’URL della console), le condizioni e l’aggregazione che la fanno scattare, e le azioni predefinite che esegue. Le soglie numeriche mostrate qui sono i valori predefiniti: ogni valore è modificabile per ciascuna applicazione senza perdere l’identità della regola.
Bundle finanziario
Queste regole si applicano a ogni transazione contransaction_type = FINANCE. Modellano la base normativa (soglie di segnalazione BSA/FinCEN, euristiche FATF sulla velocità) e i pattern di money mule e smurfing.
Strutturazione e soglie prossime
Volume e velocità
Layering, mule e smurfing
Anomalie comportamentali
Bundle AML / CTF
Queste regole modellano le tipologie classiche AML/CTF che non dipendono dall’arricchimento blockchain: si applicano in modo universale ai trasferimenti in valuta fiat e crypto.
La lista predefinita dei paesi ad alto rischio comprende i territori soggetti all’invito all’azione della FATF e le regioni interessate da conflitti:
IRN, PRK, SYR, AFG, RUS, MMR. Puoi sovrascrivere la lista per ogni applicazione.
La copertura PEP per le controparti non è al momento offerta. Nessun provider di screening collegato segnala se una controparte è una persona politicamente esposta: il campo
pep_counterparty è null in ogni risultato di screening attuale (vedi screening dei wallet), quindi la libreria non ha alcuna preimpostazione PEP per le controparti. Una regola installata prima che la preimpostazione fosse ritirata continua a essere valutata, ma non può corrispondere a uno screening reale: rimuovila o sostituiscila con una regola personalizzata se devi agire su un altro segnale.Bundle screening crypto
Queste regole utilizzano i dati arricchiti prodotti dallo screening crypto di Didit: sono più utili per le applicazioni native crypto e per i VASP.Pacchetto di monitoraggio crypto
Regole di esposizione a livello di wallet, oltre a controlli di integrità relativi ai VASP e correlati alla Travel Rule.Pacchetto Travel Rule
Le regole Travel Rule si applicano solo alle transazionitravelRule.
Ogni regime regionale include quattro regole (controparte in attesa, azione in attesa, dati mancanti, scambio non riuscito).
Travel Rule globale
Regimi regionali
Lo stesso modello di quattro regole si applica a ogni regime. Sostituisci<regime> con uno dei seguenti valori: australia, dubai, eu, hong_kong, india, indonesia, japan, kazakhstan, singapore, south_africa, turkey, uk.
L’assegnazione del regime è automatica: Didit imposta custom_values.travel_rule_regime su ogni transazione Travel Rule in base al campo jurisdiction delle tue impostazioni Travel Rule: SG → singapore, GB → uk, e qualsiasi codice di uno Stato membro UE o SEE, come DE o FR, → eu. I codici senza un bundle regionale vengono convertiti in minuscolo (US → us), così le regole personalizzate possono comunque applicarsi a essi. Un valore props.travel_rule_regime inviato nella transazione sostituisce sempre il regime derivato.
Sono quindi 48 regole specifiche per regione, che si aggiungono alle tre regole Travel Rule globali e alle cinque regole sulla controparte qui sotto.
Il bundle separato
travel_rule_eu_tfr aggiunge quattro regole EU TFR, descritte in Pacchetto di regole EU TFR.
Due diligence sulla controparte
Queste regole leggono ciò che la tua applicazione sa della VASP controparte con cui l’exchange è entrato in contatto: la tua decisione su di essa, il suo livello di rischio di due diligence, il suo paese e la sua reattività. Consulta Due diligence sulla controparte per sapere da dove provengono i singoli valori.Intelligenza dei dispositivi e prevenzione delle frodi
Queste regole trasformano i segnali provenienti dall’SDK lato client (fingerprint del dispositivo, IP, browser, anzianità della sessione) e dall’arricchimento fornito dal provider in eventi di rilevamento delle frodi.Fingerprint del dispositivo e account multipli
IP, rete e VPN
Composito comportamentale
Presa di controllo dell’account e frode APP
Abuso di affiliati e bonus
Pacchetto gioco responsabile
Per le applicazioni iGaming. Queste regole sono progettate per rilevare sia i segnali di tutela del giocatore sia i pattern di abuso dei bonus.Pacchetto antifrode per l’iGaming
Per gli operatori che inviano eventi di monitoraggio oltre ai movimenti di denaro. Queste regole usanoscope.record_types = ["event"], quindi i clienti che usano solo transazioni non vedono alcuna variazione di comportamento. Dove esiste un fallback solo transazioni, installa la regola di fallback indicata insieme alla regola evento finché la tua integrazione non invia la categoria evento.
Segnali evento richiesti da ogni regola
Ogni regola sopra legge campi evento con nome specifico. Quando un campo richiesto è assente, la regola semplicemente non trova corrispondenza: non approssima mai il segnale utilizzando altri dati, e non ricorre mai da sola ai dati della transazione. Invia le chiavi indicate di seguito nelpayload e nel device_context dell’evento (vedi Eventi per il contratto completo di invio e Regole sugli eventi per i percorsi dei campi delle regole).
Usa il pacchetto
igaming_fraud quando la tua integrazione emette eventi di login, gameplay, bonus, affiliazione, pagamento, contestazione, sicurezza e gioco responsabile. Le regole restano opt-in: aggiungerle alla libreria non le installa per le applicazioni esistenti e non modifica i preset attuali di nessun cliente.
Bundle e-commerce
Per marketplace e applicazioni con merchant of record.Bundle frode sugli assegni
Per le applicazioni che inviano transazioni di deposito di assegni. Ogni regola si attiva con i flagcustom_values.check_* che il chiamante imposta quando un assegno presenta un segnale di rischio noto (lavaggio, MICR mancante, numero seriale presente in liste del dark web, ecc.).
Bundle BNPL
Per i provider buy-now-pay-later. Individua la frode del cliente (mancato pagamento) e gli schemi di condivisione di identificativi specifici del credito rateale.Riferimento: standard alla base della libreria
Ogni preset della libreria di Didit corrisponde a una tipologia AML, di frode o di compliance ampiamente riconosciuta. Gli standard di riferimento sono:
Didit implementa solo le tipologie riconosciute come standard di settore e rende ogni soglia modificabile.
Personalizzazione dei preset
Ogni preset può essere:- Personalizzato: modificare le soglie, le finestre, i valori di punteggio o le azioni per applicazione
- Disabilitato: impostare un preset in modalità
DISABLEDe smette di valutare senza perdere la propria identità - Testato: impostare un preset in modalità
TESTper valutarlo in modalità shadow senza influire sugli esiti delle transazioni - Esteso: creare regole personalizzate che integrano o sostituiscono i preset