メインコンテンツへスキップ
Diditは、アプリケーション内で起こるすべてを、2種類の主要なエンティティタイプを軸に整理します。 すべての検証セッション、すべての取引、すべてのブロックリストのエントリを、エンティティに紐付けられます。紐付けると、エンティティは履歴、リスクシグナル、コンプライアンスの状態を時間をかけて集約する、永続的なプロフィールになります。

​
エンティティとセッション

エンティティとセッションは別のものです。 1つのエンティティに、再検証、再提出、追加のチェック、定期的な継続モニタリングなど、多数のセッションを持たせることができます。エンティティはその結果を集約します。

​
自動作成と手動での事前作成

エンティティは、次の3つの方法のいずれかで作成されます。
1

セッションから自動作成

vendor_dataの識別子を指定してセッションを作成し、一致するエンティティがない場合、Diditはエンティティを自動的に作成します。これが最も一般的な方法です。
セッションが開始された時点で、user-42のユーザーエンティティが作成されます。
2

Management APIで事前作成

先にエンティティを作成し、それに対してセッションを開始します。最初の検証の前に、リスクシグナル（ステータス、タグ、カスタムメタデータ）を設定しておきたい場合に便利です。
3

コンソールで作成

コンプライアンスチームは、Business Consoleから直接ユーザーや法人を作成できます。手動でのオンボーディング、インポート、是正ワークフローに便利です。

​
エンティティがすべてを結び付ける仕組み

vendor_dataフィールドが、結び付けのキーです。セッションや取引にvendor_dataを渡すと、Diditは一致するエンティティにそれを振り分けます。 詳しくは、vendor_dataの紐付けガイドを参照してください。

​
エンティティでできること

ユーザーまたは法人のエンティティごとに、次のことができます。 詳しい手順は、ユーザーと法人にあります。

​
ユーザーと法人の関係

1人のユーザーを、1つまたは複数の法人に紐付けられます。これはKYBの中で自然に発生します。
  • ユーザーは、ある法人の取締役であり、別の法人のUBOであることがあります。
  • ユーザーのユーザー認証（KYC）セッションは、主要関係者のフローを通じて、法人の法人確認（KYB）セッションに紐付けられます。
Diditはこれらの関係を保持します。法人エンティティを確認すると、紐付けられたすべてのユーザーが分かり、ユーザーエンティティを確認すると、関連するすべての法人が分かります。

​
ライフサイクルとステータス

すべてのエンティティにはステータスがあり、新しいアクティビティに対してDiditがブロックを適用するかどうかを決めます。 遷移とWebhookイベントについては、エンティティのライフサイクルの全文を参照してください。

​
次のステップ

ライフサイクル

すべてのエンティティの状態、遷移、ライフサイクルイベント。

vendor_dataの紐付け

vendor_dataがセッション、取引、エンティティを結び付ける仕組み。

ユーザー

ユーザーエンティティ、操作、コンソールのワークフローの詳細。

法人

法人エンティティ、操作、コンソールのワークフローの詳細。

エンティティのWebhook

すべてのエンティティの変更をリアルタイムで通知するイベント。

ブロックリスト

ブロックリストのエントリが、ユーザーおよび法人エンティティとどう連動するか。