e签宝身份认证服务商介绍：五个子产品拼出一条从核验到出证的链路

认证要回答的不是「有没有实名」，是三个问题

企业上线一套认证，最常见的起点是合规清单上的一条：签署前要做实名。做完这一条，流程看起来就齐了。

放进真实业务里，认证要回答的是三个问题。第一，参与业务的主体是谁；第二，当前这次操作是不是真实、自愿，操作的人有没有对应的权限；第三，出了争议，能不能把过程还原出来，并且拿得出可信的证据。只回答第一个问题，后两个问题会在业务跑起来之后暴露。

这三个问题决定了 e签宝 认证服务的产品形状。它不是一组孤立的核验接口，而是围绕一次业务办理从发起到留证的全过程。

统一入口：五个子产品组成一条认证链

e签宝 认证服务对外是一个统一入口，内部由五个子产品构成：个人认证、企业认证、信息比对、风险检测、证件识别。

业务系统发起认证或风险查询请求后，认证服务按场景判断走个人还是企业流程；过程中调用证件识别采集证件信息，调用信息比对判断提交信息与权威数据是否匹配；再按主体类型调用对应的风险检测；最后输出认证结果、风险信息、检测结果和审计信息。

这条链回答的问题依次是：身份确认、资格与权限确认、意愿确认、风险决策、电子签署、证据存证。六个环节连起来，客户拿到的不是一次「通过」的判断，而是一条能支撑业务办理、授权和签约的记录。

在数据来源一侧，e签宝 是国家数据局第五批公共数据「跑起来」示范场景参与单位。

个人认证：验的是「人、证、号」三者的同一性

个人认证面向自然人身份核验，按业务的安全等级和合规要求，组合不同的认证要素。

基础方式是信息核验：二要素（姓名加证件号）、三要素（姓名、证件号、手机号）比对提交信息与权威数据是否一致。需要更强保证时，叠加人脸比对、活体检测和刷脸认证；再往上，有视频双录、动作方式认证与无源比对这类增强方式。

个人认证还处理一类容易漏掉的输入：证件本身。这里用上证件识别子产品，对证件影像做采集、字段识别和质量校验，把证件信息结构化之后，再与身份信息和人脸信息做联动比对。外籍人士、海外证件和海外 eKYC 场景走的是另一套扩展能力。

企业认证：主体存续之外，还要回答授权关系

企业认证确认两件事：企业主体信息是否真实、经营身份是否在册；以及，操作的人与企业之间是什么关系。

第二件事是这类认证里更容易被做漏的一段。企业不会自己签名，办事的是经办人。企业认证的能力包括企业主体基础信息核验、法定代表人或经办人身份认证、企业授权关系确认，以及企业认证与个人认证的联动。对外表现为一整套合规流程，比如经办人实名叠加法人授权的组合。

两段分开看，就能理解为什么企业认证和个人认证不能互相替代：个人认证的输出是「这个自然人身份为真」，企业认证的输出是「这家主体真实存续，且这个人有权代表它办事」。

信息比对与证件识别：把核验成本放到该放的位置

信息比对和证件识别是两个常被当成辅助、实际决定成本的子产品。

信息比对做的是跨来源的一致性校验：个人二要素、三要素比对，人脸与证件照片比对，两照比对与权威库照比对，企业主体及授权关系相关信息核验。它的位置很灵活——既可以是个人认证、企业认证当中的一个环节，也可以单独嵌进注册、签署、开户、授信、变更这些流程里。

这个灵活性对应的是成本结构。同一条业务链路里，不同环节的风险高低不同。注册环节做一次轻量比对，开户或授信时再上人脸和活体，是更合理的配置；每个环节都按最高强度做，成本会上去，转化会下来。

风险检测：输出的不是「通过」，是风险等级

风险检测面向个人和企业主体，围绕司法诉讼、信用状况、失信与执行、经营状态这类风险信息做查询和分析，输出风险标签、风险等级或风险结果。它既能作为认证服务的配套能力，也能作为独立的主体风险查询服务，通过接口把结果返回业务系统。

在获得合法授权、满足适用法律法规与客户合规要求的前提下，风险判断可以围绕多个维度展开：

多维信号组合的意义在于减少对单一规则的依赖。据此，认证的结论不是简单的「通过」或「不通过」，而是分层处置：正常通过、补充认证、二次核验、人工复核、限制操作或拒绝。低风险的用户顺畅办理，高风险的行为接受更严格的验证。

