継続的AMLモニタリング

承認済みの顧客を毎日、更新されたリストで再スクリーニングし、新たな該当があればセッションの状態を変更します。年間$0.07で追加の連携は不要です。

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

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

#仕組み

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

1. 継続AML監視は有効にしたセッションだけを毎日再確認します。新規分はワークフローで有効にします。初期状態はオフです。既存分は一覧で選択して継続監視 → オン、または記録のAML欄のスイッチを使います。認証への書き込み権限が必要です。AMLのないセッションは対象外です。オフにすると以後の再確認が止まり、過去の結果は残ります。
2. 閾値との比較。 新たに見つかった事項は、ワークフローで設定したものと同じ審査閾値・拒否閾値と比較されます。
3. ステータスの変化。 審査閾値を超える新たなヒットがあればセッションは審査中に移行します。拒否閾値を超えれば拒否に移行します。
4. Webhook。 アプリケーションは、更新後のステータスと新たなヒットの詳細を含むstatus.updatedのwebhookを受け取ります。形式は他のwebhookと同じです。
5. コンソール。 変化はセッション上に反映され、新たなヒットはすぐに対応できる状態で表示されます。

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

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

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

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

#料金

モニタリング対象の人物1人あたり年間$0.07です。プランクレジットまたは残高から支払われます。

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

#オンとオフの切り替え

継続AML監視は有効にしたセッションだけを毎日再確認します。新規分はワークフローで有効にします。初期状態はオフです。既存分は一覧で選択して継続監視 → オン、または記録のAML欄のスイッチを使います。認証への書き込み権限が必要です。AMLのないセッションは対象外です。オフにすると以後の再確認が止まり、過去の結果は残ります。

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

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

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

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

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

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

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