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

# 交易监控状态参考：交易、案件与 Travel Rule

> Didit 交易监控状态参考：涵盖每种交易、案件和 Travel Rule 状态及其流转与含义。每月包含 1,000 笔交易，之后每笔 $0.001。

交易监控有三套独立的状态机：**交易**、每个**案件**，以及（适用时）**Travel Rule 核验**。本页为参考手册。

## 交易状态

在创建时设置，并随生命周期更新。

| 状态 | 含义 |
| - | - |
| `APPROVED` | 交易通过了审核阈值以下的所有规则。 |
| `IN_REVIEW` | 分数超过审核阈值，或某条规则明确要求审核。需要分析人员关注。 |
| `DECLINED` | 分数超过拒绝阈值，或某条规则明确拒绝。交易已被拒绝。 |
| `AWAITING_USER` | 用户必须先完成操作，交易才能结算。Didit 仅通过规则设置此状态：规则的 `change_status` 操作（例如可选启用的库规则 `travel-rule-pending-action`，它会在 `ON_HOLD` 状态的 Travel Rule 转账上触发），或要求补充验证的规则操作（已创建补救会话）。需要证明钱包控制权的 Travel Rule 转账本身不会设置此状态：交易保持规则给出的状态（通常为 `APPROVED`），并且只要存在待处理的小组件会话，`action_required` 块就会包含钱包所有权 URL。请阅读交易的 `action_required` 块，以获取具体操作和 URL。 |

### 状态流转

```mermaid theme={null}
stateDiagram-v2
    [*] --> APPROVED: Score < review threshold, no blocking rules
    [*] --> IN_REVIEW: Score >= review threshold
    [*] --> DECLINED: Score >= decline threshold, or rule decline action
    [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER
    IN_REVIEW --> APPROVED: Analyst cleared
    IN_REVIEW --> DECLINED: Analyst declined
    AWAITING_USER --> APPROVED: Remediation session approved
    AWAITING_USER --> DECLINED: Remediation session declined
    AWAITING_USER --> IN_REVIEW: Remediation session ended in review
```

注：除 Travel Rule 外，`APPROVED` 或 `DECLINED` 不会直接转换为其他状态。
Travel Rule 过期时，无论当前状态如何，您的 `timeout_outcome` 都会将状态设为 `IN_REVIEW`（`HOLD`）或 `DECLINED`（`REJECT`）。在 Travel Rule 状态转换之后触发的规则，可能会更改 `APPROVED` 交易。
如需更正，请通过控制台使用状态补丁；这些更正会记入审计日志。

## 警报

