ヒットしたときだけエスカレーションする継続的モニタリング

モニタリング対象の各エンティティをどのくらいの頻度で再スクリーニングするか — 日次、週次、月次 — を、ポートフォリオ全体ではなくエンティティごとに設定できます。高リスクな取引先や指定の境界線上にある名前は日次で実行し、低リスクな仕入先は月次で実行するというように、スクリーニング頻度が一律の周期ではなく、案件ごとのリスクに合わせられます。この間隔設定こそが、1回限りのスクリーニングを継続的な収録範囲へと変えるものです。エンティティは手動での再入力なしに、設定されたスケジュールに沿って自動的にすべてのソースの最新状態と照合されるため、オンボーディング後に追加された指定も、誰かがたまたま確認するタイミングではなく、次のサイクルで確実に捉えられます。

モニタリングがアナリストをノイズで埋もれさせない理由は、変化検知にあります。エンティティが再スクリーニングされるたびに、プラットフォームは結果のフィンガープリントを計算し、前回の結果と比較します。何も変わっていなければ静かなまま — アラートもチケットも発行されず、再確認のための無駄な作業も発生しません。フィンガープリントが異なる場合はアラートを発します。これは、新しいヒットの出現、指定の追加・削除、識別情報の変更、アドバースな発見事項の浮上など、重要な何かが実際に動いたことを意味するためです。この仕組みこそが、アラートを意味のあるものにします。アラートは、そのエンティティの結果が前回確認したときと違うことを示しており、まさにコンプライアンスチームがレビューすべきタイミングです。同じ既知の結果が変わらず続いているだけの定期的なリマインダーではありません。

モニタリングは、大規模には確定的に処理し、AIはそのコストに見合う場面でのみ使うよう設計されています。何千件ものエンティティを、AIモデルに一切データを送信しない確定的なQuick Checkでモニタリングし、変化によって実際にフラグが立てられたごく少数のエンティティにだけ、AI-EnhancedおよびAI Reviewのレベルを充てられます。変化検知がアラートを発したときこそ、その特定の名前をAI Review Checkにエスカレーションし、読みやすいマッチ理由の説明と誤検知の兆候を得るタイミングです。したがって一括モニタリングは、AIモデルへの個人情報の送信をゼロに保ちます — 基本サイクルは純粋な確定的スクリーニングであり、知能はあくまで変化のあった案件にのみ費やされるため、データ露出とコストの両方が、実際のリスクに比例した状態を保てます。

モニタリング対象エンティティの結果が変化すると、アラートがダッシュボードに表示され、どのエンティティが動いたか、前回サイクルと比べて何が変わったか、現在のスクリーニング結果を確認できます。そこから変化をレビューし、より深いレベルへエスカレーションするかどうかを判断し、結果をエビデンスとして記録できます。ベータ期間中は、アラートはアプリ内表示のみです。サインインした際に変化を確認する形で、メール通知はまだご利用いただけません。変化の記録は保持されるため、モニタリング対象エンティティの履歴 — 結果が動いたすべてのサイクル — が監査可能な状態になります。これは、単発の実施時点チェックではなく、継続的モニタリングのプログラムに規制当局が期待する水準です。