> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# 实体：Didit 用户与企业

> Didit 的两大核心实体是用户和企业。每个实体都将 KYC 会话、交易、证件、生物识别和风险信息汇总到一份档案中。

Didit 围绕两种核心实体类型组织您应用中发生的一切：**用户**和**企业**。

| 实体 | 代表对象 | 关联对象 |
| - | - | - |
| **User** | 个人 | 用户验证（KYC）会话、人脸生物特征、交易（作为申请人或交易对手）、黑名单 |
| **Business** | 法人实体（公司、LLC、个体工商户、基金） | 企业验证（KYB）会话、高级管理人员、UBO、交易（作为申请人或交易对手）、黑名单 |

每个验证会话、每笔交易和每条黑名单记录都可以绑定到一个实体。绑定后，该实体会成为一份持久的档案，并汇总跨时间的历史记录、风险信号和合规状态。

## 实体与会话

**实体**和**会话**是两个不同的概念。

| 概念 | 范围 | 生命周期 | 示例 |
| - | - | - | - |
| **会话** | 一次验证事件 | 单个流程（在审核期间可持续数分钟到数天） | 一次 KYC 尝试 |
| **实体** | 持久档案 | 只要该用户或企业在您的平台上存在，就一直有效 | 客户“Jane Doe”，两年内共有 3 次用户验证（KYC）会话 |

一个实体可以对应多个会话，包括重新验证、重新提交、附加检查和定期持续监控。实体会汇总这些结果。

## 自动创建与手动预创建

实体有以下三种创建方式：

**1. 从会话自动创建**

当您使用 `vendor_data` 标识符创建会话，且不存在匹配的实体时，Didit 会自动创建该实体。这是最常见的方式。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{ "workflow_id": "wf_kyc_standard", "vendor_data": "user-42" }'
```

会话开始时，系统会立即为 `user-42` 创建一个 User 实体。

**2. 通过 Management API 预先创建**

先创建实体，再针对该实体启动会话。当您希望在首次验证之前预先写入风险信号（状态、标签、自定义元数据）时，这种方式很有用。

```bash theme={null}
curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{ "vendor_data": "user-42", "display_name": "Jane Doe" }'
```

**3. 在控制台中创建**

您的合规团队可以直接在 Business Console 中创建用户或企业。适用于手动入驻、导入或整改流程。

## 实体如何关联所有内容

`vendor_data` 字段是关联的关键。在任何会话或交易中传入 `vendor_data` 时，Didit 会将其路由到匹配的实体。

```mermaid theme={null}
flowchart LR
    VD["vendor_data:<br/>user-42"] --> U[User entity]
    S1[User Verification (KYC) session #1] --> VD
    S2[User Verification (KYC) session #2] --> VD
    T1[Transaction #1] --> VD
    T2[Transaction #2] --> VD
    F[Face biometric] --> VD
    D[Documents] --> VD
    BL[Blocklist entry] --> VD
```

进一步了解请参阅 [`vendor_data` 关联指南](https://docs.didit.me/zh/entities/vendor-data-linking)。

## 您可以对实体执行的操作

对于每个 User 或 Business 实体，您可以执行以下操作：

| 操作 | 用途 |
| - | - |
| **创建/更新** | 设置或更改实体的档案数据（姓名、国家/地区、自定义元数据） |
| **更改状态** | 标记为 `ACTIVE`、`FLAGGED` 或 `BLOCKED`，该状态的强制执行会应用于后续会话和交易 |
| **附加生物特征** | 上传人脸参考图像，用于 1:N 搜索、重复检测或加入黑名单 |
| **查看 KYC/KYB 历史记录** | 检索与该实体相关的全部会话及各功能的结果 |
| **查看交易历史记录** | 检索该实体作为申请人或交易对手的全部交易 |
| **添加到黑名单** | 阻止涉及该实体的后续会话或交易 |
| **导入/导出** | 从 CSV 批量导入实体，或导出以供外部合规工具使用 |
| **删除** | 删除该实体（历史记录将为审计保留） |

详细操作指南请参阅 [用户](https://docs.didit.me/zh/entities/users/overview.md) 和 [企业](https://docs.didit.me/zh/entities/businesses/overview.md)。

## 用户 ↔ 企业关系

一个 User 可以关联一个或多个 Business。这在 KYB 过程中会自然发生：

* 一个 User 可能是一家 Business 的**董事**，同时是另一家 Business 的 **UBO**。
* 用户的用户验证（KYC）会话，可以通过[关键人员](https://docs.didit.me/zh/business-verification/key-people.md)流程与企业的企业验证（KYB）会话相关联。

Didit 会保留这些关系。查看 Business 实体时，您可以看到所有关联的 User；查看 User 实体时，您可以看到其关联的所有 Business。

## 生命周期和状态

每个实体都有一个状态，决定 Didit 是否阻止新的活动：

| 状态 | 影响 |
| - | - |
| `ACTIVE` | 正常。会话和交易将按工作流和规则的配置继续进行 |
| `FLAGGED` | 允许会话和交易，但会自动转入人工审核 |
| `BLOCKED` | 会话和交易会被自动拒绝，且无法创建新会话 |

有关状态转换和 Webhook 事件，请参阅完整的[实体生命周期](https://docs.didit.me/zh/entities/lifecycle.md)。

## 后续步骤

> [card] [生命周期](https://docs.didit.me/zh/entities/lifecycle.md)
>
> 每个实体的状态、转换和生命周期事件。

> [card] [供应商数据关联](https://docs.didit.me/zh/entities/vendor-data-linking.md)
>
> `vendor_data` 如何绑定会话、交易和实体。

> [card] [用户](https://docs.didit.me/zh/entities/users/overview.md)
>
> 深入了解 User 实体、操作和控制台工作流。

> [card] [企业](https://docs.didit.me/zh/entities/businesses/overview.md)
>
> 深入了解 Business 实体、操作和控制台工作流。

> [card] [实体 Webhook](https://docs.didit.me/zh/entities/webhooks.md)
>
> 每次实体变更的实时事件。

> [card] [黑名单](https://docs.didit.me/zh/console/blocklist-users.md)
>
> 黑名单记录如何与 User 和 Business 实体交互。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.