制裁リストのスクリーニングワークフローを作る：名前の一致から監査可能なレビューまで

制裁リストをダウンロードして名前の類似検索を実行するだけでは、コンプライアンス向けのスクリーニングプロダクトにはなりません。実際の運用では、同名異人、別名、翻字、企業の階層構造、識別子フィールドの欠落、リストの更新、誤検知の滞留といった問題にすぐ直面します。さらにシステム障害時には、どのワークフローを一時停止し、どれを人によるレビューに回せるか、復旧後にスクリーニングをどう遡って実施するかもチームで判断しなければなりません。

r/ComplianceOpsでのスクリーニングサービスの障害に関する議論では、ベンダーが利用できなくなった後に取引が大量にキューに滞留し、チームが一時的に公式リストをダウンロードしたものの、手動対応のルールが事前に定義されていなかったという状況が語られていました。この投稿と返信は独自に検証されたものではなく、金融機関の一般的な慣行を代表するものでもありません。それでも、プロダクト設計にとって妥当な問いを投げかけています。スクリーニングプロダクトが提供するのは検索結果なのか、それとも平常時と縮退時の両方で追跡可能な意思決定ワークフローなのか、という問いです。

最終判断ではなく情報源である公式リスト

OFAC Sanctions List Serviceは、SDN、Non-SDN consolidated、カスタマイズされたデータセット、過去の差分ファイルなどを、ダウンロード可能な形式で提供しています。取り込みレイヤーでは、元のリスト、レコード識別子、公開日時、ダウンロード日時、ファイルのダイジェスト、パースのバージョンを保持すべきです。そうして初めて、特定のスクリーニングでどのバージョンのリストが使われたかを、システムで後から確認できるようになります。

同じエンティティに、正式名称、識別力の低い別名、住所、国籍、生年月日、識別番号、船舶や航空機の識別子が紐づくことがあります。プロダクトは、これらのフィールドを一本の長い文字列にまとめてから不透明なスコアを算出してはいけません。正規化レイヤーでは、フィールドの種類と元の値を保持したまま、検索用の正規化表現を生成すべきです。転写、句読点の除去、翻字を行う場合は、いずれも説明可能でなければなりません。

リストの掲載エントリだけで、コンプライアンスの範囲全体をカバーできるわけではありません。50パーセントルールに関するOFACのガイダンスでは、1人以上の制裁対象者が合計で50パーセント以上の持分を保有している場合、リストに掲載されていない一部のエンティティも資産凍結の対象とみなされうるとしています。取引相手の名前をスクリーニングするだけでは、所有関係の調査の代わりにはなりません。プロダクトはリストへの直接ヒットと、所有関係をたどるレビューを分けて扱い、持分データのない名前検索だけで所有関係について結論を出してはいけません。

候補抽出にとどまる類似度スコア

OFAC FAQ 246では、Sanctions List Searchがあいまい一致のロジックを適用するのは名前フィールドのみで、その他のフィールドには文字の一致を用いると説明しています。つまり、名前のスコアは候補を拾い上げるためのシグナルであり、複数のフィールドを考慮したリスク確率ではありません。

プロダクトは名前、別名、翻字を使って候補の網羅性を高め、そのうえで生年月日、住所、国籍、設立法域、身分証明書、エンティティの種類を使ってアナリストの判別を支援できます。ただし、フィールドの不一致が持つ意味はデータ品質に左右されます。生年が欠落していても不一致とは限らず、住所が異なっていても過去の所在地を反映しているだけかもしれません。一方、個人と法人というエンティティ種別の食い違いは、一般により強い除外シグナルになります。インターフェースには、[87]という単一のスコアではなく、フィールドごとの比較を並べて表示すべきです。

結果の分類は、少なくとも次の4つを残すことをおすすめします。

• レビュー待ち：名前または別名が候補の抽出条件を満たしていますが、補助フィールドの情報が不十分です。
• 除外可能な候補：アナリストが明確なフィールドの違いに基づいて除外し、その根拠と有効期間を記録します。
• エスカレーション：主要なフィールドが一致している、または所有関係についてコンプライアンス担当者の判断が必要です。
• 判定不可：クエリの不備、リストデータの有効期限切れ、入力不足のいずれかにより、「通過」ステータスを表示できません。

誤検知を自動でクローズする場合は、特に慎重さが求められます。過去に同名異人として除外されたエンティティでも、新しいバージョンのリスト、更新された住所、新しい身分証明書のもとでは、引き続き除外できるとは限りません。適切な一致除外ルールは、対象の識別子、根拠となるフィールド、適用されるリスト、失効条件に紐づける必要があります。

入力品質に左右されるスクリーニング品質

上流のシステムが切り詰められた受取人名しか渡さない場合、バックエンドをどれだけ複雑にしても、欠けた身元情報は復元できません。スクリーニングAPIは、国の欠落、エンティティ種別の不明、フィールド長による名前の切り詰めの可能性、法人格を示す接尾辞の除去、解析できない識別子形式といった入力品質のヒントを返すべきです。そうすれば企業は、しきい値を下げ続けるのではなく、追加データを求めることができます。

