継続的なAMLモニタリング - 毎日の再スクリーニング

継続的モニタリングは、完全なAMLプログラムに欠かせない要素です。顧客デューデリジェンスを常に最新の状態に保ち、最初のオンボーディング後に生じるリスクの可能性を特定するのに役立ちます。この機能は、AMLチェックを実施したすべてのセッションに自動で含まれ、追加の連携作業は必要ありません。

毎日の再スクリーニングとWebhookアラートを備えた、Diditの継続的AMLモニタリングのダッシュボード

仕組み

Diditの継続的モニタリングシステムは、確認済みのユーザーをさまざまなウォッチリスト、制裁リスト、ネガティブメディアの情報源に対して継続的にチェックします。処理の流れは次のとおりです。

毎日の自動チェック:
- システムは、過去に承認されたすべてのセッションに対して、毎日自動チェックを実行します
- 各チェックでは、ウォッチリストと制裁リストの包括的なデータベースに対して、ユーザーを再スクリーニングします
- 新たに見つかった内容を、設定済みのAMLしきい値と比較します
しきい値に基づく更新:
- 設定したレビューしきい値を超える新たなヒットが見つかった場合、セッションのステータスは「審査中」に変わります
- 拒否しきい値を超える新たなヒットが見つかった場合、セッションのステータスは自動的に「拒否」に変わります
- これらのしきい値は、ワークフローで設定したものと同じです
リアルタイムの通知:
- ステータスが変更されると、アプリケーションにWebhook通知が届きます
- Webhookのペイロードには、更新後のステータスと、新たなAMLヒットの詳細情報が含まれます
- これらの通知は、標準のWebhookシステムと同じ形式です
ビジネスコンソールの更新:
- すべての変更は、ビジネスコンソールに即座に反映されます
- コンプライアンスチームは、新たなAMLヒットを調べ、詳細な結果を確認し、適切な対応を取れます
- コンソールには、すべてのモニタリング活動とステータス変更の完全な監査証跡が保持されます

ユーザーと法人のモニタリングを有効にする

コンソールから、ユーザーや法人全体について継続的モニタリングをオン/オフできます。インポートされたユーザーなど、AMLチェックを一度も受けていないユーザーも対象です。

ビジネスコンソールでユーザー(または企業)を開き、モニタリングしたいプロファイルを選択して、AML継続的監視をクリックします。
何かが実行される前に、ダイアログに費用の見積もりが表示されます。選択したプロファイルの数、新たなAMLスクリーニングが必要な数、1回限りのスクリーニング費用、年間のモニタリング費用です。
監視を有効にするをクリックします。少数の選択はすぐに完了し、大量の選択はバックグラウンドで実行され、ダイアログに進捗がライブ表示されます。
実行が終わると、ダイアログにプロファイルごとの結果が内訳として表示されます。有効化、スクリーニングして有効化、すでに有効、またはスキップ(理由付き。たとえば、スクリーニングに必要な氏名、生年月日、国が揃っていないプロファイル)です。

知っておくと役立つ点がいくつかあります。

AMLスクリーニングのないプロファイルは、先にスクリーニングされます。 Diditはそれらに対して新たなAML認証を作成し(プロファイルの認証タブに表示されます)、通常のAMLスクリーニングとして課金します。その後、そのスクリーニングでモニタリングが有効になります。
プロファイルごとに、モニタリング対象のスクリーニングは1つ。 有効にすると、ユーザーまたは法人ごとにモニタリング対象のAMLスクリーニングがちょうど1つに保たれるため、複数回認証した人でも、モニタリングも課金も1回だけです。無効にすると、そのプロファイルのすべてのスクリーニングでモニタリングがオフになります。
一覧でモニタリングの状況がひと目でわかります。 ユーザーと企業の両方の一覧に継続的な監視列があり、カーソルを合わせると次回の年次請求日が表示されます。
すべて選択はフィルターに対応します。 すべての行を選択した場合、操作は読み込み済みのページだけでなく、現在のフィルター結果に適用されます。

APIでモニタリングを有効にする

同じ操作を、APIキーを使ってバックエンドからも実行できるため、モニタリングを変更するためにプロファイルを再スクリーニングしたり、コンソールを開いたりする必要はありません。

ユーザー向け: POST /v3/users/aml-monitoring/
法人向け: POST /v3/businesses/aml-monitoring/
ジョブをポーリングする: GET /v3/aml-monitoring/jobs/{job_id}/

どちらの切り替えエンドポイントも、お客様独自の識別子のリスト(vendor_data_list)、Diditのid(didit_internal_id_list)、またはその両方を、1回の呼び出しで最大1000件まで受け付け、コンソールのルールにそのまま従います。プロファイルごとにモニタリング対象のスクリーニングは1つ、スクリーニングのないプロファイルは先にスクリーニングされ、無効にするとそのプロファイルのすべてのスクリーニングでモニタリングがオフになります。

# 1. Preview the cost. Nothing is written.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "estimate_only": true, "vendor_data_list": ["user-123", "user-456"]}'

# 2. Enable monitoring. 20 profiles or fewer complete inline (200);
#    larger selections return 202 and a job_id to poll.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'