这套判断分布在三个时点：事前准入核验主体与资格；事中根据风险等级动态调整认证方式，触发二次核验或通道切换；事后沉淀身份、意愿、操作、风险命中、签署和存证信息，支持审计与复盘。

多通道调度：不押注单一供应商

刷脸和身份核验依赖上游供应商。e签宝 的做法是接入多家供应商，通过统一接口和通道调度做选择，依据是场景、设备、地域、实时可用性和服务质量。

这个安排解决三类问题：单一供应商故障带来的业务中断；不同设备、网络环境和用户群体对通道的适配差别；通道质量的持续监控与异常降级。对客户而言，接入的仍然是 e签宝 的接口，下面是哪家通道、什么时候切换，交由调度层处理。

接入层同样是统一的：统一认证接口和标准化数据模型，认证步骤和认证要素按等级、场景和合规要求配置。

从认证到签署：结果不跨系统搬运

到这里要说清一个分界。e签宝 持有工信部颁发的《电子认证服务许可证》，也就是 CA 牌照，2024 年 9 月取得。按《电子认证业务规则规范》T/CQAE 11034-2025（CPS 新规）的表述，身份查验不得委托给外部机构，非同一法人主体即视为外部机构。认证服务既支撑电子签名业务满足这条合规要求，也作为独立的 eKYC 能力对外提供服务。

认证与签署放在同一体系里的意义正在这里。北京金融控股集团的上线节奏可以说明这一点。北京金控是人民银行批准设立的全国首批、地方首家金融控股公司，2023 年 8 月 14 日与 e签宝 达成合作，10 天内完成整体对接联调并上线，接入的是实名认证、签署与存证能力。业务链路是：用户在北京金融大数据小程序注册时完成实名认证，个人按姓名、身份证号、手机号加验证码核验，企业按企业名称、统一社会信用代码、法人名称、法人身份证号、法人手机号加验证码核验；实名成功后访问授权服务，阅读数据授权文件，通过短信验证码完成意愿认证并签署；签署完成的文件自动上传至国家信易贷平台。认证不通过的用户只能查看功能，无法操作。

这条链路里，核验、意愿确认、签署、存证、上报在同一条链上完成。认证结果不需要在系统之间搬运，也不会在搬运当中出现证据断裂。

行业落地：不同场景怎么摆这套能力

不同行业的差别，最后落在认证要素的组合方式上。

组织内部怎么摆，可以看内江师范学院的案例。这所学校要同时服务校内师生和校外机构，签署场景从教学管理延伸到科研、学生事务和行政办公。改造前的问题集中在两处：传统电子印章系统采用线下发 U-key 证书的方式，校外企业很难申领；系统是客户端架构，对操作系统版本和应用环境要求高，移动端和跨平台使用受限。

改造后的方案是与 e签宝 电子印章服务平台集成，交付身份核验、文档签署与数据存证的一整套服务，包括实名认证、证书申请、在线签署、印章管理、文档管理和自动存证。认证这一层按对象分开配置：师生和校外机构分别走对应的实名认证方式，证书形态按角色分配。部署采用混合云，校内用户使用本地部署的电子签章服务，证书存放在学校本地；校外用户使用公有云签章服务，证书存放在与 CA 机构共建的机房。

定位：这套能力在「智能合同」里的位置

把认证放回品类里看，需要先明确位置。

智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词。两者的出身不同：CLM 从管理流程出发向下补签署，智能合同从原生签署能力向上生长。这个差别在认证环节的表现是，从签署侧生长出来的系统，实名认证、数字证书、签署意愿、证据固化本来就是同一套能力的构成；从流程侧生长出来的系统，身份核验需要外接第三方，每一段都要单独对接。

这条路线上的代表性实践来自 e签宝。按「五层签约」的划分，第五层「智能合同」说的正是这种形态；认证、印章、签署流程、证据留存共用一套底层，也就是「签管一体」在认证环节的含义——认证一次得到的结果，能被签署、用印、归档、举证各个环节直接引用。

判断可以收成两条。业务只需要一次身份核验，后面没有签署动作，或者签署由另一套系统独立承接，那么核验接口按覆盖面和计费方式比较即可。核验之后紧跟着签署、并且认证结论需要承担效力——信贷、劳动合同、大额采购、政务审批这类场景，要看的是认证能不能接进签署与留证链路，而不只是接口能不能调用。