iGamingにおける責任あるゲーミング取引モニタリング (JA)
責任あるゲーミングバンドルは、預金速度の急増、不審な制限変更、ボーナス乱用を、gambling_*取引カテゴリを使用して検知します。AMLモニタリングと同じエンジンで、1トランザクションあたり0.02ドルで提供されます。.

iGaming事業者は、相反する2つの監視義務を負っています。AML(アンチマネーロンダリング)規則では、マネーロンダリング(ストラクチャリング、ミュールパターン、制裁対象取引先)を監視するよう求められます。一方、責任あるゲーミング規則では、危害(プレイヤーが過度に速く入金する、損失を追いかけるために自己制限を引き上げる、ボーナスの不正利用など)を監視するよう求められます。ほとんどの事業者は、これらを別々のツールで別々のプログラムとして実行していますが、どちらも同じプレイヤー取引のストリームを読み取っています。
Diditの取引モニタリングAPIは、両方を1つのエンジンで実行します。責任あるゲーミングバンドルは、預金速度の急増、不審な制限変更、ボーナスの乱用を、専用のgambling_*取引カテゴリを使用して検知します。これは、AML/CTF、異常検知、不正防止の各バンドルと同じ製品、同じアラートキュー、同じケースワークフロー内に組み込まれています。すべての取引は、リアルタイムで1トランザクションあたり0.02ドルでスコアリングされます。
このガイドでは、責任あるゲーミングバンドル、それを支えるギャンブルカテゴリ、およびその設定方法について説明します。
主なポイント
- 責任あるゲーミングバンドルは、預金速度の急増、不審な制限変更、ボーナスの乱用など、マネーロンダリングだけでなくプレイヤー保護のシグナルも検知します。
- 専用の
gambling_*カテゴリ(gambling_bet、gambling_limit_change、gambling_bonus_change)により、適切なコンテキストでルールが適用されます。 - 責任あるゲーミングとAMLは1つのエンジンで実行されるため、プレイヤーへの危害とマネーロンダリングのシグナルはアラートキューとケースワークフローを共有します。
- ベロシティウィンドウ(カウント、合計、ユニーク)は、個別のストリームプロセッサなしで預金速度と制限変更パターンを表現します。
AWAITING_USERは、フラグが立てられた取引を、プレイヤー保護のタッチポイントとしても機能するステップアップのために一時停止できます。- 1トランザクションあたり0.02ドル、最低料金なし。フラグが立てられた当事者のAMLスクリーニングは、別途0.20ドルで請求されます。
責任あるゲーミングバンドルがすること
このバンドルは、マネーロンダリングの類型ではなく、プレイヤー保護の類型に合わせて調整された厳選されたルールセットです。プレイヤーの取引ストリーム(預金、ベット、制限変更、ボーナスイベント)を読み取り、規制当局や危害防止フレームワークが重視するパターンをフラグ付けします。例えば、短期間に繰り返し入金するプレイヤー、負けが続いた直後に預金または損失制限を引き上げるプレイヤー、あるいはボーナスを乱用または組織的に不正利用するアカウントなどです。
各ルールは、エンジンの他の部分と同じ種類のアクションを実行します。リスクスコアへの追加、ステータスの変更、取引へのタグ付け、または当事者のリストへの追加などです。したがって、預金速度の急増は、プレイヤーをレビュー対象に移動させ、責任あるゲーミングチームにメモを添付し、ポリシーで選択した場合、AWAITING_USERで次の預金を一時停止して、プレイヤーが続行する前に確認する必要があるように設定できます。
それが重要な理由
ギャンブル規制当局は、AMLコンプライアンスだけでなく、積極的な危害監視を事業者に求めるようになっています。多くの管轄区域でのライセンス条件では、事業者が危害の兆候(損失を追いかける、預金の増加、保護を解除する制限変更など)を特定し、介入することが期待されています。そうしないことは、罰金だけでなく、ライセンスリスクとなります。
責任あるゲーミングをAML監視へのアドオンとして実行することは無駄です。なぜなら、どちらも同じ取引を読み取っているからです。統合されたエンジンにより、1つの統合で両方の義務を果たすことができます。AMLルールがストラクチャリングのためにスコアリングする同じ預金を、責任あるゲーミングルールは速度のためにスコアリングします。シグナルはキューを共有し、アナリストはワークフローを共有し、監査証跡は両方のプログラムを一度にカバーします。これは、2つのベンダー契約ではなく、トランザクションごとの価格で実現されます。
技術詳細
ギャンブル取引は、適切なルールが適用されるように、gambling_*カテゴリで統一された/v3/ APIに対して作成されます。
curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"transaction_id": "txn_g7a118",
"category": "gambling_bet",
"amount": 500,
"currency": "EUR",
"currency_kind": "fiat",
"txn_date": "2026-05-21T20:05:00Z",
"subject": { "vendor_data": "player_4471", "role": "SENDER", "entity_type": "INDIVIDUAL" },
"payment_method": "CARD"
}'
預金速度の急増は、責任あるゲーミングバンドルをトリガーし、事業者が対応できるステータスを返します。
{
"transaction_id": "txn_g7a118",
"status": "AWAITING_USER",
"risk_score": 68,
"triggered_rules": [
{
"name": "Deposit velocity — 24h count",
"bundle": "Responsible gaming",
"aggregation": "count",
"window": "24h",
"action": "CHANGE_STATUS"
}
],
"alert_id": "alrt_e9c440"
}
ギャンブルカテゴリ。 gambling_bet、gambling_limit_change、gambling_bonus_changeにより、ルールはコンテキスト内で適用されます。預金に対する速度ルール、制限変更に対するパターンルール、ボーナスイベントに対する乱用ルールなどです。
速度と集計。 個別のストリームプロセッサなしで、「24時間以内に6回以上の預金」、「7日間で累計2,000ユーロ以上の預金」といったカウント、合計、ユニークなウィンドウで預金速度と制限変更パターンを表現します。
Webhooks。 transaction.createdとtransaction.status.updatedを購読して、アラートが解決され、修復が完了したときにプラットフォームを同期状態に保ちます。
価格。 1トランザクションあたり0.02ドル。呼び出しごとに請求され、最低料金はありません。フラグが立てられた当事者のAMLスクリーニングは、別途0.20ドルで請求されます。
プレイヤー保護ルールの構築
- 預金速度。
gambling_betに関連する預金イベントに対するcountまたはsumウィンドウは、プレイヤーが危害閾値を超える速さまたは量で預金していることを検知します。次の預金をAWAITING_USERで一時停止し、プレイヤーが続行する前に確認できるようにします。 - 制限変更。
gambling_limit_changeに関するルールは、プレイヤーが預金または損失制限を引き上げている場合、特に負けが続いた直後など、損失を追いかける典型的な兆候を検知します。これをレビューに回し、責任あるゲーミングチームに通知します。 - ボーナス乱用。
gambling_bonus_changeに関するルールを、ユニークアカウント数と組み合わせることで、ボーナスサイクリングや組織的な不正利用を検知します。 - AMLも同時に。 同じプレイヤーの預金は、AML/CTFおよび異常検知と同時に実行されるため、ストラクチャリングやミュールのシグナルが同じキューに表示されます。
これらすべてはビジネスコンソールで調整でき、事業者固有の危害の兆候についてはカスタムバンドルで拡張できます。
ユースケース
- オンラインカジノ — 預金速度と制限変更ルールは、損失を追いかける行動をフラグ付けし、プレイヤー保護のステップアップをトリガーします。
- スポーツベッティング — ベットと預金速度のウィンドウは、セッション内での賭け金のエスカレートを検知します。
- ボーナス主導の獲得 —
gambling_bonus_changeルールとユニークアカウント数により、ボーナス不正利用を検知します。 - 年齢制限のあるプラットフォーム — 危害または不正のシグナルが現れた場合、
AWAITING_USERステップアップは再検証のタッチポイントとしても機能します。 - 複数管轄区域の事業者 — 1つの監視プログラムを維持しながら、コンソールで市場ごとに危害閾値を調整します。
Diditとの統合方法
- バンドルを有効にする。 ビジネスコンソールで、AML/CTFおよび異常検知と並行して責任あるゲーミングを有効にし、預金速度、制限変更、ボーナス閾値を管轄区域に合わせて調整します。
- ギャンブルイベントを送信する。 プレイヤーが入金、ベット、制限変更、またはボーナスを受け取ったときに、適切な
gambling_*カテゴリと安定したtransaction_idおよびプレイヤーにリンクするvendor_dataを使用してPOST /v3/transactions/を送信します。 - ステータスに基づいて行動する。 承認、レビュー、拒否、または
AWAITING_USERで一時停止することで、プレイヤー保護または再検証ステップを挿入します。 - Webhooksと同期する。 アラートが解決されたり、ステップアップが完了したりしたときに反応するために、
transaction.status.updatedをリッスンします。
すべてが統一された/v3/ API上にあるため、KYCフローでオンボーディングされたプレイヤーは、責任あるゲーミングとAMLモニタリングの両方を実行する同じエンジンに直接流れ込みます。これは、エンドツーエンドの単一の本人確認および不正防止プラットフォームです。
よくある質問
責任あるゲーミングバンドルは何を検知しますか?
預金速度の急増、不審な制限変更、ボーナス乱用など、プレイヤー保護の兆候を、gambling_bet、gambling_limit_change、gambling_bonus_changeカテゴリを使用して検知します。
責任あるゲーミングとAMLを同じエンジンで実行できますか?
はい。両方とも同じ取引ストリームに対して1つのエンジンで実行され、アラートキューとケースワークフローを共有するため、1つの統合で両方の義務を果たすことができます。
損失を追いかける行動をどのようにフラグ付けしますか?
gambling_limit_changeに関するルールを使用して制限の引き上げ(特に損失後)を検知し、預金速度のウィンドウを使用して預金の増加を検知します。これらをレビューに回すか、AWAITING_USERで一時停止します。
プレイヤーをブロックするのではなく、一時停止できますか?
はい。AWAITING_USERステータスは、フラグが立てられた取引をステップアップ(確認、再検証)のために一時停止します。プレイヤーがそれをクリアすると自動的に再開され、プレイヤー保護のタッチポイントとしても機能します。
費用はいくらですか?
1トランザクションあたり0.02ドル。呼び出しごとに請求され、最低料金はありません。フラグが立てられた当事者のAMLスクリーニングは、別途0.20ドルで請求されます。
始める準備はできましたか?
ドキュメントの取引モニタリングの概要を読み、取引モニタリング製品ページでそれがプラットフォームの他の部分とどのように適合するかを確認し、料金ページで透明な呼び出しごとの料金を確認してください。準備ができたら、無料で開始してください。毎月500回の無料KYCチェックと、1呼び出しあたり0.02ドルの取引モニタリングが利用できます。