AMLヒットへの対応

ヒットは判定ではなく候補です。それが自社の顧客かどうか、重要かどうかを判断し、監査に耐えられる形で判断内容を記録する方法を説明します。

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

Short answer

順番に2つの問いを立ててください。これは自社の顧客か（マッチスコア）、そして重要かどうか（リスクスコアとカテゴリー）です。ほとんどのヒットは最初の問いで不合格になります。非常に大規模なリストに対して名前が一致しているだけのケースです。いずれの結論であっても判断理由を記録してください。監査担当者が読むのはその判断の経緯です。

#ヒットは候補である

スクリーニングエンジンの役割は、リストに載っている可能性のある人物を洗い出すことです。それが本当にそうなのか、そしてどう対応するかを決めるのはあなたです。POSSIBLE_MATCH_FOUNDという警告は、まさにその意味しか持ちません。

The verifications list in the Didit console with status filters and the bulk status action
  1. ヒットを保持しているセッションだけに絞り込み、判断が必要なものだけをキューに残します。
  2. マッチを判断したら、ここでセッションの結果を設定します。
  3. クリアにした顧客も監視を続ければ、将来のリスト掲載も届くようになります。
ヒットは、それが属するセッションの判定を決めることで解決されます。

#ステップ1: これは本当に自社の顧客か

ヒットに含まれる識別情報を、検証で確認済みの情報と照合します。

比較項目有効な理由
生年月日最も強い判別要素です。不一致であれば、たいていそれで決着します
国籍と国自社の顧客とまったく関わりのない国でのヒットです
ミドルネームや父称を含むフルネーム部分的な名前の一致が、誤検知の主な原因です
ヒット記録上の識別番号リストに掲載されている場合

よくある名前は、制裁リストやPEPリストに対して大量の低信頼度マッチを生みます。これは不具合ではなく、名前ベースのスクリーニングの性質です。キューがこれで埋まっている場合、マッチ閾値が低すぎます。AMLスクリーニング結果の理解をご覧ください。

Tip

ここでは音訳が重要です。非ラテン文字の名前は複数の妥当なローマ字表記を持ち得るため、同一人物が文字列として一致しない綴りで現れたり、逆に異なる人物が同じ綴りに収束したりすることがあります。そうしたケースでは、生年月日と国籍をより重視してください。

#ステップ2: 重要かどうか

自社の顧客本人だった場合、対応を決めるのはカテゴリーであり、ここでリスクスコアが関わってきます。

  • 制裁マッチ。 最も深刻なものです。自社の制裁対応手順に従って処理してください。安易に判断してよいものではありません。
  • PEP。 PEPは犯罪者ではありません。多くの規制体系では、PEPステータスは拒否ではなく強化された継続的顧客管理（追加情報の取得、資金源の確認、上級者による承認など）を引き起こします。PEPを自動的に拒否するのは1つのポリシー上の選択ですが、通常は望ましくない選択です。
  • RCA。 PEPの親族や近しい関係者で、同じ理由でスクリーニングされ、通常は同様に扱われます。
  • ネガティブ報道。 タグ付けされたカテゴリーを読んでください。1回報じられた申立ては有罪判決ではなく、自社のポリシーはその違いを区別すべきです。
  • 国・地政学的リスク。 通常は判断そのものではなく、リスク評価の入力値です。

#ステップ3: 判断を記録する

コンソールでヒットを解決する際は、判断理由を説明するメモを添えてください。ここが後から重要になる部分です。監査担当者が関心を持つのは、ヒット率そのものよりも、判断が一貫した方法で行われ、証跡が残っているかどうかです。

2年後にあなたがいない状態で、他の誰かが読むことを想定してメモを書いてください。実際にそうなるからです。「生年月日が14年異なり、国籍も異なるため棄却」は有用です。「マッチではない」は有用ではありません。

すべての操作は365日間、監査ログに記録されます。監査ログの利用をご覧ください。

#見落としなく誤検知を減らす

効果の高い順に並べると次のとおりです。

  1. マッチ閾値を上げる。 自社で測定した誤検知率に見合う水準まで上げてください。決定の前に必ず測定してください。
  2. セッション作成時に、より多くの識別情報を渡す。 生年月日を伴うスクリーニングは、名前だけによるスクリーニングよりも格段に精度が高くなります。
  3. 拒否ではなく振り分ける。 候補としてのヒットは、ほぼ常に自動拒否ではなくレビューに回すべきです。
  4. リスクに応じて閾値を分ける。 高価値のオンボーディングフローと低リスクの年齢確認では、同じAML設定は必要ありません。

#4アイズ承認

AML判断に2人のレビュアーを必要とするプロセスの場合、Diditは2人目が確認を行う4アイズフローに対応しています。4アイズレビューをご覧ください。

#モニタリングはヒットを再び呼び戻す

継続的モニタリングを有効にしている場合、以前承認された顧客が後から新たなヒットを生み、審査中に戻ることがあります。これは不具合ではなく機能が正しく動作している証拠であり、ヒットの解決がオンボーディング時だけの単発作業ではなく、継続的に人員配置すべきプロセスであることを意味します。継続的AMLモニタリングをご覧ください。

#本番前に練習する

サンドボックスには2つのAMLシナリオがあります。decline_aml_hitは拒否に至るヒットを生成し、review_aml_possible_matchは、スコアの内訳を含む実際のヒットと同じスキーマで、審査中となる低信頼度のヒットを生成します。実際の顧客を待たせる前に、これらを使ってチームに解決プロセスを練習させてください。サンドボックスでのテストをご覧ください。