レスポンスには、コンソールのダイアログと同じ内訳に加えて、プロファイルごとに1件のresultsエントリとその結果が含まれます。結果はenabled、screened_and_enabled、already_enabled、disabled、またはskipped_no_identity_dataのようなスキップ理由です。どれにも一致しなかった識別子はunmatchedに返されます。モニタリングの切り替え自体はWebhookを発行しません。モニタリングがオンになると、再スクリーニングで通常のstatus.updatedとdata.updatedイベントが発火します。

モニタリングが実行されたことを証明する

上記のアラート、アクティビティのエントリ、Webhookはすべて、変更があったときに発火します。1年間毎日スクリーニングされ、新たなヒットがなかった対象者には、そのどれも生成されません。そのため、「変化なし」と「何も実行されていない」が区別できず、これでは監査に耐える回答にはなりません。実行そのものを記録する画面が3つあります。 1. AMLレポート上の最終スクリーニング日。 last_ongoing_screening_atは、変更の有無にかかわらず、実行が完了するたびに更新されます。/v2/と/v3/のセッション判定、およびスタンドアロンのAMLレポートで確認できます。併せて表示されるlast_ongoing_screening_datasets_updated_atは、その実行時にプロバイダーが報告した、直近のAMLデータセットの更新日です。どちらも推定されることはありません。nullは、それぞれ「一度も再スクリーニングされていない」「データセットの日付が報告されていない」を意味し、「不明だからそれらしい日付を入れた」という意味ではありません。next_ongoing_monitoring_bill_dateをスクリーニング日として読まないでください。これは請求日です。 2. 対象者ごとのスクリーニング履歴。 GET /v1/session/{session_id}/aml-screening-history/は、そのセッションのAMLチェックについて、完了したすべての実行を新しい順に返します。結果がNO_CHANGEだった実行も含まれます。グラフワークフローにAMLノードが複数ある場合は、?node_id=を追加します。

curl https://verification.didit.me/v1/session/SESSION_ID/aml-screening-history/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "count": 2,
  "results": [
    {
      "uuid": "0d1c...",
      "completed_at": "2026-09-12T04:03:11Z",
      "started_at": "2026-09-12T04:00:02Z",
      "outcome": "NO_CHANGE",
      "trigger": "ONGOING_MONITORING",
      "status": "Approved",
      "score": 0,
      "total_hits": 0,
      "dataset_freshness": null
    }
  ]
}

フィールド	意味
`outcome`	`NO_CHANGE` — 実行が完了し、結果は変わらなかった。`CHANGED` — 実行が完了し、スコア、ステータス、またはヒットが変わった。`FAILED` — プロバイダーがこの対象者について利用できる回答を返さなかったため、何もスクリーニングされず、何も変更されなかった。カバレッジの欠落は、隠されずに記録されます。
`completed_at` / `started_at`	この対象者のスクリーニングが完了した時刻と、それが属していたバッチが開始された時刻。
`status` / `score` / `total_hits`	実行後にチェックが置かれた状態。
`dataset_freshness`	その実行時に、プロバイダーのリストがどれだけ最新だったか。データセットの日付が得られなかった場合は`null`。

3. エクスポート可能な証拠。 GET /v1/session/{session_id}/aml-screening-history/export/は、同じ履歴をCSVファイルとしてストリーミングします。完了したスクリーニングごとに1行で、プロバイダーが報告した場合はソースファミリーごとのデータセット更新日が入り、報告されなかった場合は空のセルになります。このファイルは、コンプライアンスチームが監査人に提出するものです。ビジネスコンソールでは、AMLの結果の隣に同じ一覧と同じエクスポートが用意されているため、レビュー担当者はAPIにアクセスしなくても作成できます。

提供範囲の制限を明示します。 履歴は、この機能が提供開始された時点以降のものが記録されます。それ以前のスクリーニングは再構築されず、単に存在しません。実行履歴は、設定された保持期間(デフォルトでは2年間)保管されます。データセットの鮮度は、お使いの環境でプロバイダーがデータセットの日付を公開しているかどうかに依存します。公開されていない場合、すべてのデータセットのフィールドはnullになり、GET /v1/aml/dataset-freshness/はavailability: "not_configured"を報告します。存在しない日付が代わりの値で置き換えられることはありません。

継続的モニタリングのメリット

継続的なコンプライアンス: 追加の設定なしで、AML/KYC規制への継続的な準拠を確保します。
リスクの軽減: 自動モニタリングにより、新たに生じるリスクをすばやく特定し、対処できます。
業務効率: 手間のかかる手動の再スクリーニングを、追加の連携作業なしで自動化します。
強化されたデューデリジェンス: 顧客プロファイルを自動で最新の状態に保ちます。
規制当局への対応: 継続的なコンプライアンスの取り組みを、規制当局に簡単に示せます。
ゼロタッチ連携: 追加の開発作業なしで、継続的モニタリングを利用できます。

認証

検証

モニタリング

プラットフォーム

継続的なAMLモニタリング - 毎日の再スクリーニング

仕組み

ユーザーと法人のモニタリングを有効にする

APIでモニタリングを有効にする

モニタリングが実行されたことを証明する

継続的モニタリングのメリット

​仕組み

​ユーザーと法人のモニタリングを有効にする

​APIでモニタリングを有効にする

​モニタリングが実行されたことを証明する

​継続的モニタリングのメリット

仕組み

ユーザーと法人のモニタリングを有効にする

APIでモニタリングを有効にする

モニタリングが実行されたことを証明する

継続的モニタリングのメリット