イベントルール - ベロシティ・比率・シーケンス・相関

イベントは取引と同じエンジンで評価されます。ルールモデル、条件で使用する語彙、アクションのセットはそれぞれ1つだけで、ルールはどのレコード種別に適用されるかを宣言するだけです。

適用先

scope.record_typesによって、ルールが何に対して発火するかが決まります。

`record_types`	発火対象
省略、または`["transaction"]`	取引のみ（デフォルト）
`["event"]`	イベントのみ
`["transaction", "event"]`	両方

省略した場合、ルールは取引のみを対象とします。イベント機能より前に作成されたルールはすべてこれまでとまったく同じように動作します。スコープがたまたま空だったという理由で、ルールがログインにマッチし始めることはありません。

コンソールでは、ルールのトリガーステップにある適用先セレクターがこれに当たります。イベントを選ぶとイベントカテゴリのチェックリストが表示され、ルールをさらに絞り込めます。すべてのカテゴリを評価する場合は、何もチェックしないでください。

{
  "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__"は「評価対象のイベントと同じ値」を意味します。これにより、ルールは特定の値を指定せずに対象者ごと、デバイスごと、ラウンドごとの条件を表現できます。

イベントフィールド

条件は名前空間付きのパスを読み取ります。すでにおなじみの取引の語彙（action_type、subject_vendor_data、subject_ip_country、custom_values.<key>）は、イベントでも参照できます。

グループ	パス
イベント	`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`
デバイスとネットワーク	`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`
ゲームプレイ	`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`
決済と紛争	`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`
セキュリティと責任あるギャンブル	`event.security.changed_field`, `event.responsible_gambling.identity_match_ref`
ボットとアシストのテレメトリ	`event.bot.timing_variance_ms`, `event.bot.actions_per_minute`, `event.bot.pointer_entropy`, `event.bot.reaction_time_ms_p50`, `event.bot.assistance_indicator`
対象者シグナル	`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`
その他	`event.payload.<key>`, `custom_values.<key>`

対象者シグナルはイベントごとに再計算されるのではなく、モニタリング対象のユーザーに対してキャッシュされます。そのため、ルールは取り込み時にこれらを読み取れます。

集計

ベロシティ

取引ですでに使っているリデューサー（count、sum、avg、min、max、distinct_count）を、ローリングwindow（30m、24h、7d、30d）にわたって適用します。

比率

同じウィンドウにわたる2つのリデューサーです。賭け額対入金額、出金額対入金額、ボーナス対入金額、チャージバック率はこの方法で表現します。

{
  "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
}

1,000を入金し、20を賭けて出金を申請すると、比率は0.02になります。最小限のプレイによる典型的なマネーロンダリングです。

分母のない比率は決して一致しません。入金がないことは比率ゼロではなく、根拠がないということです。ここで発火させると、新規ユーザー全員にフラグが立ってしまいます。

シーケンス

ウィンドウ内の順序付き述語です。各ステップはaction_type、event_category、または任意のmatchフィルターで一致を判定し、シーケンスが次に進む前にmin_count回の発生を要求できます。

{
  "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" }
  ]
}

クレデンシャルスタッフィング、次にMFAの乗っ取り、次に支払先の変更、そして資金の引き出し。ルールはチェーンを完了させたイベントで発火し、一致した根拠には各ステップのイベントIDが列挙されます。シーケンスの状態はルールと対象者ごとに保持されるため、タイムラインを再スキャンすることなく、イベントの到着に応じて進行します。ウィンドウより古い進行状況はカウントされず、破棄されます。

相関

対象者をまたぐ結合です。このイベントと同じグループを共有するすべてのイベントにわたって集計します。

