卡在审核中的会话，以及如何减少它们

审核中意味着自动化检查已经完成，但标记出了需要人工处理的问题 - 它永远不会自行解决。本文介绍如何清空队列并降低进入审核的比例。

Didit 支持团队撰写 · 更新于 2026年9月8日

在所有状态中，审核中引发的支持咨询最多，原因很简单：它看起来像是平台还在处理，但实际上平台已经处理完毕，正在等你处理。

#审核中究竟意味着什么

所有自动化检查都已运行完毕。其中至少有一项发出了警告，而你的工作流将该警告导向了人工审核，而不是自动判定。该会话现在停留在你的队列中，直到有人处理它为止。没有任何超时机制会替你最终做出决定，也没有办法让系统重新运行检查并自行改变结果。

#清理一个会话

1. 打开审核队列

   在商业控制台中，进入核验记录，并按状态审核中进行筛选。

2. 阅读警告，而不只是看状态

   打开会话，查看是哪一项检查标记了它，以及警告的具体内容。这决定了你实际在做的是什么决定。详见如何解读核验结果。

3. 做出决定

   批准、拒绝，或仅针对失败的步骤请求重新提交。添加一条备注 - 它会成为审计记录的一部分。

4. 通知你的后端

   该决定会触发一个 status.updated webhook，让你的系统自动获取最终状态，无需你手动核对。

123

1. 筛选状态：审核中，只查看正在等待你处理的会话。
2. 「状态」列就是审核中出现的地方；在有人做出决定之前，它不会发生变化。
3. 勾选多行，然后使用「更改状态」批量批准或拒绝。

#你的审核比例为何可能偏高

大致按可能性从高到低排列：

1. 人脸比对阈值设置得过于接近。 如果你的审核区间过宽，普通的光线变化就会落入其中。详见人脸比对分数与阈值。
2. AML 审核阈值设置在较低的匹配分数上。 常见姓名在较低匹配分数下就会产生候选命中。将审核阈值设得过低，会导致几乎所有人都被送去审核。详见处理 AML 命中。
3. 地址证明部分匹配。 各国地址格式差异很大；一个缩写上的差异就可能被判定为部分匹配。请刻意决定部分匹配应该进入审核还是直接通过。
4. 数据库验证部分匹配。 原因相同 - 权威数据源中记录的姓名写法不一致。
5. 合法回访用户被标记为重复人脸。 如果同一个真实的人核验了不止一次，就会与自己匹配上。详见重复检测。
6. 「为求稳妥」将每一条警告都导向审核。 把所有内容都送去审核，等于什么都没有审核，因为队列会积压到无法处理。请挑选那些真正需要人工判断的警告。

#调整工作流顺序，让审核更早、成本更低地发生

如果你的流程成本较高，而大量会话最终仍然进入了审核，那么将成本低的风险检查放到前面，就能让流程在昂贵的检查运行之前提前止步。在完整 KYC 流程前放一个 $0.03 的设备与 IP 分析，可以减少在原本就不会通过的流量上的支出。

这里的权衡在于用户体验：在第一步就被拦下的用户没有投入任何成本，但他们也无从得知具体原因。请根据你的转化漏斗，判断哪一点对你更重要。

#双人复核

如果你的合规流程要求两个人共同签字确认一个决定，Didit 支持双人复核流程，需要第二位审核人员进行确认。详见双人复核。

#审核中不是什么

• 它不是「仍在处理中」。 如果你在等待平台完成处理，你要找的状态是进行中。
• 它不是一种软性拒绝。 处于审核中的会话此时还没有任何判定结果，因此不要在你自己的系统中将其映射为「已拒绝」- 应将其映射为它自己独立的待处理状态。
• 它不是支持团队可以替你决定的事。 只有你的团队才有权批准或拒绝你自己的客户。支持团队可以解释会话为什么被标记，但需要你提供 session_id。

#持续监控可能会让已通过的会话重新回到审核中

如果你开启了 AML 监控，一个此前已通过的会话之后可能会转为审核中，原因是每日重新筛查发现了一条超过你审核阈值的新命中。这是预期行为，而不是回归缺陷 - 这正是持续监控存在的意义。详见持续 AML 监控。