継続的AMLモニタリング

モニタリングは、承認済みの顧客を毎日、更新されたリストに対して再スクリーニングし、閾値を超える新たな事項があればセッションを動かします。年間$0.07で、追加の連携作業は不要です。

執筆: Didit サポート · 更新日: 2026年8月19日

#一度きりのスクリーニングでは不十分な理由

オンボーディング時のスクリーニングは、その日リストが何を示していたかを教えてくれるだけです。指定は追加され続け、ネガティブ報道は蓄積し、3月には問題なかった人物が8月には制裁対象になっていることもあります。継続的顧客管理を最新の状態に保つ義務がある場合（ほとんどの規制対象事業者に該当します）、1回のスクリーニングではその義務を満たせません。

#仕組み

AMLチェックが実行されたセッションでは、追加の連携作業なしで自動的にモニタリングが利用可能です。

123

1. スクリーニングを継続する人を選び、モニタリングをオンにします。
2. スクリーニングを継続する人にチェックを入れます。モニタリングは組織単位ではなく人単位です。
3. 新たなマッチがあるとセッションが再開されるため、受信箱ではなくここに表示されます。

1. 毎日の自動チェック。 これまでに承認されたすべてのセッションが、ウォッチリストと制裁データベース全体に対して再スクリーニングされます。
2. 閾値との比較。 新たに見つかった事項は、ワークフローで設定したものと同じ審査閾値・拒否閾値と比較されます。
3. ステータスの変化。 審査閾値を超える新たなヒットがあればセッションは審査中に移行します。拒否閾値を超えれば拒否に移行します。
4. Webhook。 アプリケーションは、更新後のステータスと新たなヒットの詳細を含むstatus.updatedのwebhookを受け取ります。形式は他のwebhookと同じです。
5. コンソール。 変化はセッション上に反映され、新たなヒットはすぐに対応できる状態で表示されます。

#想定して構築すべきこと

承認済みのセッションでも、後からステータスが変わることがあります。 自社の連携が承認済みを最終状態として扱い、リスニングを止めてしまうと、モニタリングが本来届けるはずのイベントを見逃すことになります。

具体的には次のようにしてください。

• すでに検証済みとマークしたセッションについても、status.updatedの処理を続けてください。
• 何週間も前にクローズしたセッションだからといって、webhookを無視しないでください。
• 自社のユーザー状態が「検証済み」から戻せるようにしておいてください。これは通常、単なるハンドラーの変更ではなく製品上の判断が必要な、より難しい変更です。

#料金

モニタリング対象の人物1人あたり年間$0.07です。無料枠の対象ではありません。

1回ごとではなく年間で料金が設定されているため、毎日のスクリーニング頻度がそのままコストの増加につながりません。これにより、継続的モニタリングは、利用量を抑える対象ではなく、大量に使っても手頃な価格に収まる仕組みになっています。

#オンとオフの切り替え

モニタリングはAMLステップと並んで、ワークフローごとに設定します。有効化した時点以降のセッションに適用されるため、オンにしても既存の承認済みの顧客群に対して遡ってモニタリングが始まるわけではありません。過去の顧客もカバーする必要がある場合は、バックフィルを計画してください。

#その先の対応を人員配置する

チームが見落としがちなのは連携作業そのものではなく、モニタリングが継続的なキューを生み出すという点です。新たなヒットには、オンボーディング時のヒットと同じ解決作業が必要です。自社の顧客かどうか、重要かどうか、そして判断理由の記録です。AMLヒットへの対応をご覧ください。

このキューを誰も担当していない場合、モニタリングは未読のまま放置されるアラートを生み出すことになり、これはモニタリングをしていない状態よりも悪い結果です。通知されていたのに何もしなかったという証拠が残ってしまいます。

#モニタリングはトランザクションモニタリングとは別物

名前が似ている2つの別物です。

• AMLモニタリングは人物を時間の経過とともにリストと再照合します。本記事の内容です。
• トランザクションモニタリングは取引が発生するたびにルールと照合します。トランザクションモニタリングの仕組みをご覧ください。

両方が必要になることも多く、それぞれ別々に課金されます。