闭环KYB：一次会话完成所有UBO的KYC (ZH)

大多数 KYB 和 KYC 堆栈是两个拼凑在一起的产品。您在一个工具中验证公司，导出受益所有人列表，然后将这些名称重新输入到单独的身份工具中以验证个人——假设交接过程中没有遗漏任何人。 “我们了解公司”和“我们了解其背后的人”之间的鸿沟正是空壳结构隐藏的地方，也是大多数提供商敞开的鸿沟。

Didit 弥合了这一鸿沟。KYB 会话不仅可以识别最终受益所有人，还能在同一统一 /v3/ API 上为每个人生成关联的 KYC 会话。在一个单一的、相互关联的流程中验证实体及其控制人。这种闭环是 Didit 独有的：识别 UBO 和验证 UBO 不是两个产品之间有手动桥接——它们是一个连续的会话图。

本指南将详细介绍闭环 KYB 的含义、为何此鸿沟至关重要以及如何集成。

主要收获

• 一个闭环，而非两个工具。KYB 会话可以为其识别的每个 UBO 生成关联的 KYC 会话——无需导出、无需重新输入、无需遗漏名称。
• 同一统一 /v3/ API。KYB 会话及其所有者的 KYC 会话位于同一 API 上，并链接回父业务。
• Didit 独有。在同一平台上弥合公司验证和受益所有人身份验证之间的鸿沟是 Didit 独有的差异化优势，没有竞争对手能与之匹敌。
• UBO 识别免费。关键人物提取作为 2.00 美元 KYB 会话的一部分是免费的；每个 UBO 的关联 KYC 按标准用户验证费率计费。
• 全貌。您将获得一家经过验证的公司、一个已解析的所有权图以及链条末端人员的已验证身份。
• 端到端生命周期。已验证的所有者将流入持续监控；标记的交易随后可以触发补救 KYC——所有这些都在同一 API 上完成。

闭环 KYB 的作用

业务验证产生两个输出：一个已验证的实体和一份控制该实体的人员列表。如果没有第二个输出，第一个输出就毫无用处——一家公司可能注册状态完美，但仍由受制裁的个人控制。因此，KYB 义务不仅要求识别受益所有人，还要求验证所列个人是否如其所声称的那样。

Didit 的闭环在一个会话图中处理这两个方面。KYB 会话运行注册、实体 AML、文件和关键人物；关键人物识别 UBO；对于每个 UBO，可以生成关联的 KYC 会话——生物识别和文件验证实际个人——所有这些都引用父业务。没有导出步骤、没有单独的工具、没有手动协调。闭环在平台内部完成。

为何重要

KYB 和 KYC 之间的差距既是合规问题，也是欺诈问题。监管机构要求受义务实体识别并验证受益所有人——而不仅仅是从注册机构收集名称。一个止步于识别的流程会将验证步骤留给一个单独的手动工作流程，这既缓慢又容易出错，并且只能通过努力进行审计。

这也是不法分子活动的地方。一家注册数据干净、董事名单看似合理的空壳公司仍然可以充当受制裁或虚构所有人的幌子。只有通过验证 UBO 的实际身份——而不仅仅是命名他们——才能堵住这个漏洞。当该验证与公司检查在同一会话中进行时，每个受益所有人都在构建时得到考虑，而不是通过某人必须记住运行的清单。

技术细节

它从统一 /v3/ API 上的单个 KYB 会话开始。

curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "your_kyb_workflow_id",
    "vendor_data": "merchant_9912",
    "callback": "https://yourapp.com/kyb/callback"
  }'

一旦 kyb_key_people 解析出 UBO，每个 UBO 都可以携带一个引用父业务的关联 KYC 会话：

{
  "session_id": "kyb_4d81fa20",
  "status": "IN_PROGRESS",
  "vendor_data": "merchant_9912",
  "kyb_key_people": {
    "status": "APPROVED",
    "ubos": [
      {
        "name": "María García",
        "ownership_percentage": 55.0,
        "linked_kyc": { "session_id": "kyc_77c1a0", "status": "APPROVED" }
      },
      {
        "name": "Daniel Romero",
        "ownership_percentage": 45.0,
        "linked_kyc": { "session_id": "kyc_77c1b3", "status": "AWAITING_USER" }
      }
    ]
  }
}