没有单独的警报状态。
处于打开状态的警报就是 `IN_REVIEW` 或 `AWAITING_USER` 状态的交易，因此请使用上述交易状态。
参见 [警报](https://docs.didit.me/zh/transaction-monitoring/alerts.md)。

## 案件状态

完整说明参见 [案件管理](https://docs.didit.me/zh/console/case-management/cases.md)。

| 状态 | 含义 |
| - | - |
| `OPEN` | 正在积极调查。 |
| `AWAITING_USER` | 等待用户方提供输入。 |
| `RESOLVED` | 已结案，并附带结论：`FALSE_POSITIVE`、`VALID_THREAT`、`INCONCLUSIVE`、`REQUIREMENTS_NOT_MET` 或 `REQUIREMENTS_SATISFIED`。 |

案件另有 **优先级**（`LOW`、`MEDIUM`、`HIGH`）。

## Travel Rule 核验状态

根据 FATF Travel Rule 进行的虚拟资产转账会运行专门的 **13 状态交换流程**，它与上述交易状态相互独立。
出站转账的起始状态为 `AWAITING_COUNTERPARTY`、`NOT_APPLICABLE`（低于 `threshold_amount`）、`UNCONFIRMED_OWNERSHIP`（对方钱包声明为自托管）、`COMPLETED`，或 `COUNTERPARTY_MISMATCHED_DATA`（在已验证钱包上进行 `INTERNAL` 匹配，取决于姓名匹配结果），也可能是 `COUNTERPARTY_VASP_NOT_FOUND` 或 `COUNTERPARTY_VASP_NOT_REACHABLE`。
入站转账也可能以 `ON_HOLD` 或 `NOT_ENOUGH_COUNTERPARTY_DATA` 起始。与已验证钱包匹配、且收款人姓名相符或缺失的 sunrise 注册，会直接经由 `COMPLETED` 进入 `FINISHED`。
交换以 `FINISHED`、`CANCELLED` 或 `EXPIRED` 结束。

| 状态 | 含义 |
| - | - |
| `AWAITING_COUNTERPARTY` | 已发送给对方，等待其响应。通过 TRUST 发送的转账会一直保持此状态直至过期，因为 TRUST 不会返回 Didit 能够读取的任何内容。在沙盒应用中，转账会发送至 [Didit 测试 VASP](https://docs.didit.me/zh/transaction-monitoring/travel-rule-sandbox.md)，它会在 Didit 内部按您选择的场景作出响应。 |
| `UNCONFIRMED_OWNERSHIP` | 收款钱包的所有权尚未得到证明。 |
| `ON_HOLD` | 仅 Didit 在入站转账上设置此状态：sunrise 注册或入站 `TRP` 询问所对应的钱包不在您的地址簿中（如果是仅提供姓名的询问，则其姓名不匹配任何单一已验证持有人）；或入站 `TRP` 询问需要您手动决定（自动接受已关闭，或无法送达自动回复）。它本身不会更改交易状态；可选启用的库规则 `travel-rule-pending-action` 会将交易设为 `AWAITING_USER`。请通过 `POST /v3/transactions/{id}/travel-rule/ownership/` 处理此状态。 |
| `COMPLETED` | 汇款人与收款人数据匹配，可安全地在链上广播。 |
| `FINISHED` | 已报告链上哈希，交换结束。 |
| `CANCELLED` | 已从非终态取消。 |
| `EXPIRED` | 确认超时已过。只有在截止时间仍处于 `AWAITING_COUNTERPARTY` 的转账才会过期，系统每 15 分钟检查一次；其他状态永不超时。您的 `timeout_outcome` 会应用于交易，且该变更不会发送 `transaction.status.updated` Webhook。 |
| `COUNTERPARTY_MISMATCHED_DATA` | 收款人姓名不匹配。 |
| `COUNTERPARTY_VASP_NOT_FOUND` | 没有任何通道能够解析对方。 |
| `COUNTERPARTY_VASP_NOT_REACHABLE` | 已识别对方，但 Didit 无法送达：其 `TRP` 端点不可访问，或报告的 LEI 不同或缺失，或姓名不同；或网络通道（GTR、TRUST、VerifyVASP、Sygna Bridge）无法送达消息。 |
| `COUNTERPARTY_VASP_GENERAL_DECLINE` | 对方拒绝了此次交换。 |
| `NOT_ENOUGH_COUNTERPARTY_DATA` | 入站 `TRP` 询问既未提供收款人姓名，也未提供地址。它没有截止时间，所有权端点也无法解析它，因此请使用 `action: "cancel"` 取消，发送方不会收到通知。Didit 从不在出站转账上设置此状态；只有当您自行记录时，它才会出现在出站转账上，且您可以使用 `action: "resend"` 重试此类转账。 |
| `NOT_APPLICABLE` | 低于 `threshold_amount`，因此未进行任何交换；或您在 Didit 不运行的转账上记录的值（Travel Rule 已禁用、交易类型不是 `travelRule`，或为旧版值）。 |

较早的集成可能仍会发送旧版值 `UNKNOWN`、`COMPLIANT`、`PENDING_ACTION`、`PENDING_COUNTERPARTY`、`FAILED` 和 `EXEMPT`；Didit 会自动将它们映射到上述状态。

权威参考请见 [Travel Rule](https://docs.didit.me/zh/transaction-monitoring/travel-rule.md#生命周期)。

## 提供方结果状态

每个外部提供方的结果（钱包筛查、法币监控、制裁筛查）都会按其自身状态存储，并在交易响应的 `provider_results[]` 中返回。

| 状态 | 含义 |
| - | - |
| `PENDING` | 提供方查询处理中。 |
| `COMPLETED` | 已成功返回结果。 |
| `FAILED` | 提供方出错或超时。 |
| `SKIPPED` | 提供方被有意跳过（例如交易金额低于阈值）。 |

## 规则运行结果

每个 `TransactionRuleRun` 包含以下字段：

* `matched`（布尔值）：规则是否触发？
* `is_test`（布尔值）：规则是否处于 TEST 模式？
* `mode`：评估时的模式，即 `ACTIVE`、`DISABLED` 或 `TEST`。
* `score_delta`：对分数的贡献（仅当已匹配且处于启用状态时）。
* `status_target`：规则请求的状态（仅当操作为 `change_status` 时）。

有关规则结构，请参阅 [规则](https://docs.didit.me/zh/transaction-monitoring/rules.md)。

## 决策原因代码

状态转换时常见的 `reason` 值：

| 原因 | 含义 |
| - | - |
| `rule_score_threshold` | 分数超过审核或拒绝阈值。 |
| `rule_change_status` | 规则的 `change_status` 操作强制设置了状态。 |
| `analyst_approved` / `analyst_declined` / `analyst_cleared` | 分析师的人工操作。 |
| `user_action_approved` / `user_action_declined` / `user_action_in_review` | 关联整改会话的结果（即在 `AWAITING_USER` 状态下请求的用户操作）。 |
| `provider_update` | 外部提供方更新了结果。 |
| `aml_confirmed_sanction` | AML 筛查确认命中制裁名单。 |
| `blocklist_applicant` / `blocklist_counterparty` | 对某一方执行黑名单处置。 |

## 后续步骤

> [card] [风险评分](https://docs.didit.me/zh/transaction-monitoring/risk-scoring.md)
>
> 分数如何映射到状态。

> [card] [警报](https://docs.didit.me/zh/transaction-monitoring/alerts.md)
>
> 警报生命周期。

> [card] [案件](https://docs.didit.me/zh/transaction-monitoring/cases.md)
>
> 案件生命周期。


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