决策规则与阈值
每项检查都会产生警告，而如何处理每个警告由你决定：通过、审核，还是拒绝。这个映射关系，才是你风险偏好真正落地的地方。
每个步骤都会把自己的警告映射到一个动作：通过、审核或拒绝。 被配置为拒绝的步骤会中止整个工作流，后续步骤永远不会运行，你也不会为它们付费。 这使得规则顺序既是一个风险决策，也是一个成本决策。
#决策实际发生在哪里
很容易把工作流理解成"我要运行的这些检查"。 但检查只是其中一半。 另一半，也就是真正决定你通过率的那一半，是每项检查的警告被配置成了什么动作。
- 每个功能节点都带有自己的阈值和自己的决策。
- 一项检查可以是必选或可选，这本身就是一个关于谁能通过的决策。
- 保存工作流之后，修改过的规则会应用到新会话上。
对每个步骤而言，它能产生的每个警告都会映射到以下三种动作之一：
| 动作 | 效果 |
|---|---|
| 批准（或忽略） | 警告会被记录下来，但不会改变结果 |
| 审核 | 会话进入审核中，交由人工判断 |
| 拒绝 | 会话被拒绝，工作流中止 |
这个映射关系，就是以配置形式表达出来的你的政策。
#拒绝会中止工作流
这是最让人意外的行为，值得明确说清楚：当某个步骤拒绝时，执行会在那里中止。 之后的步骤永远不会运行。
有两个后果：
- 结果里会缺少你原本预期的检查项。 它们不是失败了，而是根本没有执行。一个在身份证件验证阶段被拒绝的会话，不会有活体检测、人脸比对或 AML 的结果。
- 你不会为它们付费。 计费是按已完成的功能计算的，一个从未运行的步骤不产生任何费用。
#用规则顺序控制成本
因为拒绝会中止流程，步骤顺序就成了一个花费上的杠杆。 把便宜的风险检查放在昂贵检查组合的前面，意味着本来就通不过的流量会在你为昂贵部分付费之前就被拦下。
设备与 IP 分析（0.03 美元）放在完整 KYC 流程前面，是标准做法：它能便宜地过滤掉你本来也会拒绝的流量。
这里的权衡是用户体验和误判率。 设备与 IP 信号是 Didit 提供的检查中噪音最大的一类，企业网络、运营商 NAT 和云端浏览器都会让真实用户共享同一个地址。 把整个流程的通过与否都押在它们上面会拦下真实客户，因此除非你已经测量过自己的真实流量，否则应该把它们导向审核，而不是直接拒绝。
#需要判断力，而不是自动化的规则
有些警告是明确无误的，应该直接拒绝：MRZ 校验和失败、芯片签名无法链接到签发机构、命中你自己黑名单上的人脸。这些属于完整性失败。
另一些几乎总是更适合走审核：
- 地址证明上的部分地址匹配，各国的格式差异很大。
- 数据库验证中的部分姓名匹配，权威数据源记录姓名的方式各不相同。
- 低置信度的 AML 候选命中，常见姓名会持续产生这类命中。
- 临界值附近的人脸比对结果，参见人脸比对分数与阈值。
- 重复人脸标记，对新账户来说是欺诈信号，对回访客户来说则是正常情况。
还有一些属于可用性失败，值得给一次重试，而不是直接下结论：未读取到的 NFC 芯片、模糊的拍摄、丢帧的摄像头画面。
#年龄策略
最小和最大年龄是按工作流配置的，违反时采取什么动作也由你选择。
MINIMUM_AGE_NOT_MET 既可以直接拒绝，也可以在你的政策允许凭证据例外时导向审核。
两种做法都是合理的，请刻意做出选择。
#针对提取数据的自定义规则
除了按警告映射之外，你还可以针对某个步骤提取出的数据编写规则，例如当提取字段取某个特定值时拒绝。 有两点需要留意：
- 规则只能作用于该步骤实际产出的数据。如果 OCR 没有提取出该字段，规则就没有可评估的对象。
- 一条导致拒绝的规则仍然会中止工作流，后果与前文相同。
如果你要编写一条基于受保护特征触发的规则，请先把它当作合规团队要解答的法律问题，而不是工程问题。
#测试规则，而不只是测试步骤
工作流的步骤用肉眼很容易验证，但它的规则不行，唯一能确认某个警告是否按你预期路由的方法，就是真的触发那个警告。
沙盒正是为此存在的。
每个场景都会强制触发一个特定的警告，让你可以端到端地确认每条规则的动作：decline_document_expired、review_face_match_borderline、decline_aml_hit、review_poa_partial_match 等等。
参见在沙盒中测试。
测试审核路径要和测试拒绝路径一样仔细。 一条导向审核的规则，只有在真的有人处理这个队列时才有意义，而要知道你的审核流程是否真的能运作，唯一方法就是在真实客户等待之前，先让一个模拟会话走一遍这个流程。
#修改只应用于新会话
编辑工作流不会追溯改变已经创建的会话。 会话携带的是它创建时的配置，因此在修改规则之后，请用一个新会话测试，而不是重新检查一个旧会话。