メインコンテンツへスキップ
POST
curl

概要

選択したユーザーエンティティに対して継続的なAMLモニタリングを有効化または無効化します。動作はBusiness ConsoleのAML Ongoing monitoringアクションとまったく同じです。Consoleとこのエンドポイントは同じ処理を内部で実行するため、ルール、請求、結果はすべて同一です。 まずestimate_only: trueを指定して送信すると、選択されたユーザー数、新たにAMLスクリーニングが必要なユーザー数、1回限りのスクリーニング費用、年間のモニタリング費用を確認できます。このドライランでは何も書き込まれません。

利用シーン

  • プログラムによるオンボーディング: インポートしたユーザーやAPIで作成したユーザーについて、手作業で再スクリーニングすることなくモニタリングを有効にします。
  • オフボーディング: プラットフォームを離れたユーザーのモニタリングと、その年次更新を停止します。
  • コスト管理: 選択内容を確定する前に、コストへの正確な影響をプレビューします。

選択したユーザーの処理方法

  • 監視対象のスクリーニングはユーザーごとに1件。複数回認証したユーザーでも、モニタリングと請求は1回だけです。無効化すると、そのユーザーのすべてのスクリーニングでモニタリングが停止されます。
  • AMLスクリーニングのないユーザーは先にスクリーニングされます。Diditはそのユーザーに新しいAML検証を作成し(ユーザーのVerificationsタブに表示されます)、通常のAMLスクリーニングとして請求したうえで、そのスクリーニングでモニタリングを有効にします。これにはユーザーの氏名、生年月日、国が必要です。いずれかが欠けているユーザーは、黙って除外されるのではなくskipped_no_identity_dataとして報告されます。
  • ブロックされたユーザーはスキップされます(skipped_blocked)。サンドボックスのアプリケーションではスクリーニングは作成されません(skipped_sandbox)。
  • 残高は事前に確認されます。残高が見積額に満たない場合、有効化は403で拒否されます。レスポンスには見積額が含まれるため、チャージすべき金額がわかります。
  • 年間更新。新たにモニタリング対象となったユーザーには、次回の更新日に年間モニタリング料金が請求されます。この日付はConsoleのOngoing monitoring列に表示される日付と同じです。無効化すると更新は停止しますが、すでに請求された期間の払い戻しは行われません。

選択対象とバッチサイズ

ユーザーはvendor_data_list、didit_internal_id_list、またはその両方で選択します。2つのリストはORで結合されます。1回のリクエストで受け付けられるのは、両リスト合わせて最大1000件の識別子です。アプリケーション内のどのユーザーにも一致しない識別子は、送信されたとおりの形でunmatchedに返され、リクエストが失敗することはありません。何にも一致しない選択は空のジョブ(total: 0)として完了し、すべての識別子が一覧表示されます。これは一括削除エンドポイントと同じ仕様です。

インライン処理とバックグラウンド処理

20ユーザー以下の選択はインラインで処理され、リクエストは完了したジョブとともに200を返します。それより多くのユーザーを含む選択ではPENDING状態のジョブとともに202が返されます。statusがCOMPLETEDまたはFAILEDになるまでAMLモニタリングジョブの取得をポーリングしてください。いずれの場合も、ジョブにはユーザーごとに1件のresultsエントリがあり、そのoutcomeが含まれます。

Webhook

モニタリングの切り替え自体ではWebhookは送信されません。モニタリングが有効になると、再スクリーニングのたびに、継続的なAMLモニタリングで説明している通常のstatus.updatedおよびdata.updatedイベントが引き続き送信されます。

権限

アプリケーションの有効なAPIキーであれば、どれでもこのエンドポイントを呼び出せます。DiditのAPIキーは役割単位ではなくアプリケーション単位です。Consoleの役割と権限は、人がConsoleで何をできるかを決めるものであり、Management APIのトラフィックには適用されません。

関連ページ

承認

x-api-key
string
header
必須

お客様のアプリケーションのAPIキーです。Business ConsoleのDevelopers -> API keysで取得できます。プライマリキーはフルアクセス権を持ちます。名前付きキーにはスコープを設定できます。リソースごとのアクセス権(なし、読み取り、書き込み)、一部のワークフローまたは承認済みセッションへの限定、IPアドレスのリストへの限定、有効期限の設定です。401は、キーが誤っている、失効している、または期限切れであることを意味します。403は、キーが送信されていない、キーにこのリソースやアクションへのアクセス権がない、またはIPリスト外のアドレスからリクエストが送信されたことを意味します。セッションのルートでの404は、セッションがキーのワークフローまたはステータスの対象外であることを意味します。メディアへのアクセス権がないキーでは、画像、動画、PDFのURLがnullで返されます。セッションの書き込み権限がないキーでは、セッションのリンクとトークンがnullで返されます。詳細は次を参照してください: https://docs.didit.me/console/api-keys

ボディ

application/json

vendor_data_list、didit_internal_id_list、またはその両方でユーザーを選択します(2つのリストはORで結合されます)。1回のリクエストで指定できる識別子は、両方のリストを合わせて最大1000件です。

is_enabled
boolean
必須

モニタリングを有効にする場合はtrue、無効にする場合はfalseです。

estimate_only
boolean
デフォルト:false

trueの場合、費用の見積もりを返し、書き込みは一切行いません(スクリーニング、請求、ジョブのいずれも発生しません)。

vendor_data_list
string[]

切り替えるユーザーのお客様独自の識別子で、送信した値と完全一致で照合されます。

didit_internal_id_list
string<uuid>[]

切り替えるユーザーのDidit内部IDです。作成、取得、一覧の各エンドポイントが返すdidit_internal_idを指定します。

レスポンス

estimate_onlyがtrueの場合は見積もり、インラインで処理された選択の場合は完了したジョブです。

費用のプレビュー。estimate_onlyがtrueの場合に直接返されます(何も書き込まれません)。

users_total
integer
必須

選択条件に一致したプロフィール。

already_enabled
integer
必須

すでにモニタリング中のプロフィール(有効化時には何も行われず、無効化するとこれらがオフになります)。

with_existing_aml
integer
必須

既存のAMLスクリーニングがモニタリング対象に切り替えられるプロファイル(新たなスクリーニングは行われません)。

needing_screening
integer
必須

AMLスクリーニングが一度も行われておらず、最初にスクリーニングが行われるプロファイル(通常のAMLスクリーニングとして請求されます)。

skipped_no_identity_data
integer
必須

本人情報が不足しているためスクリーニングできないプロフィール。

skipped_blocked
integer
必須

スキップされるブロック済みユーザーの数(企業の場合は常に0)。

estimated_screening_cost_usd
number
必須

新しいスクリーニングの1回限りの費用です。

例:

0.2

estimated_annual_monitoring_cost_usd
number
必須

モニタリング対象となるプロファイルの年間モニタリング費用。

例:

0.07

balance_sufficient
boolean
必須

組織の残高でスクリーニングと初年度のモニタリングを賄えるかどうか。

unmatched
string[]
必須

このアプリケーション内のどのプロフィールにも一致しなかったリクエストの識別子。送信されたとおりの値で返されます。

最終更新日 2026年11月1日