> ## 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 eventi: Velocità, Rapporto, Sequenza, Correlazione > Con Didit, regole di velocità, rapporto, sequenza e correlazione sui dati degli eventi, nello stesso rule builder delle transazioni. Gli [Eventi](https://docs.didit.me/it/transaction-monitoring/events.md) sono valutati dallo stesso motore delle transazioni. Esiste un unico modello di regola, un unico vocabolario di condizioni e un unico insieme di azioni: una regola dichiara semplicemente a quali tipi di record si applica. ## Si applica a `scope.record_types` determina su cosa si attiva una regola. | `record_types` | Si attiva su | | - | - | | omesso o `["transaction"]` | Solo transazioni - **il valore predefinito** | | `["event"]` | Solo eventi | | `["transaction", "event"]` | Entrambi | > [!NOTE] > > Se lo ometti, la regola resta limitata alle transazioni. Tutte le regole scritte prima che esistessero gli eventi si comportano esattamente come prima, e una regola non inizia mai a corrispondere agli accessi perché il suo ambito era vuoto. Nella console questo corrisponde al selettore **Si applica a** nel passaggio Trigger della regola. Selezionando Eventi compare una checklist **Categorie di eventi** che restringe ulteriormente la regola; lasciala completamente deselezionata per valutare ogni categoria. ```json theme={null} { "title": "Failed login burst", "scope": { "record_types": ["event"], "event_categories": ["security"] }, "aggregation": [ { "metric": "count", "operator": "gte", "value": 3, "window": "30m", "filters": { "subject_vendor_data": "__current__", "event.action_type": "login_failed" } } ], "actions": [ { "type": "add_score", "value": 40 }, { "type": "change_status", "value": "IN_REVIEW" } ] } ``` `"__current__"` significa "lo stesso valore dell'evento in valutazione": è così che una regola esprime *per soggetto*, *per dispositivo* o *per round* senza nominarne uno. I record privi del valore raggruppato non vengono mai raggruppati insieme. Un evento senza impronta del dispositivo non è "lo stesso dispositivo" di altri eventi senza impronta, e un evento che non indica un soggetto non è "lo stesso soggetto" di altri eventi anonimi: quando l'evento in valutazione non ha un valore per un campo `"__current__"`, quell'aggregazione non corrisponde, qualunque sia il suo operatore. ## Campi degli eventi Le condizioni leggono percorsi con namespace. Il vocabolario delle transazioni che già conosci (`action_type`, `subject_vendor_data`, `subject_ip_country`, `custom_values.`) si risolve anche su un evento. | Gruppo | Percorsi | | - | - | | Evento | `event.category`, `event.action_type`, `event.occurred_at`, `event.amount`, `event.currency`, `event.direction`, `event.session_id`, `event.session_sequence`, `event.score`, `event.status`, `event.ingest_source`, `event.retention_class`, `event.subject_vendor_data`, `event.business_vendor_data` | | Dispositivo e rete | `event.device.fingerprint`, `event.device.persistent_device_id`, `event.device.bot_score`, `event.ip.address`, `event.ip.country`, `event.ip.asn_number`, `event.ip.asn_organization`, `event.ip.is_vpn_or_tor`, `event.ip.is_data_center`, `event.ip.proxy_type`, `event.ip.country_name`, `event.ip.city`, `event.ip.connection_type`, `event.ip.travel_distance_km`, `event.ip.travel_speed_kmh` | | Gioco | `event.gameplay.game_id`, `event.gameplay.table_id`, `event.gameplay.round_id`, `event.gameplay.hand_id`, `event.gameplay.match_id`, `event.gameplay.market_id`, `event.gameplay.side`, `event.gameplay.role`, `event.gameplay.counterparty_vendor_data`, `event.gameplay.net_result_amount`, `event.bonus.bonus_id`, `event.affiliate.affiliate_code` | | Pagamento e contestazione | `event.payment.reference_id`, `event.payment.payment_fingerprint`, `event.payment.instrument_reference_hash`, `event.payment.withdrawal_address_hash`, `event.dispute.dispute_id`, `event.dispute.chargeback_id` | | Sicurezza e gioco responsabile | `event.security.changed_field`, `event.responsible_gambling.identity_match_ref` | | Telemetria bot e assistenza | `event.bot.timing_variance_ms`, `event.bot.actions_per_minute`, `event.bot.pointer_entropy`, `event.bot.reaction_time_ms_p50`, `event.bot.assistance_indicator` | | Segnali del soggetto | `subject.email.risk_score`, `subject.email.social_count`, `subject.email.is_disposable`, `subject.email.deliverability`, `subject.email.domain_reputation`, `subject.email.first_seen_days`, `subject.email.is_breached`, `subject.phone.risk_score`, `subject.phone.line_type`, `subject.phone.social_count`, `subject.phone.carrier`, `subject.phone.country`, `subject.phone.is_disposable` | | Tutto il resto | `event.payload.`, `custom_values.` | I segnali del soggetto sono memorizzati nella cache per l'utente monitorato e non vengono ricalcolati per ogni evento, così una regola può leggerli alla velocità dell'ingestione. ## Aggregazioni ### Velocità Le funzioni di aggregazione che già usi sulle transazioni - `count`, `sum`, `avg`, `min`, `max`, `distinct_count` - su una `window` scorrevole (`30m`, `24h`, `7d`, `30d`). ### Rapporto Due funzioni di aggregazione sulla stessa finestra. È così che si esprimono i rapporti tra scommesse e depositi, tra prelievi e depositi, tra bonus e depositi e i tassi di chargeback. ```json theme={null} { "metric": "ratio", "window": "24h", "filters": { "subject_vendor_data": "__current__" }, "numerator": { "metric": "sum", "field": "event.amount", "filters": { "event.action_type": "bet_placed" } }, "denominator": { "metric": "sum", "field": "event.amount", "filters": { "event.action_type": "deposit_completed" } }, "operator": "lte", "value": 0.1 } ``` Deposita 1.000, scommetti 20 e richiedi un prelievo: il rapporto è 0,02, un classico caso di riciclaggio con gioco minimo. > [!NOTE] > > Un rapporto **senza denominatore non corrisponde mai**. Nessun deposito non equivale a un rapporto pari a zero: è assenza di prove, e far scattare la regola in quel caso segnalerebbe ogni utente appena registrato. ### Sequenza Predicati ordinati all'interno di una finestra. Ogni passaggio corrisponde a `action_type`, `event_category` o a un filtro `match` arbitrario, e può richiedere almeno `min_count` occorrenze prima che la sequenza avanzi. ```json theme={null} { "metric": "sequence", "key": "ato_drain", "window": "24h", "steps": [ { "event_category": "security", "action_type": "login_failed", "min_count": 3 }, { "event_category": "security", "action_type": "mfa_changed" }, { "event_category": "payment", "action_type": "withdrawal_address_changed" }, { "event_category": "payment", "action_type": "withdrawal_requested" } ] } ``` Uso automatizzato di credenziali rubate, poi la presa di controllo tramite MFA, poi il reindirizzamento del pagamento, poi lo svuotamento del conto. La regola si attiva sull'evento che completa la catena, e le prove corrispondenti elencano gli ID evento di ogni passaggio. Lo stato della sequenza è mantenuto per regola e per soggetto, quindi avanza man mano che arrivano gli eventi invece di riscansionare la cronologia. Il progresso risalente a prima della finestra viene scartato, non conteggiato. ### Correlazione Un join tra soggetti diversi: esegue un'aggregazione su tutti gli eventi che condividono il gruppo di questo evento. ```json theme={null} { "metric": "correlation", "window": "7d", "pair": true, "group_by": ["subject_vendor_data", "event.gameplay.counterparty_vendor_data"], "filters": { "event.action_type": "p2p_settlement" }, "correlate": { "metric": "sum", "field": "event.gameplay.net_result_amount", "filters": { "event.gameplay.role": "winner" } }, "operator": "gte", "value": 500 } ``` `"pair": true` confronta le due estremità come insieme non ordinato, quindi A→B e B→A finiscono nello stesso gruppo. È questo che permette a una sola regola di vedere entrambe le metà di una collusione. Il trasferimento illecito di fiches, le scommesse opposte e l'autoreferenza dell'affiliato hanno tutti questa forma. Assegna sempre a una regola di correlazione dei `filters` restrittivi. Senza di essi considera ogni evento della finestra. ## In tempo reale e asincrone Alcune regole possono rispondere all'interno della richiesta di acquisizione, altre no. | Esecuzione | Quali regole | | - | - | | **Nella richiesta** | Velocità, rapporto e sequenze limitate (finestra fino a 24 ore) | | **Entro pochi minuti, in modo asincrono** | Regole di correlazione e sequenze con una finestra superiore a 24 ore | Un evento le cui regole sono ancora in attesa viene restituito con `"correlation_pending": true`. Il suo stato e il suo punteggio si aggiornano sul posto al completamento del passaggio asincrono; la riesecuzione è idempotente, quindi una regola non applica mai il proprio punteggio due volte. Questa suddivisione è intenzionale: una query di anello tra soggetti diversi non deve far attendere un login. ## Azioni Lo stesso vocabolario di azioni delle regole sulle transazioni: `add_score`, `change_status`, `add_tags`, `add_note`, `add_to_list`, `open_case`. Due differenze sugli eventi: * `change_status` impostato su `AWAITING_USER` è un esito valido solo per le transazioni (non esiste un flusso di rimedio per gli eventi) e viene applicato come `IN_REVIEW`. * `open_case` collega il caso al **soggetto** anziché a una transazione, e registra sul caso l'id dell'evento corrispondente. ## Evidenze Ogni corrispondenza memorizza ciò che ha rilevato: la finestra di aggregazione, il valore calcolato, il valore atteso, gli id degli eventi campionati e la **fonte di ciascun campo corrispondente**. | Fonte | Significato | | - | - | | `server` | Didit l'ha ricavata (IP, agente utente, origine). Autorevole. | | `sdk` | L'SDK di Didit l'ha riportata dal dispositivo. | | `customer` | I tuoi sistemi l'hanno fornita. | Un analista può quindi distinguere un IP registrato dal server da un suggerimento fornito dal client prima di agire su una corrispondenza. La console mostra la fonte accanto a ciascun campo corrispondente nel pannello dell'evento. ## Esempi pratici > [accordion] Riciclaggio con gioco minimo > > Deposito, gioco con token, prelievo rapido. Condizione `event.action_type eq withdrawal_requested`, più il rapporto puntata-deposito sopra indicato con `lte 0.1` su `24h`. > [accordion] Frode amichevole > > Rapporto tra `count(chargeback_opened)` e `count(deposit_completed)` per soggetto su `30d`, `gte 0.5`. Raggruppa per `event.payment.payment_fingerprint` anziché per soggetto, per individuare uno stesso strumento di pagamento su più account. > [accordion] Svuotamento causato dalla compromissione dell'account > > La sequenza `ato_drain` descritta sopra, con `add_score 90` e `change_status DECLINED`. > [accordion] Chip dumping > > La correlazione di coppia descritta sopra. Imposta `value` sull'importo rilevante per i tuoi tavoli e aggiungi `event.gameplay.game_id` a `group_by` per tenere separate le partite. > [accordion] Gioco con bot e assistenza in tempo reale > > Condizioni su `event.action_type eq bot_signal_observed`, `event.bot.timing_variance_ms lte 10` ed `event.device.bot_score gte 90`, con `add_tags`. Combinala con un `distinct_count` di `event.device.fingerprint` per IP, per individuare una farm anziché un singolo script. > [accordion] Elusione dell'autoesclusione > > Condizione su `event.action_type eq self_exclusion_match` e `event.payload.re_registration_attempt eq true`, con escalation tramite `open_case`. ## Passaggi successivi > [card] [Acquisizione degli eventi](https://docs.didit.me/it/transaction-monitoring/events.md) > > Il contenitore, le dieci categorie e il contratto dei batch. > [card] [API delle regole](https://docs.didit.me/it/transaction-monitoring/rules-api.md) > > Crea, aggiorna e sottoponi a back-test le regole in modo programmatico. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.