如何解读核验结果
一个会话的结果由状态、每项检查各自的结果，以及一份警告列表组成 - 警告才是真正告诉你实际发生了什么的部分。
请按以下顺序阅读：先看整体状态，再看各项检查的状态，最后看警告。 只有警告能告诉你为什么会是这个结果 - 其余部分只能告诉你发生了什么。
无论你查看的是控制台、webhook 负载还是 API 响应，从商业控制台的核验记录中打开任意会话，看到的都是同样的三层结构。
- 从这里开始：判定结果，以及产生该结果的各项检查。
- 「活体检测」标签页保存着自拍结果和人脸比对分数。
- 证件标签页显示了提取到的内容，以及哪些字段匹配成功。
- 「事件」标签页说明了会话是如何走到当前状态的。
#第一层 - 整体状态
会话的唯一判定结果：已通过、已拒绝、审核中等等。大多数集成正是基于这个结果来采取行动。它是一个综合结果：由你工作流的配置方式将各项检查的结果组合而成，因此它本身不会告诉你究竟是哪一项检查导致了这个结果。
#第二层 - 每项检查各自的结果
每一项运行过的检查都有自己的状态和数据。你最常见到的有：
| 检查项 | 需要关注什么 |
|---|---|
| 身份证件核验 | 提取到的字段（姓名、证件号码、日期）、证件类型与国家/地区，以及 MRZ 是否通过校验 |
| 被动 / 主动活体检测 | 是否检测到真实活人，以及任何攻击信号 |
| 人脸比对 1:1 | 自拍与证件照片之间的相似度分数 |
| 人脸搜索 1:N | 该人脸是否匹配已核验用户或黑名单中的条目 |
| AML 筛查 | 命中记录，每条都带有匹配分数和风险分数 |
| 设备与 IP 分析 | 国家/地区、VPN 或代理信号、被列入黑名单的地址 |
| 地址证明 | 提取到的地址，以及它与你提供的地址匹配的程度 |
| NFC | 芯片是否被成功读取，以及其签名是否链接到可信的签发机构 |
| 手机 / 邮箱 | OTP 是否已确认，以及号码或邮箱地址上的风险信号 |
单项检查可以是已通过，而整个会话却是已拒绝，反过来也一样。这是正常现象 - 会话状态是所有检查结果的综合体现，而不是取其中最差的一项。
#第三层 - 警告
警告这一层才是真正解释结果的部分。每条警告都是附加在触发它的检查上的一个具体、命名过的代码，例如：
DOCUMENT_EXPIRED- 证件的有效期已过。MRZ_VALIDATION_FAILED- 机读区的校验和未通过。这是一个很强的篡改信号。LOW_FACE_MATCH_SIMILARITY- 自拍与证件照片的得分低于你设置的阈值。LIVENESS_FACE_ATTACK- 在自拍过程中检测到仿冒攻击。POSSIBLE_MATCH_FOUND- AML 发现了一条需要处理的候选命中。NFC_DATA_DOES_NOT_MATCH_OCR- 芯片数据与印刷数据不一致。IP_ADDRESS_IN_BLOCKLIST- 该连接来自你屏蔽的地址。
在排查某个具体会话时，直接看警告即可。状态告诉你结论；警告告诉你证据。 每项功能的完整警告目录都记录在 核心技术文档中。
#提取的数据与你的预期对比
如果你在创建会话时传入了 expected_details（例如你已持有的姓名、出生日期或证件号码），结果还会告诉你证件内容是否与之一致。这里出现不一致，通常是你这边的数据录入问题，而不是证件本身有诈，因此在拒绝任何人之前，都值得先检查一下这一点。
提取出的姓名可能经过了音译。使用西里尔字母、阿拉伯字母或希腊字母的证件， 生成的拉丁字母姓名即使对应的是同一个人，也可能无法与你的记录逐字符匹配。 在将姓名不匹配视为欺诈之前，请同时比对证件号码或出生日期。
#sandbox 结果看起来会略有不同
在 sandbox 会话中，控制台会在提取数据的区域标注一个模拟数据标签。媒体确实是真实采集的，但字段内容和结果都来自你所选择的场景 - 因此不要对这些数值本身做过多解读。详见在 sandbox 中测试。
#通过编程方式获取同样的内容
webhook 负载和 GET /v3/session/{id}/decision/ 接口都会在一个 decision 对象中携带全部三层信息。请将 webhook 作为你的唯一可信来源，轮询仅用于核对 - 有些事件（例如审核人员对数据的修改）只会通过 webhook 送达。详见通过 webhook 获取结果。
#为你的记录获取一份副本
如需用于审计或监管报送，可以将会话下载为 PDF - 其中汇总了每一个步骤、提取的数据、生物识别分数、AML 结果和最终判定结果。详见下载核验报告。