企业身份核验 API 怎么选：六个评估维度与三条合规红线

身份核验是开户、注册、交易、用工等环节的通用能力，市面上的供应商看起来都能提供「姓名+身份证号」校验，实际差异集中在数据源合规性、返回码语义、异常判定责任这三处。本文给出一套可直接用于选型评审的评估框架，并说明各类核验方式的能力边界。

一、先分清五种核验，强度完全不同

核验方式	验证的是什么	强度	典型场景
二要素（姓名+身份证号）	两者是否匹配	低	低风险注册、信息补全
三要素（+手机号/银行卡）	关联关系是否存在	中低	实名认证、支付绑卡前置
人脸活体比对	当前操作人与证件照片是否同一人	中	远程开户、面签替代
证件 OCR + 防伪检测	证件表面信息与版式是否正常	中	信息录入、材料审核
证件芯片核验（NFC）	证件本身是否为签发机构签发、数据是否被篡改	高	高风险开户、跨境身份核验

一个常见误区是把「校验通过」等同于「本人操作」。二要素和三要素证明的是数据之间的关联关系，不证明操作人身份；要证明人证合一，必须有人脸活体或芯片核验参与。

二、选型评审的六个维度

1. 数据源是否可追溯

要问清楚：核验所用的比对源是哪里授权、授权链条能否出示、是否有明确的授权期限。拿不到授权说明的接口，接入后一旦被追溯，风险由使用方承担。

2. 覆盖范围写清楚，缺口要主动披露

境内证件、港澳台证件、境外护照、港澳通行证与回乡证，覆盖度并不一致。选型时要求供应商书面列出「支持 / 不支持」清单，而不是笼统写「全球支持」。以护照芯片核验为例，我们的可核验范围是 121 个国家与地区，南非、埃及、巴基斯坦、斯里兰卡等少数签发方目前没有公开可用的信任源，这一点会在方案里直接写明。

3. 返回码语义要能区分「不合格」和「没读到」

这是接入后最容易被忽略的一处。用户侧核验未通过至少有三种原因：证件本身有问题、终端没读到芯片、网络或密钥异常。如果供应商用一个笼统的「核验未通过」覆盖全部情况，业务侧就无法区分「该拒绝」和「该让用户重试」，客诉和误拒都会上升。

4. 并发与稳定性要有可验证的口径

要求提供历史可用性与峰值并发说明，并约定限流策略与降级方式。批量场景（如集中开户、存量客户复核）尤其要提前确认是否有并发上限。

5. 计费口径必须写明

按调用计费还是按成功计费，差异在批量场景下可能达到数倍。另外要确认「用户中途取消」「证件异常」是否计费——这些细节建议直接写进合同附件。

6. 判定责任怎么划

供应商给的是核验结论还是原始证据，两者责任不同。若业务需要留存证据（如审计、纠纷举证），要在接入时确认能否返回可留存的核验记录，以及保存期限。

三、合规上三条硬要求

• 最小必要：只取业务必需字段，不因为「接口支持」就全量采集。
• 单独同意：明确告知核验目的、方式与范围，取得用户单独授权，不能混在通用协议里。
• 可追溯：记录核验时间、结果码、调用来源与操作人，出现争议时能还原过程。

四、几个具体问题的回答

护照芯片核验为什么比 OCR 可靠？

OCR 读的是证件表面，翻拍、改图、模板合成都能骗过；芯片核验读的是证件内置芯片，并用签发国的证书对芯片数据做密码学校验，能判断证件是否由签发机构签发、数据是否被篡改。代价是需要支持 NFC 的终端，以及维护各国证书信任链——后者是长期投入，不是接一次就能一劳永逸的。

港澳通行证、回乡证能不能离线验签？

不能这样承诺。这几类证件可以读取芯片信息，但其签发机构的证书未公开分发，离线环境无法完成密码学验签。可以做的是芯片读取 + 信息比对，真伪判定仍需依赖权威源核验。

自建还是采购？

如果只需要二要素、三要素这类基础核验，采购接口的成本远低于自建；如果涉及证件芯片核验，自建意味着要持续维护多国证书信任链与吊销信息，这部分投入通常被低估。判断标准是：核验是否属于你的核心竞争力，以及你能否承担信任链的长期维护。

五、关于羽山数据