> ## 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.

# KYB 响应 Schema：决策 Payload 参考

> Didit 企业验证（KYB）决策 payload 结构详解：涵盖公司登记核查、关键人员、UBO KYC 摘要、证件、AML 筛查及共享字段。每次核验 $2.00 起。

本页面详细说明了 [`GET /v3/session/{id}/decision/`](https://docs.didit.me/zh/sessions-api/retrieve-session) 针对企业验证（KYB）会话返回的完整 payload。该 endpoint 是统一的——传入企业的 `session_id` 时，响应包含 `session_kind: "business"` 以及下方说明的企业专属功能数组。

## 顶层结构

```json theme={null}
{
  "session_id": "bs_01H...",
  "session_kind": "business",
  "session_number": 89,
  "session_url": "https://verify.didit.me/...",
  "status": "Approved",
  "status_override": null,
  "workflow_id": "wf_kyb_standard",
  "features": ["KYB_REGISTRY", "AML", "KYB_DOCUMENTS", "KYB_KEY_PEOPLE"],
  "vendor_data": "biz-acme-001",
  "metadata": { },
  "callback": null,

  "registry_checks": [ ... ],
  "aml_screenings": [ ... ],
  "document_verifications": [ ... ],
  "key_people_checks": [ ... ],

  "phone_verifications": null,
  "email_verifications": null,
  "questionnaire_responses": null,
  "ip_analyses": null,

  "reviews": [ ],
  "decision_trace": { ... },
  "linked_records": null,
  "contact_details": { ... },
  "expected_details": null,
  "created_at": "...",
  "expires_at": "..."
}
```

所有功能数组均支持多实例：每个条目代表图谱工作流中的一个节点。若为 null，则表示该功能未包含在当前会话的工作流中。

## 共享顶层字段

| 字段 | 类型 | 描述 |
| - | - | - |
| `session_id` | UUID | 唯一会话标识符 |
| `session_kind` | enum | 对于 KYB 会话始终为 `"business"` |
| `session_number` | int | 应用内的顺序编号 |
| `session_url` | URL | 托管验证链接 |
| `status` | enum | 总体会话状态（参见[状态说明](https://docs.didit.me/zh/business-verification/statuses.md)） |
| `status_override` | 对象或 null | 当审核员手动设置 `status` 且覆盖了平台原本的判定时（例如关联的关键人员验证已被拒绝，但审核员仍批准该企业），包含 `{ overridden_at, automatic_status }`。若状态为自动判定，则为 `null`。可用于区分人工批准与自动批准 |
| `decision_trace` | object | 决策达成路径说明：`status`、`decided_by`（`manual`、`automatic` 或 `investigator`）、`decided_at`、`automatic_status`、`terminal_node_id`、`actor`、`warning_counts` 以及 `status_warnings`（触发该状态的警告） |
| `linked_records` | 对象或 null | 与该会话关联的其他记录摘要。若无内容可展示则为 `null` |
| `workflow_id` | UUID | 驱动此会话的工作流 |
| `features` | 字符串数组 | 工作流运行的功能标识符（例如 `KYB_REGISTRY`、`AML`、`KYB_DOCUMENTS`、`KYB_KEY_PEOPLE`、`PHONE`、`EMAIL`） |
| `vendor_data` | string | 您为该企业设置的标识符 |
| `metadata` | object | 创建会话时附加的自定义 JSON |
| `callback` | URL 或 null | 验证完成后可选的重定向 URL |
| `contact_details` | 对象或 null | `{ email, email_lang, send_notification_emails, phone }`：当流程包含邮箱/电话通知时设置 |
| `expected_details` | 对象或 null | 创建会话时传入的企业预期数据 payload：`company_name`、`registry_country`（`XX`，或者州级登记带州代码的 `XX-YY`，例如 `US-CA`）、`registration_number` |
| `reviews` | array | 审核员对该会话的最新批注 |
| `created_at`, `expires_at` | ISO 时间戳 | — |

## `registry_checks[]`

每个条目代表一次公司登记核验（通常每次会话一次；在具有递归企业 UBO KYB 的图谱工作流中会有多次）。

```json theme={null}
{
  "status": "Approved",
  "node_id": "feature_kyb_registry",
  "data_resolved": true,
  "company": { ...see below... },
  "ownership_structure": { },
  "warnings": []
}
```

| 字段 | 描述 |
| - | - |
| `status` | 功能生命周期状态（`Approved`、`Declined`、`In Review`、`Not Finished`、`Resub Requested`） |
| `node_id` | 此核验的图谱节点标识符 |
| `data_resolved` | 当公司登记数据加载完成或用户手动提供了数据时为 `true` |
| `company` | 完整的公司登记 payload，参见下方的 **`company` 块** |
| `ownership_structure` | 交付股权结构等级时由公司登记证明的股权结构表：`shareholders[]` 和 `beneficial_owners[]`，每一项都具有与 `company.beneficial_owners[]` 相同的登记身份和持股信息（`name`、`entity_type`、`roles`、`ownership_min_shares` / `ownership_max_shares` 等）及其规范化的 `shareholding`。当登记中未证明任何股权时为 `null`。读取 `company.beneficial_owners` 和 `company.ownership` 可获取当前记录 |
| `warnings` | 针对此公司登记核验的结构化警告/日志条目。参见[企业验证警告](https://docs.didit.me/zh/business-verification/warnings.md)。 |

### `company` 块

嵌套的企业对象是从登记中获取（并可由用户选择性编辑）的法人实体的完整视图：

```json theme={null}
{
  "uuid": "...",
  "node_id": "feature_kyb_registry",
  "status": "Approved",
  "registry_status": "active",
  "data_resolved": true,
  "company_name": "Acme Corporation Limited",
  "registration_number": "12345678",
  "country_code": "GBR",
  "company_type": "Private Limited",
  "incorporation_date": "2010-05-14",
  "registered_address": "1 Main Street, London EC1A 1AA, United Kingdom",
  "tax_number": "SAMPLE-TAX-12345",
  "risk_level": null,
  "verification_status": "verified",
  "is_from_registry": true,
  "fetch_status": "resolved",
  "alternative_names": "Acme Ltd",
  "nature_of_business": "Software publishing",
  "registered_capital": "100000 GBP",
  "website": "https://acme.example",
  "email": "alex.sample@example.com",
  "phone": "+15550101000",
  "legal_entity_identifier": "529900XXXXXXXXXXXXX",
  "location_of_registration": "London",
  "vat_number": "GB980780684",
  "vat_validation_status": "format_valid",
  "vat_validated_number": "GB980780684",
  "vat_validation_source": "format_rules",
  "vat_validated_name": null,
  "vat_validated_address": null,
  "vat_checked_at": "2026-04-16T10:10:00Z",
  "financial_summary": { },
  "officers": [ ... ],
  "beneficial_owners": [ ... ],
  "addresses": [
    {
      "type": "registered",
      "address": "1 Main Street, London EC1A 1AA, United Kingdom",
      "street": "1 Main Street",
      "city": "London",
      "postal_code": "EC1A 1AA",
      "region": null,
      "country_code": "GB",
      "description": null
    }
  ],
  "industries": [
    { "code": "58290", "description": "Other software publishing", "scheme": "UK SIC 2007", "is_primary": true }
  ],
  "accounts": { ... },
  "ownership": {
    "status": "delivered",
    "tier_requested": "ubo",
    "tier_delivered": "ubo",
    "unavailable_reason": null,
    "direct_ownership_complete": true,
    "unresolved": []
  },
  "registry_tier": "ubo",
  "registry_tier_delivered": "ubo",
  "registry_ownership_status": "delivered",
  "registry_monitoring": null,
  "registry_data": { },
  "user_provided_data": { },
  "confirmed_by_user_at": "2026-04-16T10:10:00Z",
  "last_console_edit_at": null,
  "is_editable": false
}
```

| 字段 | 描述 |
| - | - |
| `registry_status` | 数据提供商报告的状态（`active`、`dissolved`、`struck_off`、`inactive` 等）。参见[状态列表](https://docs.didit.me/zh/business-verification/statuses.md#注册机构状态（来自服务商）) |
| `is_from_registry` | 当数据来自官方公司登记时为 `true`；手动输入时为 `false` |
| `fetch_status` | `pending`、`resolved` 或 `failed`：公司登记查询状态 |
| `verification_status` | `verified`、`failed` 或 `unknown` |
| `risk_level` | 从公司登记来源透传的可选值。通常为 `null`：Didit 不会计算风险等级，因此请使用 `warnings[]` 和会话 `status` 进行决策 |
| `registry_monitoring` | 该企业的最新公司登记监控，若不存在则为 `null`。仅在[公司登记监控](https://docs.didit.me/zh/business-verification/ownership.md#监控股东与实际受益人)可用后填充。字段包括：`uuid`、`status`、`unavailable_reason`、`enrolled_at`、`cancelled_at`、`last_bill_date`、`next_bill_date`、`last_event_at`、`events_count`、`watched_fields` |
| `is_editable` | 当来自公司登记的数据仍可由终端用户编辑时为 `true` |
| `registry_data` | Didit 规范化的公司登记详情：股权结构结果（`ownership_error`、`section_errors`、`ubo_resolution`）、通过 [update-data](https://docs.didit.me/zh/sessions-api/update-data.md) 所做的更正，以及没有专属字段的公司登记事实。它绝不包含登记来源自身的记录。其键随企业而异，并非固定合约：请改用规范字段 |
| `user_provided_data` | 终端用户输入或编辑的字段（用于对照公司登记值进行审计比对） |
| `confirmed_by_user_at` | 终端用户确认/编辑公司登记数据的时间戳 |
| `vat_number` | 提交的增值税号（若已收集） |
| `vat_validation_status` | 增值税号验证结果，若无增值税号则为 `tax_number` 的验证结果：`valid`、`invalid`、`format_valid`、`invalid_format`、`could_not_validate` 或 `not_applicable`。参见[增值税号与税号核验](https://docs.didit.me/zh/business-verification/company-data.md#vat-号码与税号验证) |
| `vat_validated_number` / `vat_validation_source` | 数据源所记录的已核验号码，以及判定该状态的数据源（官方公司登记或 `format_rules`） |
| `vat_validated_name` / `vat_validated_address` | 在数据源登记的名称和地址（若数据源有披露） |
| `vat_checked_at` | 执行核验的时间戳；未运行核验时为 `null` |
| `officers[]` | 包含嵌入式 KYC 增强信息的高管列表（见下文） |
| `beneficial_owners[]` | 包含嵌入式 KYC 增强信息的实际受益人（UBO）列表（见下文） |
| `addresses[]` | 公司登记中列出的所有地址，采用下方的规范地址格式。未列出任何地址时为 `null` |
| `industries[]` | 公司登记将企业活动归入的行业，采用下方的规范行业格式。未列出任何行业时为 `null` |
| `accounts` | 报告的企业备案日期：`last_annual_return_date` 和 `last_agm_date`。这些描述的是备案和会议，而非财务报表 |
| `ownership` | 股权结构（股东/实际受益人）等级的结果，采用下方的规范格式 |
| `registry_tier` / `registry_tier_delivered` / `registry_ownership_status` | 订购的等级、实际交付（并计费）的等级以及股权结构结果。相同的值也包含在 `ownership` 中 |

### 适用于所有国家/地区和登记数据源的统一格式

Didit 通过多个登记数据源读取许多国家/地区的公司登记。
每个数据源发布的格式各不相同，但 `company` 块始终保持相同的结构：无论企业来自哪个国家/地区和数据源，以下键始终存在且类型一致。
登记中未公布的事实值为 `null`；您绝不需要针对国家/地区添加分支逻辑，也无需解析 `registry_data`。
[决策](https://docs.didit.me/zh/sessions-api/retrieve-session.md)、独立的 [KYB 公司登记](https://docs.didit.me/zh/standalone-apis/kyb-registry-ubo.md) endpoint 以及托管验证流均返回相同的结构。

**地址**（`addresses` 的每个条目）

| 字段 | 描述 |
| - | - |
| `type` | 小写。注册办事处为 `registered`；其他类型按公司登记的原名称显示（例如 `postal`、`office`）。当登记中未指明地址类型时为 `null` |
| `address` | 完整的单行地址。始终存在 |
| `street`、`city`、`postal_code`、`region` | 地址拆解后的各部分（若公司登记中提供） |
| `country_code` | ISO 3166-1 alpha-2 |
| `description` | 公司登记对该地址的自有标签（若有提供） |

**行业**（`industries` 的每个条目）

| 字段 | 描述 |
| - | - |
| `code` | 公司登记中显示的活动代码 |
| `description` | 活动标签（若公司登记中提供） |
| `scheme` | 分类系统，无论由哪个数据源报告，每个系统均使用统一定义的名称（`UK SIC 2007`、`US SIC`、`NACE Rev. 2`、`NACE Rev. 2.1`、`NAF Rev. 2`、`CNAE`、`SBI`、`NOGA 2008`、`CAE Rev. 4`、`Canada SIC 1977`）。其他国家系统保留公司登记自身的名称；当登记中未指明时为 `null` |
| `is_primary` | 主要经营活动为 `true`。有且仅有一项为主营活动 |

当公司登记列出了经营活动但没有业务描述时，`nature_of_business` 会根据经营活动标签填充。
联系方式和别名在可用时会填充，而用户或审核员的显式编辑始终优先。

**股权结构** (`ownership`)

| 字段 | 说明 |
| - | - |
| `status` | `delivered`；当股权登记机构给出响应但根本未列出该公司（因此没有可提供的股权记录）时为 `not_held`；当由于任何其他原因未提供数据（记录未指明所有者、未返回股权部分或无法请求供应商）时为 `unavailable`；当公司登记仍在获取股权部分时为 `pending`；在 Basic 等级上为 `not_requested` |
| `tier_requested` / `tier_delivered` | `basic`、`shareholders` 或 `ubo`。如果 UBO 请求仅返回直接股东，则交付并计费为 `shareholders` |
| `unavailable_reason` | 未能交付所请求股权等级的原因：`no_owners_on_record`、`no_natural_person_owner`、`ownership_section_unavailable`、`company_not_found`、`ambiguous_company_match`、`missing_registration_number`、`entity_type_not_covered`、`provider_unavailable` 或 `other`。成功交付股权时为 `null` |
| `direct_ownership_complete` | 当直接股东声明的持股比例相加达到 100%（在 1 个百分点的四舍五入误差范围内）时为 `true`，未达到时为 `false`，未交付股权或未指明持股比例时为 `null` |
| `unresolved[]` | 公司登记未能解析的股权链部分，格式为 `{ reason, section }`（例如针对 `group_structure` 的 `no_group_structure_on_record`：直接所有者已知，但其上方的企业集团未在记录中） |

**公司登记详情** (`registry_data`)

Didit 自身关于公司登记核验的详情，绝非公司登记数据源的原始记录。
每个键都是可选的，仅在公司具有对应值时才会出现，并且可能会添加新键：对于规范字段所涵盖的任何内容，请优先读取上方介绍的规范字段。

| 字段 | 说明 |
| - | - |
| 登记事实（`legal_address`、`registered_address`、`registration_date`、`dissolution_date`、`registry_status`、`verification_status`、`company_type` 以及 [update-data](https://docs.didit.me/zh/sessions-api/update-data.md) 接受的其他字段） | 字符串。使用 update-data 进行的更正，以及公司登记所声明但没有独立字段的事实（`registration_date`、`dissolution_date`） |
| `ownership_error` | 未交付所请求股权等级的原因，使用与 `ownership.unavailable_reason` 相同的代码（`no_owners_on_record`、`ownership_section_unavailable`、`company_not_found`、`provider_unavailable`、`other` 等） |
| `section_errors` | 公司登记未返回的板块，以板块名称为键（`officers`、`shareholders`、`group_structure`），每个值为 `{ status_code }` |
| `ubo_resolution` | UBO 等级穿透链路的方式：`parent_chain[]` 和 `subsidiaries[]` 结构为 `{ name, country_code, registration_number }`，`unresolved[]` 结构为 `{ reason, section }` |
| `lite_enrichment` | 该国家/地区的另一个公司登记数据源填充的空白 Lite 字段：`{ fields[], people_added }` |
| `registry_metadata`, `registry_sources[]`, `previous_names[]`, `parent_companies[]`, `documents_available` | 仅限较旧的公司登记记录：登记机构自身的字段、读取的官方登记册（`{ name, source_type }`，仅命名官方登记册）、曾用名、母公司名称以及可获取的文件归档数量 |

### 管理人员项结构 (位于 `company.officers` 内部)

```json theme={null}
{
  "uuid": "...",
  "name": "Jane Doe",
  "first_name": "Jane",
  "last_name": "Doe",
  "date_of_birth": null,
  "date_of_birth_year": 1983,
  "date_of_birth_month": 2,
  "address": "1 Example Street, London",
  "appointment_date": "2024-07-01",
  "termination_date": null,
  "designation": "Director",
  "role": "director",
  "nationality": "USA",
  "is_active": true,
  "kyc_status": "Approved",
  "kyc_session_url": "https://verify.didit.me/..."
}
```

只有在公司登记提供完整日期时，才会填充 `date_of_birth`。
如果公司登记仅报告了年份或年份与月份，请使用 `date_of_birth_year` 和 `date_of_birth_month`；缺失的日期不会被推断。
姓名、出生信息、地址和任职日期在公司管理人员列表和关键人员登记列表中均可获取。

### 实际受益人项结构 (位于 `company.beneficial_owners` 内部)

```json theme={null}
{
  "uuid": "...",
  "name": "John Doe",
  "first_name": "John",
  "last_name": "Doe",
  "entity_type": "person",
  "date_of_birth": null,
  "country_of_birth": null,
  "email": null,
  "company_name": null,
  "registration_number": null,
  "nationality": null,
  "designation": null,
  "appointment_date": null,
  "voting_min_shares": null,
  "voting_max_shares": null,
  "roles": ["ubo"],
  "ownership_min_shares": "40",
  "ownership_max_shares": "40",
  "is_active": true,
  "kyc_status": "Pending",
  "kyc_session_url": "https://verify.didit.me/...",
  "effective_ownership_percent": 40.0,
  "shareholding": {
    "share_class": "Ordinary",
    "number_of_shares": 40,
    "currency": "GBP",
    "nominal_value": 1,
    "total_value": null,
    "percentage": 40
  }
}
```

`kyc_status` 采用对 B2C 安全的投影值：`Approved`、`Declined` 或 `Pending`（在 KYC 完成之前，所有会话状态均归为 `Pending`）。

`shareholding` 声明所有者持有的股份信息，在每个国家/地区和公司登记数据源中具有相同的结构：`share_class`、`number_of_shares`、`currency`、`nominal_value`、`total_value` 和 `percentage`（精确持股比例，保留四位小数）。
当公司登记未声明持股时，该字段为 `null`。
持股区间（例如英国 PSC 的 25-50%）不是确切持股比例：此时 `percentage` 为 `null`，区间保留在 `ownership_min_shares` / `ownership_max_shares` 中。
股东和 UBO 均列在 `beneficial_owners` 中；可以通过 `roles` 区分两者。

## `key_people_checks[]`

这是针对会话中所有管理人员和 UBO 的**汇总核验**。它公开了两个分桶，以便控制台可以并排渲染“从登记处提取的信息”与“由企业提交的信息”，外加概览性的 UBO KYC 摘要。

```json theme={null}
{
  "status": "Approved",
  "node_id": "feature_kyb_key_people",
  "registry": {
    "officers": [ ...registry-derived officers... ],
    "beneficial_owners": [ ...registry-derived UBOs... ]
  },
  "submitted": {
    "parties": [ ...user-submitted key-people records... ]
  },
  "ubo_kyc_summary": {
    "total": 2,
    "approved": 1,
    "flagged": 0,
    "pending": 1
  },
  "warnings": []
}
```

* **`registry.officers` / `registry.beneficial_owners`** — 从公司登记核验中提取的相关方。
* **`submitted.parties`** — 企业管理员在“关键人员”流程中显式添加的相关方（`source = "USER"` 的记录）。

### `registry.officers[]` / `registry.beneficial_owners[]`

登记处事实与上文中的 `company.officers` / `company.beneficial_owners` 一致。
关键人员还包含 AML 状态和详细的验证关联信息，例如 `kyc_session_id` 以及验证工作流字段。
企业列表保留其现有的简化 KYC 状态和验证 URL。

### `submitted.parties[]`

用户提交的相关方携带其 KYC 或子 KYB 关联信息：

```json theme={null}
{
  "uuid": "...",
  "entity_type": "person",
  "name": "Alice Chen",
  "first_name": "John",
  "last_name": "Doe",
  "email": "alex.sample@example.com",
  "role": "ubo",
  "ownership_percent": 35.0,
  "nationality": "USA",
  "position": "CEO",
  "date_of_birth": "1990-01-01",
  "phone_number": "+34612345678",
  "source": "USER",
  "requires_verification": true,
  "is_skipped": false,
  "kyc_session_id": "sess-xyz...",
  "kyc_session_status": "Not Started",
  "kyc_session_url": "https://verify.didit.me/...",
  "kyc_session_deleted": false,
  "custom_fields": { }
}
```

当为企业 UBO 启用了嵌套 KYB 时，企业相关方（`entity_type: "company"`）还会携带 `company_name`、`registration_number` 以及 `kyb_sub_session_id` / `kyb_sub_session_status` / `kyb_sub_session_deleted`。

当相关方的子会话被删除时，`kyc_session_deleted`（及其企业对应的 `kyb_sub_session_deleted`）为 `true`。被删除的子会话会保留删除时的任何状态，且永远无法结算，因此请读取此标志而不是状态：匹配的 `*_session_url` 会返回为 `null`，因为链接已无法解析，并且关键人员核验会降级为 `In Review`，而不是一直等待。删除子会话绝不算作通过。使用 [`PATCH /v3/session/{id}/kyb/parties/{party_uuid}/`](https://docs.didit.me/zh/sessions-api/update-data#跳过关键人员) 豁免该相关方以允许 KYB 结算。

### `ubo_kyc_summary`

汇总 UBO KYC 进度 — 适用于单个仪表板卡片：

| 字段 | 含义 |
| - | - |
| `total` | 拥有关联 KYC 会话的活跃 UBO 数量 |
| `approved` | 其 KYC 会话为 `Approved` 的 UBO |
| `flagged` | 其 KYC 会话为 `Declined` 或 `In Review` 的 UBO |
| `pending` | 其他所有人（尚未完成） |

当没有 UBO 拥有关联的 KYC 会话时返回 `null`。

## `document_verifications[]`

按节点分组的证件：

```json theme={null}
{
  "status": "Approved",
  "node_id": "feature_kyb_documents",
  "items": [
    {
      "uuid": "...",
      "document_type": "LEGAL_PRESENCE",
      "document_subtype": "CERTIFICATE_OF_INCORPORATION",
      "document_group": "LEGAL_PRESENCE",
      "status": "Approved",
      "file_url": "https://didit-storage.s3...",
      "document_metadata": {
        "file_size": 246810,
        "content_type": "application/pdf",
        "creation_date": "2024-05-15",
        "modified_date": "2024-05-15",
        "overlay_manipulation": null
      },
      "ocr_data": {
        "company_name": "Acme Corporation Limited",
        "registration_number": "12345678",
        "incorporation_date": "2010-05-14"
      }
    }
  ],
  "groups": {
    "LEGAL_PRESENCE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 },
    "OWNERSHIP_STRUCTURE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 }
  },
  "required_groups": ["LEGAL_PRESENCE", "OWNERSHIP_STRUCTURE"],
  "warnings": []
}
```

| 字段 | 描述 |
| - | - |
| `items[]` | 单个证件行 — 每行都有自己的 `status`、`document_type` 和 `document_group`（分组）、`document_subtype`、`file_url`（已签名）、`document_metadata` 以及 OCR 提取内容 |
| `groups` | 每个分组的进度计数器，以分组值为键（`LEGAL_PRESENCE`、`COMPANY_DETAILS`、`OWNERSHIP_STRUCTURE`、`REPRESENTATIVES_AUTHORIZATION`，外加未分类证件的 `OTHER`）。每个分组包含 `total`、`approved`、`pending`、`declined`、`in_review`、`other` 和 `missing`。参见 [KYB 证件分组](https://docs.didit.me/zh/business-verification/documents.md#证件分组) |
| `required_groups` | 您的工作流标记为必填的分组；只有全部满足时才会批准会话 |

### 企业证件元数据

对于 PDF 格式的企业证件，`items[].document_metadata.overlay_manipulation` 可以包含涉嫌叠加文本篡改的取证证据。存在时，它包括：

| 字段 | 描述 |
| - | - |
| `analysis_incomplete` | 仅当文件无法完整检查时存在且为 `true`。已检查的部分会尽可能保留其发现，并且证件会引发 `KYB_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT`。 |
| `detected` | 是否检测到叠加文本篡改证据 |
| `analyzed` | PDF 是否可以被分析 |
| `signals` | 触发的取证信号，例如 `duplicate_font_subset` 或 `glyph_fragmentation` |
| `manipulated_regions` | 涉嫌编辑文本周围的 PDF 页面坐标矩形：`page`、`x`、`y`、`width`、`height`、`page_width`、`page_height` |

当未发现叠加证据、证件不是 PDF 或 PDF 无法被分析时，该字段为 `null`。

## `aml_screenings[]`

企业级以及（当工作流配置了它们时）个人级的 AML 筛查。

```json theme={null}
{
  "node_id": "feature_aml",
  "status": "Approved",
  "total_hits": 0,
  "score": 0,
  "entity_type": "COMPANY",
  "screened_data": {
    "company_name": "Acme Corporation Limited",
    "country_code": "GBR"
  },
  "is_ongoing_monitoring_enabled": true,
  "next_ongoing_monitoring_bill_date": "2027-04-16",
  "last_ongoing_screening_at": "2026-09-12T04:03:11Z",
  "last_ongoing_screening_datasets_updated_at": null,
  "hits": [],
  "warnings": []
}
```

当 `total_hits > 0` 时，每个命中包含匹配分数、风险评分、观察名单来源以及可通过 update-aml-hit-status endpoint 更新的每个命中的 `review_status`。有关命中结构，请参阅 [AML 筛查报告](https://docs.didit.me/zh/core-technology/aml-screening/report-aml-screening.md)。

## 共享功能数组

`phone_verifications`、`email_verifications`、`questionnaire_responses`、`ip_analyses` 使用与用户（KYC）会话相同的单项结构。当工作流不包含它们时，它们为 `null`。有关单项数据结构，请参阅 [KYC 响应](https://docs.didit.me/zh/sessions-api/retrieve-session.md)。

当工作流包含 [电子签名](https://docs.didit.me/zh/core-technology/electronic-signature/overview.md) 步骤时，`signatures` 存在。企业会话中每个代表公司签名的关键人员都对应一项，包含 `signer.capacity: "company"`、公司名称以及关键人员的角色。请参阅 [电子签名报告](https://docs.didit.me/zh/core-technology/electronic-signature/report-electronic-signature.md)。

## 警告功能分组

企业验证（KYB）警告按生成它们的功能进行分组：

* `KYB_REGISTRY`：针对登记处可用性、股权结构、企业活动和国家/地区限制问题。
* `KYB_DOCUMENTS`：针对企业证件提取、交叉核对、元数据、篡改、子类型、证件年龄及尝试限制问题。
* `AML`：针对企业 AML 筛查匹配项或缺失的筛查数据。
* `KYB_KEY_PEOPLE`：针对与董事、管理人员、UBO 或代表相关的个人级别问题。
* `PHONE`：针对电话号码风险、重复、黑名单和验证码尝试问题。
* `EMAIL`：针对邮箱风险、可投递性、重复、黑名单和验证码尝试问题。
* `QUESTIONNAIRE`：针对由问卷回答驱动的自定义状态规则。
* `LOCATION`：针对设备与 IP 分析、私有网络、IP 黑名单、设备黑名单以及重复设备/IP 问题。
* `SIGNATURE`：针对电子签名拒绝、验证码确认失败、签名人姓名不匹配、未验证签名人、证件变更以及缺失字段数据问题。请参阅 [电子签名警告](https://docs.didit.me/zh/core-technology/electronic-signature/warnings-electronic-signature.md)。

有关警告代码的完整列表，请参阅 [企业验证（KYB）警告](https://docs.didit.me/zh/business-verification/warnings.md)。

## 工作流驱动的字段过滤

工作流可以通过 `response_attributes` 限制每个功能项中显示的嵌套字段。无论如何都会包含的字段包括：`status`、`warnings`、`node_id`。所有其他不在允许列表中的字段都将被置空，该键仍保留在响应中以确保架构稳定性。

## 后续步骤

> [card] [状态](https://docs.didit.me/zh/business-verification/statuses.md)
>
> 了解每个状态值的含义。

> [card] [风险评估](https://docs.didit.me/zh/business-verification/risk-assessment.md)
>
> 了解决定 KYB 结果的因素。

> [card] [AML 报告](https://docs.didit.me/zh/core-technology/aml-screening/report-aml-screening.md)
>
> 完整的 AML 命中 payload 参考。

> [card] [关键人员](https://docs.didit.me/zh/business-verification/key-people.md)
>
> 了解各方如何根据来源（公司登记或用户提交）进入 `registry` / `submitted` 分类。

> [card] [证件](https://docs.didit.me/zh/business-verification/documents.md)
>
> 证件组、OCR 及交叉核验。

> [card] [获取会话](https://docs.didit.me/zh/sessions-api/retrieve-session.md)
>
> 完整的 endpoint 参考，包含响应示例。


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