链接。每个关联的 KYC 会话都是一个标准的“用户验证”会话——生物识别活体检测、文件验证、人脸匹配——它连接回父 KYB 会话及其 vendor_data，因此公司记录和所有者身份保持关联。

状态。KYB 会话经历业务会话生命周期（NOT_STARTED、IN_PROGRESS、APPROVED、DECLINED、IN_REVIEW、RESUBMITTED、ABANDONED、EXPIRED）；每个关联的 KYC 会话报告用户验证状态，包括 AWAITING_USER，表示所有者仍需完成其步骤。

Webhooks。订阅父级的 status.updated 和 data.updated (session_kind: business)，以及每个关联 KYC 会话的标准会话 webhook。

价格。关键人物提取作为 2.00 美元 KYB 验证的一部分是免费的。每个关联的 KYC 会话按标准用户验证费率计费。

端到端闭环

闭环的要点在于平台（而非您的运营团队）保持公司及其所有者的连接。KYB 会话识别所有者；关联的 KYC 会话验证他们；父业务记录反映组合结果。已验证的所有者随后流入持续监控，如果稍后标记了交易，则可以在同一 API 上生成补救 KYC。身份和欺诈生命周期从注册检查到持续监督都在一个平台上进行。

这种连续性是难以通过将供应商拼接在一起来复制的。一个 KYB 工具加上一个 KYC 工具再加上一个监控工具会给您带来三个系统和两个缝隙；闭环会给您一个会话图并且没有缝隙。

使用案例

• 市场平台在启用支付前，验证业务卖家实体并对每个所有者进行 KYC——在一个流程中完成，没有所有者遗漏验证。
• 金融科技和银行平台在单个连接会话中满足“识别和验证受益所有人”的要求，以开设公司账户。
• 贷款提供商在承保商业借款人时，同时验证借款实体和最终控制该实体的个人。
• 加密 B2B 平台在接入交易对手 VASPs 和企业客户时，弥合了实体筛选和所有者身份验证之间的鸿沟。

如何与 Didit 集成

1. 构建工作流。在业务控制台中，创建一个 KYB 工作流，其中启用 kyb_key_people 并为 UBO 开启关联 KYC。
2. 创建 KYB 会话。使用您的 KYB workflow_id 和业务的 vendor_data 引用 POST /v3/session/。
3. 处理 Webhook。监听父业务 webhook 和关联 KYC 会话 webhook，以跟踪闭环的两个部分。
4. 解决所有者步骤。将所有关联 KYC 为 AWAITING_USER 的 UBO 路由以完成其验证，然后读取父记录上的组合结果。

由于 KYB 会话和每个关联的 KYC 会话都位于同一统一的 /v3/ API 上，因此公司及其背后的人员可以一起进行验证——一个端到端的身份和欺诈平台。

常见问题

“闭环 KYB”是什么意思？

KYB 会话在同一统一的 /v3/ API 上为其识别的每个最终受益所有人生成关联的 KYC 会话——因此公司及其背后的人员可以在一个连接的流程中进行验证，无需导出或重新输入。

这真的是 Didit 独有的吗？

是的。将 UBO 识别和 UBO 验证作为单个平台上连续的会话图是 Didit 的差异化优势；大多数堆栈需要单独的 KYC 工具和手动交接。

费用是多少？

关键人物提取作为 2.00 美元 KYB 验证的一部分是免费的。每个关联的 KYC 会话按标准用户验证费率计费。

每个所有者如何验证？

通过标准的用户验证 (KYC) 会话——生物识别活体检测、文件验证和人脸匹配——链接回父 KYB 会话。

所有者验证后会发生什么？

已验证的所有者将流入同一 API 上的持续监控，后续标记的交易可以触发补救 KYC——在同一平台上完成完整的身份和欺诈生命周期。

准备好开始了吗？

阅读文档中的业务验证概述，在业务验证产品页面上查看它如何与平台其余部分配合，并在定价页面上查看透明的按次调用定价。准备就绪后，免费开始——每月 500 次免费 KYC 检查，以及每家公司 2.00 美元的业务验证。