> ## 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. # Regles: velocitat, ràtio, seqüència, correlació > Regles de velocitat, ràtio, seqüència i correlació sobre dades d'esdeveniments a Didit, en el mateix constructor que les regles de transaccions. [Els esdeveniments](https://docs.didit.me/ca/transaction-monitoring/events.md) són avaluats pel mateix motor que les transaccions. Hi ha un sol model de regla, un sol vocabulari de condicions i un sol conjunt d'accions: una regla només declara a quins tipus de registre s'aplica. ## S'aplica a `scope.record_types` determina en quins registres s'activa una regla. | `record_types` | S'activa en | | - | - | | omès o `["transaction"]` | Només transaccions - **el valor per defecte** | | `["event"]` | Només esdeveniments | | `["transaction", "event"]` | Tots dos | > [!NOTE] > > Si l'omets, la regla continua sent només de transaccions. Totes les regles escrites abans que existissin els esdeveniments es comporten exactament com abans, i una regla mai no comença a coincidir amb inicis de sessió perquè el seu àmbit estava buit. A la consola, això és el selector **S'aplica a** del pas Activador d'una regla. En triar Esdeveniments es mostra una llista de verificació **Categories d'esdeveniments** que restringeix la regla encara més; si la deixes tota desmarcada, la regla avalua totes les categories. ```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__"` vol dir «el mateix valor que l'esdeveniment avaluat», i així una regla expressa *per subjecte*, *per dispositiu* o *per ronda* sense haver-ne de nomenar cap. Els registres sense el valor agrupat mai no s'agrupen entre ells. Un esdeveniment sense empremta digital del dispositiu no és «el mateix dispositiu» que altres esdeveniments sense cap empremta digital, i un esdeveniment que no indica cap subjecte no és «el mateix subjecte» que altres esdeveniments anònims: quan l'esdeveniment avaluat no té valor per a un camp `"__current__"`, aquesta agregació no coincideix, sigui quin sigui el seu operador. ## Camps d'esdeveniments Les condicions llegeixen rutes amb espai de noms. El vocabulari de transaccions que ja coneixes (`action_type`, `subject_vendor_data`, `subject_ip_country`, `custom_values.`) també es resol en un esdeveniment. | Grup | Rutes | | - | - | | Esdeveniment | `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` | | Dispositiu i xarxa | `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` | | Joc | `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` | | Pagament i disputa | `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` | | Seguretat i joc responsable | `event.security.changed_field`, `event.responsible_gambling.identity_match_ref` | | Telemetria de bots i assistència | `event.bot.timing_variance_ms`, `event.bot.actions_per_minute`, `event.bot.pointer_entropy`, `event.bot.reaction_time_ms_p50`, `event.bot.assistance_indicator` | | Senyals del subjecte | `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` | | Qualsevol altra cosa | `event.payload.`, `custom_values.` | Els senyals del subjecte es guarden en memòria cau a l'usuari monitoritzat i no es recalculen per a cada esdeveniment, de manera que una regla els pot llegir a la velocitat de la ingestió. ## Agregacions ### Velocitat Els reductors que ja fas servir amb les transaccions - `count`, `sum`, `avg`, `min`, `max`, `distinct_count` - sobre una `window` mòbil (`30m`, `24h`, `7d`, `30d`). ### Proporció Dos reductors sobre la mateixa finestra. Així s'expressen les taxes d'aposta sobre dipòsit, de retirada sobre dipòsit, de bonificació sobre dipòsit i de contracàrrecs. ```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 } ``` Dipositar 1.000, apostar 20 i sol·licitar una retirada: la proporció és 0,02, un clàssic blanqueig amb joc mínim. > [!NOTE] > > Una proporció **sense denominador mai no coincideix**. Si no hi ha dipòsits, la proporció no és zero: no hi ha evidència, i activar-la marcaria tots els usuaris nous. ### Seqüència Predicats ordenats dins d'una finestra. Cada pas es basa en `action_type`, `event_category` o en un filtre `match` arbitrari, i pot requerir `min_count` ocurrències abans que la seqüència avanci. ```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" } ] } ``` Atac de farciment de credencials, després la presa de control amb MFA, després la redirecció del pagament i després el buidatge. La regla s'activa en l'esdeveniment que completa la cadena, i l'evidència coincident enumera els identificadors d'esdeveniment de cada pas. L'estat de la seqüència es guarda per regla i subjecte, de manera que avança a mesura que arriben els esdeveniments en lloc de tornar a recórrer la línia de temps. El progrés més antic que la finestra es descarta i no es compta. ### Correlació Una unió entre subjectes: aplicar una reducció a tots els esdeveniments que comparteixen el grup d'aquest esdeveniment. ```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` fa coincidir els dos extrems com a conjunt no ordenat, de manera que A→B i B→A cauen al mateix grup. Això permet que una sola regla vegi les dues parts d'una col·lusió. L'abocament de fitxes, les apostes oposades i l'autoderivació com a afiliat: tots tenen aquesta forma. Dona sempre a una regla de correlació `filters` que la restringeixin. Sense ells, considera tots els esdeveniments de la finestra. ## Regles en temps real i asíncrones Algunes regles poden respondre dins de la petició d'ingestió i altres no. | S'executa | Quines regles | | - | - | | **A la petició** | Velocitat, ratio i seqüències acotades (finestra de fins a 24 hores) | | **En minuts, de forma asíncrona** | Regles de correlació i seqüències amb una finestra de més de 24 hores | Un esdeveniment amb regles pendents torna amb `"correlation_pending": true`. El seu estat i la seva puntuació s'actualitzen al mateix lloc quan acaba el procés asíncron. Tornar a executar-lo és idempotent, de manera que una regla mai aplica la seva puntuació dues vegades. Aquesta separació és intencionada: una consulta de xarxa entre subjectes no ha de fer esperar un inici de sessió. ## Accions El mateix vocabulari d'accions que les regles de transaccions: `add_score`, `change_status`, `add_tags`, `add_note`, `add_to_list`, `open_case`. Hi ha dues diferències en els esdeveniments: * `change_status` a `AWAITING_USER` és un resultat exclusiu de les transaccions (no hi ha flux de remediació per als esdeveniments) i s'aplica com a `IN_REVIEW`. * `open_case` enllaça el cas amb el **subjecte** en lloc d'una transacció, i registra l'identificador de l'esdeveniment coincident al cas. ## Evidència Cada coincidència emmagatzema el que ha vist: la finestra d'agregació, el valor calculat, el valor esperat, els identificadors d'esdeveniments mostrejats i la **font de cada camp coincident**. | Font | Significat | | - | - | | `server` | Didit l'ha derivat (IP, user agent, origen). Autoritativa. | | `sdk` | El SDK de Didit ho ha comunicat des del dispositiu. | | `customer` | Els teus sistemes l'han proporcionat. | Així, un analista pot distingir una IP marcada pel servidor d'una pista subministrada pel client abans d'actuar sobre una coincidència. La consola mostra la font al costat de cada camp coincident al panell de l'esdeveniment. ## Exemples pràctics > [accordion] Blanqueig amb joc mínim > > Dipòsit, joc amb tokens, retirada ràpida. Condició `event.action_type eq withdrawal_requested`, més la ràtio entre apostes i dipòsits en `lte 0.1` durant `24h`. > [accordion] Frau amistós > > Ratio de `count(chargeback_opened)` respecte de `count(deposit_completed)` per subjecte durant `30d`, `gte 0.5`. Agrupa per `event.payment.payment_fingerprint` en lloc del subjecte per detectar un mateix instrument de pagament en diversos comptes. > [accordion] Buidatge per presa de control del compte > > La seqüència `ato_drain` anterior, amb `add_score 90` i `change_status DECLINED`. > [accordion] Abocament de fitxes > > La correlació de parells anterior. Augmenta `value` fins a l'import que sigui rellevant per a les teves taules, i afegeix `event.gameplay.game_id` a `group_by` per mantenir les partides separades. > [accordion] Joc amb bots i assistència en temps real > > Condicions sobre `event.action_type eq bot_signal_observed`, `event.bot.timing_variance_ms lte 10` i `event.device.bot_score gte 90`, amb `add_tags`. Combina-ho amb un `distinct_count` de `event.device.fingerprint` per IP per detectar una granja en lloc d'un sol script. > [accordion] Elusió de l'autoexclusió > > Condició sobre `event.action_type eq self_exclusion_match` i `event.payload.re_registration_attempt eq true`, escalant-ho mitjançant `open_case`. ## Següent > [card] [Ingestió d'esdeveniments](https://docs.didit.me/ca/transaction-monitoring/events.md) > > L'envolupant, les deu categories i el contracte de lots. > [card] [API de regles](https://docs.didit.me/ca/transaction-monitoring/rules-api.md) > > Crea, actualitza i fes proves retrospectives de regles de manera programàtica. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.