企業の背後にいる人々を検証する

KYBはUBO、株主、役員を特定し、それぞれを独自のセッションで検証します。何が収集されるか、招待の仕組み、Awaiting Userが何を意味するかを説明します。

執筆: Didit サポート · 更新日: 2026年8月31日

#このステップが存在する理由

123

1. 検証対象の企業ごとに1行あります。
2. People列には、紐づいている当事者の人数と、その進捗が表示されます。
3. 企業の判定は、その関係者が解決するまで確定しません。

企業が登記されていることを検証するだけでは、その企業が実在することしかわかりません。誰がその背後にいるかまではわからず、それこそが実際のコンプライアンス上の要件であることがほとんどです。すなわち、そのエンティティを最終的に所有または支配している自然人である実質的最終所有者を特定することです。

Diditは、公開されている場合は登記簿から所有構造を取得し、ホスト型フローの中でビジネス管理者がそれを確認・補完できるようにした上で、各人物に対して役割に応じた検証を実行します。

#当事者ごとに収集される内容

ホスト型フローでは、デフォルトの項目セットに加えて、ワークフローが要求する任意のカスタムフィールドが収集されます。

当事者は自然人にも法人にもなり得ます。エンティティの種類は自動的に設定されるため、ある企業を別の企業が所有している場合でも、人物用の枠に無理やり当てはめることなく正しくモデル化されます。

#カスタムフィールド

ワークフローでは、人物ごとまたは企業ごとに任意の数の追加フィールドを必須にできます。これらは各当事者の判定レスポンスに含まれて届きます。典型的な用途は、資金源の申告、社内の参照番号、記録として必要な誓約書などです。

#各人物がどのように検証されるか

必要な各当事者は、それぞれに設定したKYCワークフローを実行する独自のセッションを受け取ります。そのセッションは、書類、ライブネス、フェイスマッチ、AMLなど、ワークフローが指定するすべてを含む完全な検証であり、簡易版ではありません。つまり、KYBフロー内で検証されたUBOは、単独のユーザーと同じ基準で検証されています。

この間、親であるビジネスセッションはAwaiting Userに移行します。

#招待と配信

当事者は、主要関係者のステップで収集されたメールアドレス宛てに招待されます。自社の製品、自社のメール、あるいはユーザーがすでに信頼しているチャネルなど、リンクを自分たちで配信したい場合は、それがフローの設計時にDiditの担当窓口に確認すべき事項です。連携の組み方が変わってくるためです。

APIからこれを動かしている場合は、コンソールを経由せずに追跡・再送信できるよう、各当事者のセッション識別子を作成時に保持しておいてください。

#親のステータスの読み方

登記簿チェックの拒否は、Awaiting Userより優先されます。 親セッションは、関係者を待たずに拒否となります。また、子セッションが再提出されると、親セッションは完了するまでAwaiting Userに戻ります。

#企業だけでなく人物にもAMLを行う

企業レベルのAMLスクリーニングは、そのエンティティについて教えてくれますが、その所有者については何も教えてくれません。義務が人物にも及ぶ場合は、個別にスクリーニングしてください。これは企業スクリーニングとは別に、UBOまたは役員1人あたり$0.20が追加でかかります。

これが、2つのKYBセッションの費用が大きく異なり得る主な理由です。取締役1人・所有者1人の企業は安価ですが、役員が8人スクリーニングされるファンドはそうではありません。

#所有構造データが登記簿にない場合

登記簿が所有構造を公開していない法域では、主要関係者のステップがそのデータの情報源となり、企業自身がそれを申告します。これは登記簿からの抽出情報よりも弱い形の証拠であるため、リスクポリシー上、独立した確認が必要な場合は、ワークフロー内で書類の要求を組み合わせてください。登記簿のカバレッジと所有構造データをご覧ください。