メインコンテンツへスキップ
ユーザーおよび企業の各エンティティは、Didit内で予測可能なライフサイクルをたどります。このライフサイクルを理解することが、オンボーディング、継続的なモニタリング、是正対応のフローを設計するうえでの鍵となります。

ライフサイクル図

ステータスの詳細

PATCH /v3/users/{vendor_data}/update-status/またはPATCH /v3/businesses/{vendor_data}/update-status/でステータスを変更すると、Webhook(user.status.updated/business.status.updated)が送信されるため、下流のシステムがリアルタイムで対応できます。

ライフサイクルのフェーズ

作成

エンティティは次の3つの方法のいずれかで作成されます。
  • 新しいvendor_dataでセッションを開始すると自動作成されます。エンティティはACTIVEステータスで作成されます。
  • POST /v3/users/create/またはPOST /v3/businesses/create/を使用してAPIで事前作成します。ステータスはデフォルトでACTIVEになります。
  • コンプライアンス担当者がコンソールで作成します。担当者が別のステータスを指定しない限り、ステータスはACTIVEとなります。
すべてのエンティティには、Diditが生成するuuidと、顧客が管理するvendor_data識別子が付与されます。

検証

セッションはvendor_dataを介してエンティティに紐付けられます。各セッションは、設定済みのワークフローに従って実行されます。本人確認、ライブネス検知、顔照合、AML、書類、KYBの法人登記照会などです。完了したセッションにより、エンティティの集計カウンターが更新されます。
  • session_count、approved_count、declined_count、in_review_count
  • featuresマップ:すべてのセッションにおける各機能の最新ステータス(例:{ "id_verification": "APPROVED", "aml": "IN_REVIEW" })
  • プロフィールのフィールドは、最新の承認済みセッションから反映されます(例:full_name、date_of_birth、portrait_image)。

利用中

エンティティに承認済みのセッションが1件以上あれば、次のことができます。
  • 取引のペイロードでvendor_dataを指定してエンティティを参照し、取引を送信する
  • 継続的なAMLモニタリングを実行する:制裁、PEP、ネガティブメディアの各リストを定期的に再スキャンします
  • スケジュールに沿って再検証する:同じvendor_dataに対して定期的に新しいセッションを作成します
  • セッションと取引をまたいでリスクシグナルを集約する

ステータスの遷移

エンティティのステータスは、自動または手動で変更されます。自動遷移
  • セッションがDECLINEDとなり、ワークフローが自動ブロックに設定されている場合はACTIVE → BLOCKED。
  • 取引がレビューのしきい値を超えた場合、またはルールによりエンティティがウォッチリストに追加された場合はACTIVE → FLAGGED。
  • 顔の生体情報がブロックリストのエントリと一致した場合はACTIVE → BLOCKED。
手動遷移は、アナリストがコンソールからステータスを変更した場合、またはupdate-statusエンドポイントを呼び出した場合に発生します。すべての遷移で、user.status.updatedまたはbusiness.status.updatedのWebhookが送信されます。

削除

エンティティはPOST /v3/users/delete/またはPOST /v3/businesses/delete/(一括)で削除します。エンティティのレコードは完全に削除されます。ユーザーを削除すると、セッション削除後も保持されていたそのユーザーの生体認証テンプレートもすべて消去されるため、その人物は重複検出や顔検索で一致しなくなります。これらのエンドポイントは本人確認セッションを対象としておらず、取引も対象外です。セッションはセッションの削除またはセッションの一括削除で削除し、取引はコンソールから削除します。

アクティビティのタイムスタンプ

エンティティはアクティビティを追跡し、休眠中またはアクティブなプロフィールを特定するのに役立ちます。 これらのタイムスタンプを使用して、休眠中のエンティティを絞り込んだり、再検証をスケジュールしたり、継続的なモニタリングをトリガーしたりできます。

ライフサイクル中に送信されるイベント

ペイロードの構造と配信の仕組みについては、エンティティのWebhookを参照してください。

次のステップ

vendor_dataによる紐付け

vendor_dataがセッション、取引、エンティティをどのように結び付けるかを説明します。

ユーザーの操作

ユーザーエンティティの作成、更新、ステータス変更、削除を行います。

企業の操作

企業エンティティの作成、更新、ステータス変更、削除を行います。
最終更新日 2026年11月1日