はじめに
疑わしい取引検知では、既存の取引データだけで条件を作れるとは限りません。
新しい外部APIから取得する情報や、これまで保存していなかった補足情報を使いたくなることがあります。
このとき、いきなり検知類型まで作り込むと、条件の妥当性を確認しづらくなります。
この記事では、疑わしい取引検知で新しいデータソースを使うときは、先にデータを蓄積してから類型を決めた方がよい、という考え方を整理します。
データがないと閾値を決められない
検知条件を決めるには、実データの分布を見る必要があります。
例えば、外部APIから取得するリスクスコアを検知に使いたいとします。
このとき、スコアがどの範囲にどれくらい分布するのかが分からなければ、閾値を決められません。
- 80点以上で何件引っかかるのか
- 90点以上で何件引っかかるのか
- 既存の検知対象とどれくらい重なるのか
- 正常なユーザーも大量に含まれていないか
- 確認できる件数に収まるのか
こうした確認は、データが一定量たまってからでないと判断しにくいです。
先に取得と保存だけを作る
新しいデータソースを使う場合は、まず取得と保存だけを作る進め方が有効です。
最初から検知条件、通知、管理画面、運用フローまで一気に作る必要はありません。
まずは次のような状態を目指します。
- 外部APIから必要な項目を取得できる
- 取得結果をDBに保存できる
- 取得日時が残っている
- 取引やユーザーと紐づけて確認できる
- 後からSQLで件数を確認できる
この状態まで作っておくと、実データを見ながら検知条件を検討できます。
類型は実データを見てから決める
データがたまったら、SQLで分布や件数を確認します。
例えば、架空の例ですが、過去30日分のリスクスコアを見たとします。
| 条件 | 対象件数 |
|---|---|
| 70点以上 | 480件 |
| 80点以上 | 92件 |
| 90点以上 | 14件 |
この結果だけを見ると、80点以上がよさそうに見えるかもしれません。
しかし、実際には対象の中身も見る必要があります。
80点以上に本当に確認すべき対象が多いのか、既存の類型と同じユーザーばかりではないか、確認側が処理できる件数かを見ます。
ここでいう類型とは、「短期間に高額入金がある」「複数アドレスへ送金している」など、疑わしい取引を検知するためのパターンやルールの単位を指します。
類型は、項目が追加された瞬間に決めるものではありません。
実データを見ながら、条件として意味があるかを確認して決めるものです。
先に類型を決めるとずれやすい
データがない状態で類型を決めると、想定と実態がずれやすくなります。
例えば、次のようなことが起きます。
- ほとんど検知されない
- 想定より大量に検知される
- 正常な取引ばかり引っかかる
- 既存類型と重複して新しい意味が薄い
- 保存した項目だけでは判断材料が足りない
この場合、実装した後に条件や保存項目を見直すことになります。
もちろん、最初から完全に正しいデータ設計をするのは難しいです。
それでも、まずデータをためてから類型を決める進め方にすると、検知条件を現実に合わせやすくなります。
保存時に残しておきたい情報
後から検知条件を検討するなら、値だけを保存するのではなく、確認に必要な情報も残しておく必要があります。
例えば、次のような情報です。
- 取得元
- 取得日時
- 対象ユーザー
- 対象取引
- 取得した値
- 判定に使ったバージョン
- 取得に失敗した場合の理由
特に外部APIを使う場合、後から同じ結果を再取得できるとは限りません。
そのため、検知条件を決める前の段階でも、あとで検証できる形で保存しておくことが重要です。
まとめ
疑わしい取引検知で新しいデータソースを使う場合、いきなり検知類型まで作り込むと判断が難しくなります。
まずは取得と保存だけを作り、一定期間データを蓄積します。
そのうえで、実データの分布、検知件数、既存類型との重複、運用側が確認できる件数を見ながら類型を決めます。
検知条件は、想像だけで決めるより、実データを見てから決めた方が現実に合いやすくなります。