{
  "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は両端を順序のない集合として照合するため、A→BとB→Aは同じグループに入ります。これにより、1つのルールで共謀の両側を把握できます。チップダンピング、反対ベッティング、アフィリエイトによる自己リファラルは、いずれもこの形です。相関ルールには必ず絞り込み用のfiltersを指定してください。指定しないと、ウィンドウ内のすべてのイベントが対象になります。

リアルタイムルールと非同期ルール

取り込みリクエスト内で結果を返せるルールと、できないルールがあります。

実行タイミング	対象ルール
リクエスト内	ベロシティ、比率、範囲が限定されたシーケンス（ウィンドウは最大24時間）
数分以内に非同期で	相関ルール、およびウィンドウが24時間を超えるシーケンス

ルールが保留中のイベントは、"correlation_pending": true付きで返されます。非同期処理が完了すると、既存のイベントのステータスとスコアが更新されます。再実行は冪等なため、ルールがスコアを二重に適用することはありません。この分担は意図的なものです。複数の対象者にまたがるリングのクエリのために、ログインを待たせてはならないからです。

アクション

取引ルールと同じアクション（add_score、change_status、add_tags、add_note、add_to_list、open_case）を使用します。イベントでは次の2点が異なります。

AWAITING_USERへのchange_statusは取引専用の結果であるため（イベントには是正フローがありません）、IN_REVIEWとして適用されます。
open_caseは、ケースを取引ではなく対象者に紐付け、一致したイベントIDをケースに記録します。

エビデンス

すべての一致には、集計ウィンドウ、算出値、期待値、サンプリングされたイベントID、一致した各フィールドのソースが保存されます。

ソース	意味
`server`	Diditが導出した値です（IP、ユーザーエージェント、オリジン）。信頼できる値です。
`sdk`	Didit SDKがデバイスから報告した値です。
`customer`	お客様のシステムが提供した値です。

そのため、アナリストは一致に対してアクションを起こす前に、サーバーで記録されたIPとクライアントが提供したヒントを区別できます。コンソールでは、イベントドロワー内の一致した各フィールドの横にソースが表示されます。

実例

最小限のプレイによるマネーロンダリング

入金し、形だけのプレイを行い、すぐに出金するパターンです。条件event.action_type eq withdrawal_requestedに加え、前述の賭け金対入金比率を24hの期間でlte 0.1に設定します。

フレンドリー詐欺

対象者ごとのcount(chargeback_opened)とcount(deposit_completed)の比率を30dの期間でgte 0.5に設定します。対象者の代わりにevent.payment.payment_fingerprintでグループ化すると、複数のアカウントにまたがって使われる1つの決済手段を検出できます。

アカウント乗っ取りによる資金流出

前述のato_drainシーケンスに、add_score 90とchange_status DECLINEDを組み合わせます。

チップダンピング

前述のペア相関を使用します。valueをお客様のテーブルにとって重要な金額まで引き上げ、group_byにevent.gameplay.game_idを追加してゲームごとに分けて集計します。

ボットによるプレイとリアルタイムアシスト

event.action_type eq bot_signal_observed、event.bot.timing_variance_ms lte 10、event.device.bot_score gte 90を条件とし、add_tagsを設定します。IPごとのevent.device.fingerprintのdistinct_countと組み合わせると、単一のスクリプトではなくファーム全体を検出できます。

自己排除の回避

event.action_type eq self_exclusion_matchとevent.payload.re_registration_attempt eq trueを条件とし、open_caseでエスカレーションします。

次のステップ

イベントの取り込み

エンベロープ、10のカテゴリ、バッチの仕様について説明します。

ルールAPI

プログラムでルールを作成、更新、バックテストできます。

はじめに

機能

リファレンス

コンソール

イベントルール - ベロシティ・比率・シーケンス・相関

適用先

イベントフィールド

集計

ベロシティ

比率

シーケンス

相関

リアルタイムルールと非同期ルール

アクション

エビデンス

実例

次のステップ

イベントの取り込み

ルールAPI

​適用先

​イベントフィールド

​集計

​ベロシティ

​比率

​シーケンス

​相関

​リアルタイムルールと非同期ルール

​アクション

​エビデンス

​実例

​次のステップ

イベントの取り込み

ルールAPI

適用先

イベントフィールド

集計

ベロシティ

比率

シーケンス

相関

リアルタイムルールと非同期ルール

アクション

エビデンス

実例

次のステップ