> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Regole KYT e scoring: velocità e condizioni

> Con Didit configuri regole KYT, condizioni, finestre di velocità e azioni automatiche. 1,000 al mese incluse, poi $0.001 ciascuna.

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.

[Creazione di una regola - Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> Le regole possono essere gestite dalla **Console Aziendale**, dall'**API di gestione** e dal **Didit MCP**. Usa la console quando un membro del tuo team responsabile della compliance deve esaminare ogni modifica; usa l'API o l'MCP quando le regole vengono create e ottimizzate in modo programmatico, ad esempio durante la migrazione di un set di regole da un altro fornitore. Consulta il [riferimento API](https://docs.didit.me/it/management-api/transactions/rules-list.md) e la [guida alla gestione delle regole tramite API e MCP](https://docs.didit.me/it/transaction-monitoring/rules-api.md). Le regole vengono valutate su ogni transazione inviata tramite [`POST /v3/transactions/`](https://docs.didit.me/it/management-api/transactions/create), e il risultato compare nell'array `rule_runs[]` della transazione (vedi [schema della risposta](https://docs.didit.me/it/transaction-monitoring/response-schema.md)).

## 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](https://docs.didit.me/it/management-api/transactions/rules-install.md) 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](https://docs.didit.me/it/transaction-monitoring/rules-library.md).

| Pacchetto | Esempi |
| - | - |
| **Finanza** | Rilevamento del frazionamento (in entrata/in uscita), singole transazioni di grande importo sopra le soglie di segnalazione |
| **AML/CTF** | Limiti di volume cumulativo, movimenti rapidi di entrata e uscita, corrispondenza delle controparti con le liste delle sanzioni, parole chiave sospette nei riferimenti dei pagamenti |
| **Rilevamento delle anomalie** | Frequenza elevata delle transazioni in entrata/in uscita, riattivazione di conti dormienti dopo 12+ mesi di inattività |
| **FATF** | Esposizione a giurisdizioni ad alto rischio per le controparti e gli indirizzi IP dei soggetti |
| **Intelligence dei dispositivi** | Uso ripetuto di una campagna bonus dalla stessa impronta del dispositivo, più impronte del dispositivo per lo stesso soggetto |
| **Prevenzione delle frodi** | Utilizzo di più account tramite impronte del dispositivo condivise tra soggetti distinti |
| **Monitoraggio crypto** | Esposizione a servizi mixer/di offuscamento, indirizzi ad alto rischio (darknet, sanzionati, fondi rubati) |
| **Screening crypto** | Esposizione a un'origine dei fondi ad alto rischio (>30%), più controparti rischiose, rifiuto automatico per il finanziamento del terrorismo / lo sfruttamento minorile, sospensione in attesa dello screening, segnalazione per punteggio di rischio medio del wallet |
| **Gioco responsabile** | Rapidi picchi di depositi in finestre temporali brevi |
| **E-commerce** | Schemi di transazione specifici dell'e-commerce |

## Fonti delle regole

Ogni regola ha una `source` che indica chi la gestisce:

| Fonte | Descrizione |
| - | - |
| **Preset** | Regole installate dalla libreria integrata di Didit. Scegli quali preimpostazioni (o interi pacchetti) installare e controlli la modalità di ciascuna preimpostazione installata (`Active`, `Test`, `Disabled`). Le loro condizioni e soglie sono fisse: per sovrascriverne una, crea una regola personalizzata. Vengono rimosse disinstallandole, non eliminandole. |
| **Custom** | Regole create dal tuo team nella Console Aziendale. Hai il pieno controllo delle regole personalizzate: puoi crearle, modificarle ed eliminarle secondo necessità. |

## Struttura di una regola

Ogni regola è composta da:

| Componente | Descrizione |
| - | - |
| **Titolo e descrizione** | Nome comprensibile per l'utente e spiegazione di ciò che la regola rileva |
| **Categoria** | Raggruppamento logico (ad esempio `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Modalità** | `Active` (valutazione in tempo reale), `Disabled` (saltata), oppure `Test` (valutata, ma i risultati non influiscono sulla transazione) |
| **Modalità di valutazione** | `All` (ogni condizione deve essere soddisfatta) oppure `Any` (almeno una condizione deve essere soddisfatta) |
| **Ambito** | Limita le transazioni a cui si applica la regola. Chiavi: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types` - vuoto o assente significa nessuna restrizione |
| **Condizioni** | Controlli a livello di campo: confrontano i campi della transazione con dei valori tramite operatori come `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Aggregazione** | Finestre temporali per la frequenza: aggregano le transazioni storiche nell'arco di un periodo di tempo (ad esempio conteggio, somma o conteggio dei valori distinti su 1 ora, 7 giorni, 30 giorni) |
| **Azioni** | Cosa accade quando la regola viene soddisfatta (vedi sotto) |

## Azioni

Quando una regola corrisponde a una transazione, vengono eseguite una o più azioni. Ogni regola può avere più azioni, tutte applicate insieme:

| Azione | `type` | Chiavi | Descrizione |
| - | - | - | - |
| **Aggiungi punteggio** | `add_score` | `value` (intero, può essere negativo) | Aggiunge punti al punteggio di rischio della transazione. Il punteggio cumulativo di tutte le regole corrispondenti determina se la transazione raggiunge o supera la soglia di revisione o quella di rifiuto. |
| **Cambia stato** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, alias `status`), `workflow_id` (alias `remediation_workflow_id`) | Imposta direttamente lo stato della transazione, indipendentemente dal punteggio. `workflow_id` è obbligatorio quando `value` è `AWAITING_USER`: se omesso, viene restituito `400`. |
| **Aggiungi tag** | `add_tags` | `tag_uuid` o `tag_name` (uno dei due), `tag_color` | Applica un tag alla transazione per la categorizzazione e il filtraggio. Si usa il `tag_uuid` di un tag esistente oppure un `tag_name`, che viene creato al primo utilizzo (memorizzato in maiuscolo); `tag_color` imposta il colore esadecimale di un tag appena creato. |
| **Aggiungi nota** | `add_note` | `note` (alias `value`) | Allega una nota di testo automatica alla transazione per il contesto dell'analista. |
| **Aggiungi a una lista** | `add_to_list` | `list_id` | Aggiunge il `vendor_data` del soggetto a una blocklist, una allowlist o una lista personalizzata. |
| **Apri caso** | `open_case` | `blueprint` (UUID del blueprint del caso, facoltativo), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (booleano) | Apre un caso di indagine (o vi aggiunge elementi). Viene applicata solo la prima azione `open_case` di una regola. |

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](https://docs.didit.me/it/transaction-monitoring/sdk-transaction-submission.md#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](https://docs.didit.me/it/transaction-monitoring/settings.md#workflow-di-remediation).
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](https://docs.didit.me/it/transaction-monitoring/wallet-ownership-widget.md).

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](https://docs.didit.me/it/transaction-monitoring/sdk-transaction-submission.md#esempio-verifica-biometrica-rafforzata-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`.

> [!NOTE]
>
> Come azione di intervento si può usare qualsiasi tipo di workflow tranne KYB.
> I workflow Autenticazione biometrica (e i workflow in cui il confronto facciale viene eseguito prima della verifica dell'identità) richiedono inoltre un volto di riferimento memorizzato per il soggetto: un selfie per il rilevamento della vitalità approvato, la foto del chip del passaporto, il ritratto del documento o un volto registrato manualmente nel profilo.
> Se non ne esiste nessuno, all'utente viene chiesto di completare invece il workflow predefinito dell'applicazione, che registra anche il suo volto per la volta successiva, e una nota sulla transazione registra la sostituzione.
> Solo quando non esiste nemmeno un workflow predefinito adatto la sessione viene saltata, con una nota che ne spiega il motivo.

## 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):

| Impostazione | Predefinito | Descrizione |
| - | - | - |
| **Soglia di revisione** | 75 | I punteggi uguali o superiori a questo valore attivano `IN_REVIEW` |
| **Soglia di rifiuto** | 500 | I punteggi uguali o superiori a questo valore attivano `DECLINED`. Il valore predefinito (`500`) non rifiuta mai in base al punteggio |

## Creazione di regole personalizzate

Puoi creare regole personalizzate dalla **Console Aziendale** oppure tramite la **API di gestione** (raggiungibile anche dal [Didit MCP](https://docs.didit.me/it/integration/mcp/tools.md) e da qualsiasi assistente AI collegato tramite MCP).

> [tab] Console
>
> 1. Vai su **Transazioni** > **Regole** nella console
> 2. Clicca su **Create Rule**
> 3. Definisci il titolo, la descrizione e la categoria della regola
> 4. Imposta la **modalità**: `Active` per eseguirla in tempo reale, oppure `Test` per valutarla senza influire sulle transazioni
> 5. Scegli la **modalità di valutazione**: `All` (ogni condizione deve essere soddisfatta) oppure `Any` (almeno una)
> 6. Imposta l'**ambito**, cioè i tipi di transazione o le direzioni a cui si applica la regola
> 7. Aggiungi le **condizioni**, cioè confronti tra campi come soglie di importo, codici paese o verifiche su proprietà personalizzate
> 8. Facoltativamente, aggiungi un'**aggregazione**, cioè controlli di velocità su una finestra temporale (conteggio, somma, conteggio distinto e altro)
> 9. Definisci una o più **azioni**: aggiungere un punteggio, cambiare stato, aggiungere tag, aggiungere note, aggiungere a una lista oppure aprire un caso
> 10. Salva e attiva la regola

> [tab] API
>
> Chiama [`POST /v3/transactions/rules/`](https://docs.didit.me/it/management-api/transactions/rules-create) con gli stessi campi: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. Il riferimento completo a campi, operatori e azioni è in questa pagina, mentre [gestire le regole tramite API e MCP](https://docs.didit.me/it/transaction-monitoring/rules-api.md) illustra il flusso consigliato: crea, esegui il backtest, poi attiva. Include anche la migrazione di un insieme di regole da un file CSV esportato da un altro provider.

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/`](https://docs.didit.me/it/management-api/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:

| Metrica | Descrizione |
| - | - |
| `count` | Numero di transazioni che corrispondono ai filtri nella finestra |
| `sum` | Totale di un `field` numerico (ad esempio `preferred_currency_amount`) nella finestra |
| `max` / `min` / `avg` | Valore più alto, più basso o medio di un `field` numerico nella finestra |
| `distinct_count` | Numero di valori unici di un `field` (ad esempio impronte di dispositivo distinte) nella finestra (`unique_count` è un alias accettato) |

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](#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

| Pattern | Come funziona |
| - | - |
| **Frazionamento** | Conteggio delle transazioni dello stesso soggetto in 30 giorni >= 20, con `max` dell'importo inferiore a \$10,000 sulla stessa finestra |
| **Alta frequenza** | Conteggio delle transazioni in entrata dello stesso soggetto in 7 giorni >= 20 |
| **Entrate e uscite rapide** | La transazione corrente è in uscita e il conteggio delle transazioni in entrata dello stesso soggetto in 6 ore è >= 1 |
| **Multi-accounting** | Conteggio distinto dei soggetti che condividono la stessa impronta del dispositivo in 7 giorni >= 3 |
| **Riattivazione di soggetti inattivi** | Giorni dall'ultima transazione del soggetto >= 365, combinati con un importo >= \$1,000 |

## Catalogo dei campi

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

| Campo | Descrizione |
| - | - |
| `amount`, `currency` | L'importo della transazione e il relativo codice valuta |
| `preferred_currency_amount`, `default_currency_code` | Importo convertito nella valuta preferita della tua applicazione (ripiega su `amount_in_default_currency`) |
| `direction` | `INBOUND` o `OUTBOUND` |
| `action_type` | Il tuo tipo di azione, ad esempio `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Riferimento di pagamento in testo libero (il campo target di `contains_any` per le regole basate su parole chiave) |
| `score`, `severity` | Il punteggio di rischio attuale della transazione e la sua gravità |
| `subject_vendor_data`, `counterparty_vendor_data` | I tuoi identificativi per le due parti |
| `subject_country`, `counterparty_country` | Codici paese delle parti (sono accettati sia ISO-2 sia ISO-3; vengono normalizzati prima del confronto) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Impronta del dispositivo o ID persistente del dispositivo |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Dettagli del contesto del dispositivo (è disponibile anche `counterparty_browser_family`) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Contesto di rete |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | Il metodo di pagamento lato soggetto (esistono gli stessi quattro campi per `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Stato del controllo Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Ciò che sai del VASP della controparte con cui lo scambio Travel Rule è entrato in contatto: la tua decisione su di esso (`APPROVED`, `RESTRICTED`, `BLOCKED`), il suo livello di rischio (`LOW`, `MEDIUM`, `HIGH`; `HIGH` finché il tuo screening della controparte risulta segnalato), il suo paese e la sua reattività (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Vedi [Due diligence sulla controparte Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#campi-delle-regole-e-preset) |
| `subject_days_since_previous_transaction` | Giorni trascorsi dalla precedente transazione dello stesso soggetto del medesimo tipo (regole di inattività) |
| `tags` | I nomi dei tag della transazione |
| `custom_values.<key>` | Qualsiasi chiave inviata in `custom_properties` alla creazione della transazione |

## Operatori di condizione

Le regole supportano i seguenti operatori di confronto per le condizioni:

| Operatore | Descrizione | Esempio |
| - | - | - |
| `eq` / `ne` | Uguale / diverso | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Confronti numerici e di date; non corrispondono mai se uno dei due lati manca | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Appartenenza a un elenco (è accettato anche un singolo valore scalare) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Sottostringa senza distinzione tra maiuscole e minuscole, rispetto a un valore stringa | `payment_details contains "refund"` |
| `contains_any` | Almeno una stringa di un elenco è una sottostringa del campo, senza distinzione tra maiuscole e minuscole | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | Il pattern del valore corrisponde al campo | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Somiglianza approssimata tra stringhe; richiede una soglia `score` (0-100) sulla condizione | `counterparty_name fuzzy_match "Acme Corp"` con `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | Il campo è presente (alias; `value` viene ignorato) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | Il campo è assente o vuoto (alias; `value` viene ignorato) | `subject_ip_address is_empty` |

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`:

| `value_type` | Significato |
| - | - |
| `list` | `value` è un UUID di lista: le voci della blocklist, dell'allowlist o della lista personalizzata diventano il valore di confronto, così una regola può verificare se una controparte è presente nella tua watchlist personalizzata. |
| `field` | `value` è un altro percorso di campo: la condizione confronta due campi della transazione, ad esempio `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` è una data relativa, ad esempio `{"direction": "past", "unit": "days", "amount": 30}`, da usare con campi data come `txn_date`. |

### 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/`](https://docs.didit.me/it/transaction-monitoring/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à:

| Entità | Tipo di blocklist | Cosa viene verificato |
| - | - | - |
| **Utente (richiedente)** | Blocklist utenti | L'identificatore `vendor_data` del richiedente |
| **Azienda** | Blocklist aziende | L'identificatore `vendor_data` dell'azienda |
| **Indirizzo del wallet** | Blocklist indirizzi wallet | Il `account_id` dei metodi di pagamento con wallet crypto |
| **Conto bancario** | Blocklist conti bancari | Il `account_id` dei metodi di pagamento con bonifico bancario |
| **Indirizzo IP** | Blocklist indirizzi IP | L'indirizzo IP dal contesto del dispositivo della parte (supporta intervalli CIDR) |
| **Impronta del dispositivo** | Blocklist impronte dei dispositivi | L'impronta del dispositivo o l'ID persistente del dispositivo |

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

> [!NOTE]
>
> I controlli sulla blocklist vengono eseguiti prima della valutazione delle regole. Un'entità in blocklist viene sempre rifiutata, indipendentemente dalla configurazione delle regole o dalle soglie di punteggio.

## 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

> [card] [Invio delle transazioni](https://docs.didit.me/it/transaction-monitoring/transactions.md)
>
> Come sono strutturate le transazioni per la valutazione delle regole.

> [card] [Screening crypto](https://docs.didit.me/it/transaction-monitoring/aml-screening.md)
>
> Risultati dello screening crypto e modalità con cui le regole predefinite li utilizzano.

> [card] [Impostazioni](https://docs.didit.me/it/transaction-monitoring/settings.md)
>
> Configura le soglie di punteggio e i workflow di rimedio.

> [card] [Riferimento API](https://docs.didit.me/it/management-api/transactions/create.md)
>
> Endpoint API per la creazione di una transazione.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.