メインコンテンツへスキップ
主要人物は、検証対象の企業に関係するすべての自然人と法人を扱うDiditの統合モデルです。UBO、株主(個人および法人)、取締役、代表者、その他の役員が対象です。1つの主要人物フローですべてを扱えます。役割に応じて検証を振り分け、法人登記から取得した関係者とユーザーが提出した関係者を並べて詳細に比較できます。
企業エンティティにおける主要人物(役員やUBOがセッションをまたいでどのように集約されるか)については、企業 → 主要人物を参照してください。

​
仕組み

1

登記情報の事前入力(任意)

ワークフローで登記情報の事前入力を有効にすると、登記確認で抽出されたUBO、株主、役員のうち取得できたものが、主要人物の画面にあらかじめ入力されます。 エンドユーザーは、所有構造の情報がまだ取得待ちの段階でも、提出前に関係者を編集、追加、削除できます。 すでに受信した役員の情報は、所有構造レポートの取得中も引き続き利用できます。 提出前に遅れて届いた結果は、未編集のフィールドを埋め、不足している人物を追加します。編集内容を上書きしたり、削除された関係者を復元したりすることはありません。 開いている編集画面の内容は変わりません。追加の事前入力は、申請者が編集画面を閉じた後に反映されます。 登記情報の事前入力を無効にした場合、申請者が自分で人物を入力し、遅れて届いた結果はこのフォームに反映されません。 提出後に届いた登記データは登記確認の証跡の一部として残りますが、提出済みの人物リストは変更されず、追加の子検証セッションが自動的に作成されることもありません。
2

ホスト型フローからの提出

エンドユーザーは、ホスト型の検証フローを通じて主要人物の最終リストを提出します。デフォルトでは、このステップを開発者が呼び出す必要はありません。セッションの作成で発行したURLのKYBフロー内で処理されます。 独自のフロントエンドを使う場合は、関係者の下書きと関係者の提出のエンドポイントを使用してください。
3

役割に応じた検証の振り分け

提出された各関係者について、Diditはその役割に設定された検証設定を確認します。
  • ワークフローの所有比率のしきい値を適用します。設定された割合を下回るUBOと株主は、個別の検証を必要としません。
  • 役割でスキップが許可されている場合は、エンドユーザーが設定した「検証をスキップ」フラグに従います。
  • KYCが必要な個人の関係者に対して、子のユーザー認証(KYC)セッションを作成します。
  • ワークフローでネストされたKYBが有効な場合、法人のUBOに対して子のKYBサブセッションを作成します。
4

ステータスの推移

必須の子セッションが1つでも進行中の間、主要人物機能のステータスはAwaiting Userになります。すべての子セッションが完了すると、その結果に基づいてステータスがApproved、Declined、In Reviewのいずれかに集約されます。

​
収集する役割

主要人物には、以下の役割を1つ以上割り当てられます。1人が複数の役割を同時に持つこともできます(例: 取締役かつ株主)。全分類は次のとおりです。 すべての役割はワークフロー内で個別に設定できます。有効か無効か、KYCを必須とするか任意とするか、どのKYCワークフローに割り当てるか、スキップを許可するかを指定できます。検証の振り分けの詳細は所有構造を参照してください。

​
主要人物ごとに収集するデータ

ホスト型フローでは、デフォルトのフィールド一式と、ワークフローで設定した追加のカスタムフィールドの入力を求めます。全一覧は所有構造 → 収集するフィールドを参照してください。

​
登記情報の確認

主要人物ステップの前に、エンドユーザーは登記確認で抽出された企業データを確認し、必要に応じて任意のフィールドを編集します。その後、ホスト型フローは次の内容を保存します。
  • 登記確認からDiditが正規化した登記の詳細(registry_data)。
  • ユーザーが確認した時刻を示すタイムスタンプ付きのユーザー確認済みデータ(user_provided_data)。
  • 最上位の企業フィールドに対する正規化された統合ビュー。ユーザー確認済みの値があればそれを使い、なければ登記情報を使います。
モデル全体については企業データ → 登記データとユーザー提供データを参照してください。

​
判定レスポンスでの構造

提出後、収集された主要人物はKYBの判定内のkey_people_checks[]に表示され、2つのグループに分かれます。registry(プロバイダーが開示した内容)とsubmitted(企業の管理者がフローを通じて確認した内容)です。さらに、UBO KYCの進捗をまとめたubo_kyc_summaryが含まれます。詳細はkey_people_checksリファレンスを参照してください。

