ブログ・ 2026年5月21日

開発者向けガイド：速度ルールとストラクチャリング検知の構築 (JA)

速度ルールは、取引を一定期間にわたってカウント、合計、ユニークカウント集計で評価し、ストラクチャリング、スマーフィング、マネーミュールといった不正パターンの検知の基礎となります。Diditでこれらのルールを構築するための開発者向けガイドです。.

By Didit2026年5月21日更新日 2026年5月21日

個々の支払いだけを見ると、通常は何も分かりません。相手方への9,700ユーロの支払いは特筆すべきことではありません。しかし、3日間で同じ相手方に9,700ユーロの支払いが10回行われたり、午後だけで20の異なる口座から20回の着金があったりすると、それはストラクチャリングやマネーミュール活動の兆候です。これらを検知するには、取引を個別にではなく、時間の流れに沿って、カウントや合計を行いながらストリームとして見る必要があります。

それが速度ルールの役割であり、これらを自分で構築するのはトランザクション監視の中で最も難しい部分です。ユーザーごとにローリングウィンドウを維持し、そのウィンドウ内で相手方をカウント、合計、重複排除し、リアルタイムでしきい値を評価するストリームプロセッサが必要です。Diditのトランザクション監視APIは、そのエンジンをすぐに利用できるように提供します。ウィンドウを定義し、集計（カウント、合計、ユニーク）を選択し、しきい値を設定するだけで、ルールはすべてのトランザクションに対して1トランザクションあたり0.02ドルで実行されます。

これは、速度ルールを構築し、それらを使用してストラクチャリングを検出するための開発者向けガイドです。

主なポイント

速度ルールは、時間枠で評価します — 「過去24時間以内」、「7日間で」 — 単一のトランザクションを個別に評価するのではなく。
3つの集計： count（数）、sum（累積金額）、distinct（ユニークな相手方または属性） — ストラクチャリングおよびマネーミュール検知の構成要素。
ストラクチャリング — 報告しきい値をわずかに下回る多数の支払い — は、合計ウィンドウとしきい値近接条件を組み合わせることで検知されます。
マネーミュールとスマーフィングのパターンは、ウィンドウ内のユニークな相手方カウントで検知されます。
ストリームプロセッサは不要 — エンジンがウィンドウを維持し、コンソールでルールを宣言するだけです。
1トランザクションあたり0.02ドル、最低料金なし。フラグが立てられた当事者のAMLスクリーニングは、別途0.20ドルで請求されます。

速度ルールとは

速度ルールは3つの部分から構成されます。ウィンドウ（過去の期間 — 1時間、24時間、7日間）、そのウィンドウ内のトランザクションに対する集計、そして、それを超えたときにアクションをトリガーするしきい値です。集計は表現力豊かな核となります。

count — ウィンドウ内でルールの条件に一致したトランザクションの数。「24時間以内に5回以上の着金があった。」
sum — 一致するトランザクションの累積値。「7日間で累積額が10,000ユーロを超えた。」
distinct — 属性（通常は相手方）のユニークな値の数。「24時間以内に8つ以上の異なる送信元からの送金があった。」

ウィンドウはデフォルトで主体ごとにキーが設定されます — 各ユーザーは独自のローリングカウンターを持ちます — そのため、プラットフォーム全体の忙しい一日が個々のユーザーのシグナルをかき消すことはありません。

なぜ重要なのか

ストラクチャリング（スマーフィングとも呼ばれる）は、最も古いマネーロンダリング手法の一つであり、最も明確に規制されているものの一つです。報告しきい値 — EUの多くの国では10,000ユーロ、米国では10,000ドル — は、多額の資金を個々がしきい値を下回る小さな支払いに分割するインセンティブを生み出します。単一の金額のみをチェックする時点ルールでは、これを見抜くことはできません。全体のパターンは集計の中に存在します。

マネーミュールネットワークも同様です。マネーミュールの兆候は単一の送金ではなく、多くの異なる口座からの資金の集中と、それに続く迅速な資金の分散です。これは、ウィンドウ内のユニークな相手方カウントでしか見抜くことができません。規制当局は企業がこれらの類型を検知することを期待しており、速度ルールは独自のストリーミング分析スタックを構築することなくこれを行う方法です。

技術詳細

トランザクションは、お客様が制御するtransaction_idに対して冪等な統合/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_a19f04",
    "category": "finance",
    "amount": 9600,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T13:18:00Z",
    "subject": { "vendor_data": "user_3310", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" },
    "payment_method": "BANK_TRANSFER"
  }'

トランザクションがストラクチャリングパターンを完了すると、速度ルールが発動し、その応答で名前が示されます。

{
  "transaction_id": "txn_a19f04",
  "status": "IN_REVIEW",
  "risk_score": 66,
  "triggered_rules": [
    {
      "name": "Structuring — cumulative sum near threshold",
      "bundle": "Finance",
      "aggregation": "sum",
      "window": "7d",
      "action": "CHANGE_STATUS"
    }
  ],
  "alert_id": "alrt_b4d8e1"
}