個人、法人、船舶、航空機では、それぞれ異なるフィールドモデルを使います。すべてのオブジェクトを[name + country]に押し込めると、法人登記番号、個人の生年月日、船舶のIMO番号が持つ意味が失われます。統一インターフェースで共通のラッパーを使うのは構いませんが、オブジェクトの種類ごとに、それぞれ固有の識別力の高いフィールドを保持する必要があります。

プライバシーの境界も徹底する必要があります。スクリーニングに必要な識別フィールドだからといって、顧客データを無期限に保持してよい理由にはなりません。本人確認書類の原本、抽出したフィールド、スクリーニングリクエスト、分析結果には、ロールベースのアクセス制御と、それぞれ異なる保持期間が必要です。当サイトの統一データAPI設計ガイドラインは、ソースとなるエビデンスと業務アクションの境界設計に役立ちますが、法域や許可された目的に関する評価の代わりにはなりません。

毎日繰り返すアラートとは異なる継続的モニタリング

リストの更新後、システムは追加・変更・削除されたレコードを特定したうえで、影響を受ける可能性のあるオブジェクトのみを再スクリーニングする必要があります。安定したソースレコードIDとバージョン差分がなければ、名前の表記調整を新たなヒットと誤認したり、新たに追加された別名や識別子フィールドを見落としたりするおそれがあります。

継続的モニタリングのイベントには、リストのバージョン、変更されたフィールド、影響を受けるオブジェクト数、再スクリーニングのバッチ、処理ステータスを含めるべきです。同じ顧客が複数の取引関係にまたがって登場する場合は、エンティティ解決によってケースの重複作成を防ぎつつ、各取引関係内のアクションは独立させます。オンボーディング、決済、ベンダー登録では、担当者やタイムラインが異なる場合があるためです。

リストからの削除を、すべての取引を再開してよいという許可として自動的に解釈してはいけません。過去の凍結、拒否、エスカレーションを経た判定については、適用される規則に基づき、コンプライアンス担当者のレビューが必要になる場合があります。データの変更はタスクのトリガーにすぎず、システムが法的な結論を出すような越権行為をしてはなりません。

インシデント発生前に行う縮退対応の設計

リストのダウンロード失敗、パースエラー、スクリーニングサービスのタイムアウト、ケース管理システムの停止は、4つの異なる障害モードです。プロダクトは現在のリストバージョンと鮮度指標を表示し、期限切れのキャッシュが新たに完了したチェックとして扱われることを防ぐ必要があります。また、復旧可能なリクエストについては冪等性キーを保持し、サービス復旧時にケースが重複して作成されないようにします。

縮退ルールは、業務部門とコンプライアンス部門の責任者が事前に承認しておくべきです。どのワークフローを自動的に停止するか、どのワークフローでは下書き保存のみを許可するか、いつ手動ルーティングに切り替えるか、滞留した再スクリーニングをどの順で優先処理するかといった方針を定めます。インシデント発生中に、資金の保留を解除するか、顧客をオンボーディングするかを技術チームがその場で判断してはなりません。OFAC Compliance Commitments Frameworkは、リスク評価、内部統制、テストと監査、トレーニングをコンプライアンスプログラムの中核要素として挙げています。スクリーニングプロダクトは、これらの組織的統制を代替すると謳うのではなく、その裏付けとなるエビデンスを提供すべきです。

復旧後の処理では、停止期間中のオブジェクトと取引、当時使用されたリストバージョン、再スクリーニングで結果が変わったかどうか、差異を誰がレビューしたかを網羅した、キャッチアップスクリーニングのマニフェストを生成する必要があります。社内のAPIエラーと自己修復のガイドラインは、リトライ、縮退パス、例外キューの設計に役立ちますが、実際の保留解除ルールは権限を持つ担当者が定めなければなりません。

MVP検証の重点：誤検知ゼロではなく分析ループ

初期バージョンでは、単一のオブジェクトタイプ、単一の業務エントリーポイント、定められた公式リストのセットに対象を絞ってもかまいません。許可を得た過去のサンプルを使ってテストセットを構築し、真のヒットの再現率、無関係な候補の件数、ケースごとのレビュー時間、入力の欠落、リスト更新の遅延を記録します。偽陰性と偽陽性のコストの違いが見えなくなるため、単一の総合精度指標に頼るのは避けてください。

受け入れテストでは、クローズ済みのケースを無作為に抽出し、別のアナリストが同一の入力、リストバージョン、根拠を使って判断を再現できることを確認します。また、リスト更新とサービス停止の訓練を実施し、古い結果が黙って再利用されないこと、滞留分が保持されること、復旧後にキャッチアップスクリーニングが正常に実行されることを検証すべきです。

本記事は制裁リストのプロダクト化とエンジニアリング上の統制について論じたものであり、法務またはコンプライアンス上の助言ではありません。また、[EveryInfra]が制裁スクリーニングサービスをリリースしたことを示すものでもありません。制裁システムにとって最も重要なアウトプットは「合格」というラベルではなく、不確実性を受け止め、権限を持つ担当者によるレビューを可能にし、何年後でも再構成できる、範囲が明確に定められた意思決定プロセスです。