​
再提出時の動作

  • 主要人物と登記確認は直接再提出できません。特定の人物を再検証するには、その人物の個別の子KYCセッションを再提出してください。
  • 子KYCセッションが再提出されると、親の主要人物機能のステータスは自動的にAwaiting Userに戻ります。
  • 再提出された子セッションが完了すると、親の主要人物機能のステータスは、すべての子セッションのステータスに基づいて再集計されます。
  • 削除された子セッション、または本人が開始する前に期限切れになった子セッションは再提出できません。同じ関係者に新しいリンクを発行するには、関係者を再生成してください。

​
主要人物の認証リンクの有効期間

主要人物の子KYCセッションは、KYBワークフローではなく、その主要人物の役割に設定されたKYCワークフローのセッション有効期限に従います。役割を4週間の有効期限を設定したKYCワークフローに割り当てると、企業セッションの有効期限がそれより短く設定されていても、その人物のリンクは4週間利用できます。 この値はワークフローごとの設定で、1時間から4週間の範囲で指定します（session_expiration_time、秒単位）。設定場所はワークフロー → [KYCワークフロー] → 設定です。 有効期限が切れると、その当事者に対して行える操作が変わります。本人が認証を開始する前に期限切れになったリンクは、セッションが削除された場合と同様に、主要人物のKYCセッションの再生成で再発行できます。削除されたセッションは、本人がすでに認証を開始または完了していても対象になります。インポートされたセッションは、期限切れを理由に対象となることはなく、削除されている必要があります。削除されておらず、本人がすでに開始しているセッションは、期限切れでは対象になりません。

​
設定オプション

主要人物に関する動作はすべて、Business Consoleでワークフローごとに設定します。 コンソールのワークフロー → [KYBワークフロー] → 主要人物で設定します。

​
KYB審査間での検証済み個人の再利用

ワークフローで検証済み個人の再利用が有効な場合（デフォルト）、主要人物は新しいKYB審査に登場するたびにKYCをやり直す必要がありません。Diditは以前のKYB審査で承認済みとなった既存のKYCを探し、新しい子KYCセッションを作成する代わりに、そのKYCを新しい当事者に紐付けます。
これは再利用可能なKYCとは別の仕組みです。再利用可能なKYCでは、エンドユーザーが共有/インポート用のトークンを使い、完了済みの1つのセッションを、Diditと連携した別々のアプリケーション間で任意に持ち運べます。このページで説明するKYBの再利用設定は自動で行われ、ワークフローで設定し、単一アプリケーション内の主要人物に限定されます。共有トークンは不要で、エンドユーザーによるアクションも必要ありません。
照合。 候補となる一致は、送信された人物の氏名（大文字と小文字を区別せず、前後の空白を除去）を、同じアプリケーションの他のKYB審査の主要人物と比較することで検出されます。これ以外の照合シグナルはありません。書類番号、メールアドレス、電話番号の一致は必須ではなく、確認もされません。綴りの異なる名前、ミドルネームを含む名前、翻字された名前は一致しません。また、まれに同姓同名の別人が一致する場合があります。この点を踏まえて主要人物の結果をレビューしてください。 範囲。 照合の対象は、同じアプリケーションに属する他のすべてのKYB審査です。現在のKYB審査だけに限定されませんが、組織内の他のアプリケーションは対象外です。A社のUBOとして検証された人物は、両方の審査が同じアプリケーションで実行されている限り、後にB社の取締役として登場した際に一致させることができます。 対象となるステータス。 再利用の対象になるのは、当事者の最新の承認済みKYCのみです。その名前で却下されたKYCがある場合、再利用は完全にブロックされます。当事者にはフラグが付けられ、却下されたKYCに戻るのではなく、新しいKYCが要求されます。レビュー中のKYCが候補になることはありません。 保持。 照合の対象は、おおむね過去1年以内に作成され、削除されていないKYCセッションのみです。一致するセッションがこの期間外にしかない場合、または本人や組織がそのセッションを削除している場合、対象となる一致は見つからず、通知なしで新しいKYCが要求されます。この処理によって失敗したり、主要人物の送信がブロックされたりすることはありません。 請求。 再利用されたKYCが再度請求されることはありません。承認済みのセッションを新しい当事者に紐付けても追加料金は発生せず、請求は元のKYCに対する1回のみです。
Example

​
次のステップ

所有構造

収集されるフィールド、カスタムデータ、法人登記と提出内容の照合。

役員と代表者

主要人物モデルにおけるガバナンス上の役割。

レスポンススキーマ

key_people_checks[]のフィールド別リファレンス。
最終更新日 2026年11月1日