Webhooks. transaction.createdとtransaction.status.updatedを購読して、アラートが解決されると元帳を同期させることができます。

価格. 1トランザクションあたり0.02ドル、呼び出しごとに請求され、最低料金はありません。フラグが立てられた当事者のAMLスクリーニングは、別途0.20ドルで請求されます。

ストラクチャリングとマネーミュールルールの構築

ストラクチャリング（合計ウィンドウ）。 7日間のウィンドウでのsum集計と、各トランザクションが報告しきい値をわずかに下回るという条件を組み合わせます。ユーザーの累積的な「しきい値直下」の支払いが設定したラインを超えると、このルールが発動します。これは、ストラクチャリングが隠そうとした集計された多額の取引です。しきい値の近接度（「直下」と見なされる報告ラインへの近さ）と累積トリガーを調整します。

スマーフィング（カウントウィンドウ）。 短いウィンドウでのcount集計は、小さな支払いの急増を捉えます。「24時間以内に1,000ユーロ未満の送金が10回以上あった」というルールは、個々の支払いが大きくなくても、フラグメンテーションパターンを浮上させます。

マネーミュールの集中（ユニークウィンドウ）。 相手方に対するdistinct集計は集中を捉えます。「24時間以内に8つ以上の異なる送信元からの着金があった。」これを迅速な分散カウントルールと組み合わせると、完全なマネーミュールシグネチャを記述できます。

これらは、シードされたバンドルにマッピングされます — ストラクチャリングと閾値回避はFinanceに、累積ボリュームと迅速な入出金はAML/CTFに、速度スパイクはAnomaly detectionに存在します — そして、これらを拡張したり、Customバンドルで独自のものを構築したりできます。各ルールのアクションは、リスクスコアの追加、ステータスの変更、タグの追加、または当事者のリストへの追加を行うことができます。

ユースケース

フィンテック — 送金と引き出しに対する累積合計ストラクチャリングルール。着金預金に対するユニークな相手方マネーミュールルール。
暗号通貨 — 急速なウォレット活動に対するカウントウィンドウ。単一の多額の出金前に多くの異なるアドレスから資金が到着する際のユニークなルール。
融資 — 不正な貸付詐欺を検知するための支払いと返済パターンに関する速度ルール。
マーケットプレイス — 販売者のボリュームを不正に膨らませる共謀取引リングを検知するためのユニークな購入者カウントルール。
iGaming — 責任あるゲーミングのシグナルとしても機能する、預金速度カウントウィンドウ。

Diditとの統合方法

ウィンドウを定義します。 ビジネスコンソールで、ポリシーが必要とするウィンドウ、集計（カウント/合計/ユニーク）、しきい値を使って速度ルールを構築します。
トランザクションを送信します。 お金が移動する際に、安定したtransaction_idとvendor_dataを使ってバックエンドからPOST /v3/transactions/を実行し、エンジンが適切な主体にウィンドウをキー付けするようにします。
ウェブフックを処理します。 速度ルールがトリップし、アナリストがアラートを解決したときに反応するために、transaction.status.updatedをリッスンします。
時間をかけて調整します。 真陽性率と偽陽性率を学習するにつれて、コンソールでしきい値を調整します — デプロイは不要です。

すべてが統合された/v3/ API上にあるため、KYCフローでオンボーディングされたユーザーは、これらの速度ルールを実行するのと同じエンジンに直接流れ込みます — エンドツーエンドで一つの本人確認と不正防止プラットフォームです。

よくある質問

速度ルールで利用できる集計は何ですか？

3つあります。count（一致するトランザクションの数）、sum（累積金額）、distinct（ユニークな相手方または属性）で、それぞれ定義した時間枠で評価されます。

ストラクチャリングを具体的に検出するにはどうすればよいですか？

ウィンドウでのsum集計と、各支払いが報告しきい値をわずかに下回るという条件を組み合わせます。累積合計が、ストラクチャリングが隠そうとしたラインを超えると、ルールが発動します。

独自のストリームプロセッサが必要ですか？

いいえ。エンジンが主体ごとにローリングウィンドウを維持します。ウィンドウ、集計、しきい値はコンソールで宣言します。

費用はいくらですか？

1トランザクションあたり0.02ドル、呼び出しごとに請求され、最低料金はありません。フラグが立てられた当事者のAMLスクリーニングは、別途0.20ドルで請求されます。

シードされたバンドルでカバーされていない速度ルールを構築できますか？

はい。カスタムバンドルは、お客様の製品に固有のあらゆる類型に対して、条件、速度ウィンドウ、および集計をサポートします。

始めましょうか？

ドキュメントのトランザクション監視の概要を読み、トランザクション監視製品ページでプラットフォームの他の部分とどのように連携するかを確認し、料金ページで透明な呼び出しごとの料金を確認してください。準備ができたら、無料で開始できます — 毎月500回の無料KYCチェックと、1呼び出しあたり0.02ドルのトランザクション監視をご利用いただけます。