Velocity Check

定義

Velocity Check（ベロシティチェック） とは、同一のカード番号・IPアドレス・メールアドレス・デバイスフィンガープリントなどの識別子を用いて、一定時間内に何回取引が試行されたかをリアルタイムで計測し、その「速度（Velocity）」が閾値を超えた場合に不正利用（カード盗用・アカウント乗っ取り・カードテスティング）の疑いありとして取引をブロックまたは追加認証に回す不正検知ロジックです。

DTC／越境ECにおいては、決済代行会社（PSP）や不正検知ソリューション（Stripe Radar、Adyen RevenueProtect、Forter、Riskified など）の中核ルールとして標準実装されています。単発の取引だけを見ても正常に見えるため、「時間軸」という第4の軸を加えて異常を炙り出す点が最大の特徴です。

类比（たとえ話）

Velocity Checkは、「同じ人が同じATMに何度も並んでいるか」を見張る警備員のようなものです。

1回だけATMを使うのは完全に正常です。しかし、ある人が10分間に15回もATMに並び、毎回違うカードを差し込んでいたら、警備員は「これは他人のカードで現金を引き出そうとしているのでは？」と疑います。Velocity Checkはまさにこの「並ぶ回数 × 時間」をカウントし、閾値を超えた瞬間にアラートを上げる仕組みです。

ECサイトでは、この「ATM」が決済フォーム、「並ぶ人」がカード番号・IP・メールアドレスに置き換わります。

公式（計算ロジック）

Velocity Checkの基本判定は、識別子ごとにスライディングウィンドウ方式でカウントします。

Velocity(identifier, window) = Σ transactions(identifier, t)  for t ∈ [now - window, now]

if Velocity(identifier, window) > threshold:
    → Block / 3DS Challenge / Manual Review

実務では複数のウィンドウと閾値を多次元で組み合わせます。以下は越境ECでよく使われる典型値です。

識別子	ウィンドウ	閾値（例）	超過時のアクション
カード番号（PAN）	10分	3回	即ブロック
カード番号（PAN）	24時間	5回	3DS強制
IPアドレス	1時間	8回	レビュー送り
IPアドレス	24時間	20回	即ブロック
メールアドレス	1時間	4回	3DS強制
デバイスID	24時間	6回	レビュー送り
BIN（カード先頭6桁）	1時間	15回	監視フラグ

たとえば「同一カードで10分以内に3回」というルールは、カードテスティング（少額決済を連続試行して有効カードを炙り出す攻撃）に対して極めて有効です。攻撃者は1枚のカードで数十回試行するため、1〜3回の時点で止めるのが定石です。

对比表（他の不正検知ロジックとの比較）

検知ロジック	見る軸	得意な攻撃	弱点
Velocity Check	時間 × 回数	カードテスティング、ブルートフォース	低速攻撃（Low & Slow）に弱い
AVS（住所照合）	請求先住所の一致	盗難カードの即時利用	越境では不一致が多い
CVVチェック	セキュリティコード	スキミング後の無効利用	カードテスティングには無力
3Dセキュア	本人認証	なりすまし全般	離脱率が上がる
デバイスフィンガープリント	端末の同一性	アカウント乗っ取り	VPNで回避可能
機械学習スコア	多次元パターン	未知の攻撃	説明可能性が低い

Velocity Checkは単独では完結せず、AVS・CVV・3DS・MLスコアと組み合わせて多層防御を構成するのが現代の標準アーキテクチャです。

応用场景（DTC／越境ECでの実践）

1. カードテスティング対策

攻撃者は盗んだカードリストを使い、$0.50〜$1.00の少額商品で「このカードは生きているか」を確認します。同一IPから1時間に50回以上の試行が発生するため、IP単位のVelocity閾値（例：1時間8回）でほぼ確実に捕捉できます。

2. アカウント乗っ取り（ATO）対策

漏洩したメール・パスワードでログイン後、短時間に複数カードで注文を試みるパターン。メールアドレス × 24時間 × 5回のルールで検知します。

3. プロモーション悪用対策

同一IP・同一デバイスから複数アカウントを作成し、初回割引クーポンを乱用する行為。デバイスID × 24時間 × 3アカウントなどで制限します。

4. 越境特有の「BINアタック」

同一BIN（例：ある海外発行銀行のカード群）から大量の注文が集中するケース。BIN × 1時間 × 15回でフラグを立て、当該BINの承認率を監視します。

5. フラッシュセール時の誤検知抑制

セール開始直後は正規ユーザーも連続購入するため、時間帯別に閾値を動的に緩和する（例：セール中は閾値を1.5倍）運用が必須です。

常见误区

誤解1：閾値を厳しくすれば安全になる

→ 誤検知（False Positive）が急増し、正規顧客の離脱率が跳ね上がります。DTCでは承認率1%の低下が売上数百万円の損失に直結します。閾値は「ブロック」ではなく「3DSチャレンジ」に振り分けるのが推奨です。

誤解2：Velocity Checkだけで不正は防げる

→ 攻撃者は「Low & Slow」戦術（1日1回、数日かけて試行）でVelocityを回避します。MLスコアやデバイスフィンガープリントとの併用が前提です。

誤解3：IPアドレスは信頼できる識別子

→ 越境ECではVPN・プロキシ・モバイルキャリアNAT（1つのIPを数千人が共有）が一般的。IP単独の閾値は誤検知の温床になり、必ずカード・メール・デバイスと組み合わせます。

誤解4：一度ブロックすれば終わり

→ 攻撃者はカード・IP・メールをローテーションして再挑戦します。ブロックリストの自動更新と、新規識別子への即時ルール適用が必要です。

誤解5：自社でフルスクラッチ開発すべき

→ Velocity Checkはストレージ・計算コスト・リアルタイム性の要求が高く、PSPや専用SaaSの利用が現実的。自社開発は年間数千万円のTCOになりがちです。

定義