# 决策规则与阈值

Source: https://help.didit.me/zh/workflows/decision-rules
Updated: 2026-10-12

每项检查都会产生警告，而如何处理每个警告由你决定：通过、审核，还是拒绝。这个映射关系，才是你风险偏好真正落地的地方。

每个步骤都会把自己的**警告**映射到一个动作：通过、审核或拒绝。
被配置为拒绝的步骤会**中止整个工作流**，后续步骤永远不会运行，你也不会为它们付费。
这使得规则顺序既是一个风险决策，也是一个成本决策。

[Video: 条件化工作流：按 AML 风险评分分流用户 - Didit Academy](https://www.youtube.com/watch?v=Qp3qzFDvTC8&t=91)

## 决策实际发生在哪里

很容易把工作流理解成"我要运行的这些检查"。
但检查只是其中一半。
另一半，也就是真正决定你通过率的那一半，是每项检查的**警告**被配置成了什么动作。

![Didit 工作流构建器，包含功能节点和发布按钮](https://help.didit.me/screenshots/workflow-builder-light.webp)

*每个节点决定自己的结果；工作流决定这个结果意味着什么。*

对每个步骤而言，它能产生的每个警告都会映射到以下三种动作之一：

| 动作 | 效果 |
|---|---|
| **批准**（或忽略） | 警告会被记录下来，但不会改变结果 |
| **审核** | 会话进入审核中，交由人工判断 |
| **拒绝** | 会话被拒绝，工作流中止 |

这个映射关系，就是以配置形式表达出来的你的政策。

## 拒绝会中止工作流

这是最让人意外的行为，值得明确说清楚：当某个步骤拒绝时，执行会在那里中止。
之后的步骤**永远不会运行**。

有两个后果：

1. **结果里会缺少你原本预期的检查项。** 它们不是失败了，而是根本没有执行。一个在身份证件验证阶段被拒绝的会话，不会有活体检测、人脸比对或 AML 的结果。
2. **你不会为它们付费。** 计费是按已完成的功能计算的，一个从未运行的步骤不产生任何费用。

## 用规则顺序控制成本

因为拒绝会中止流程，步骤顺序就成了一个花费上的杠杆。
把便宜的风险检查放在昂贵检查组合的前面，意味着本来就通不过的流量会在你为昂贵部分付费之前就被拦下。

设备与 IP 分析（0.03 美元）放在完整 KYC 流程前面，是标准做法：它能便宜地过滤掉你本来也会拒绝的流量。

> **Warning:** 这里的权衡是用户体验和误判率。
> 设备与 IP 信号是 Didit 提供的检查中噪音最大的一类，企业网络、运营商 NAT 和云端浏览器都会让真实用户共享同一个地址。
> 把整个流程的通过与否都押在它们上面会拦下真实客户，因此除非你已经测量过自己的真实流量，否则应该把它们导向**审核**，而不是直接拒绝。

## 需要判断力，而不是自动化的规则

有些警告是明确无误的，应该直接拒绝：MRZ 校验和失败、芯片签名无法链接到签发机构、命中你自己黑名单上的人脸。这些属于完整性失败。

另一些几乎总是更适合走审核：

- 地址证明上的部分地址匹配，各国的格式差异很大。
- 数据库验证中的部分姓名匹配，权威数据源记录姓名的方式各不相同。
- 低置信度的 AML 候选命中，常见姓名会持续产生这类命中。
- 临界值附近的人脸比对结果，参见[人脸比对分数与阈值](https://help.didit.me/zh/liveness-biometrics/face-match-thresholds)。
- 重复人脸标记，对新账户来说是欺诈信号，对回访客户来说则是正常情况。

还有一些属于可用性失败，值得给一次**重试**，而不是直接下结论：未读取到的 NFC 芯片、模糊的拍摄、丢帧的摄像头画面。

## 年龄策略

最小和最大年龄是按工作流配置的，违反时采取什么动作也由你选择。
`MINIMUM_AGE_NOT_MET` 既可以直接拒绝，也可以在你的政策允许凭证据例外时导向审核。
两种做法都是合理的，请刻意做出选择。

## 针对提取数据的自定义规则

除了按警告映射之外，你还可以针对某个步骤提取出的数据编写规则，例如当提取字段取某个特定值时拒绝。
有两点需要留意：

- 规则只能作用于该步骤实际产出的数据。如果 OCR 没有提取出该字段，规则就没有可评估的对象。
- 一条导致拒绝的规则仍然会中止工作流，后果与前文相同。

如果你要编写一条基于受保护特征触发的规则，请先把它当作合规团队要解答的法律问题，而不是工程问题。

## 测试规则，而不只是测试步骤

工作流的步骤用肉眼很容易验证，但它的规则不行，唯一能确认某个警告是否按你预期路由的方法，就是真的触发那个警告。

沙盒正是为此存在的。
每个场景都会强制触发一个特定的警告，让你可以端到端地确认每条规则的动作：`decline_document_expired`、`review_face_match_borderline`、`decline_aml_hit`、`review_poa_partial_match` 等等。
参见[在沙盒中测试](https://help.didit.me/zh/getting-started/sandbox-and-testing)。

> **Tip:** 测试**审核**路径要和测试拒绝路径一样仔细。
> 一条导向审核的规则，只有在真的有人处理这个队列时才有意义，而要知道你的审核流程是否真的能运作，唯一方法就是在真实客户等待之前，先让一个模拟会话走一遍这个流程。

## 修改只应用于新会话

编辑工作流不会追溯改变已经创建的会话。
会话携带的是它创建时的配置，因此在修改规则之后，请用一个**新**会话测试，而不是重新检查一个旧会话。