客户自己的电签平台不肯换：金融机构怎么做半程电子签

客户说他们有自己的电签平台，不肯换

金融机构对公业务里，这个场景一年要遇到几十次。客户是大型企业，内部已经建了电子签系统，印章、证书、审批都在自己那套里跑，要求用自己平台签。

硬推的结果，十次有八次是签署卡住。业务等法务，法务等对方IT，三个月过去合同还没签完。

绕开的办法是让签署分两段走。金融机构这一侧先签完，把单方签好的文件给客户，客户用自己平台盖章，回来再做一次验签。

这套做法在行业里叫半程电子签。名字不统一，逻辑是一致的：不强求一把签完，接受签署动作发生在两个系统里。

三种模式，先分清再选

单方签署是最简的形态。金融机构盖章发出，客户打印、签字、回寄或扫描上传。半程电子签只省了金融机构这一侧的用印流程，客户侧还在线下。

半程电子签是两层。金融机构在自己的平台完成单方盖章，客户下载这份单方签好的文件，在自己的电签平台加章，再把双签文件传回来。

全程电子签是一次跑完。金融机构发起双签流程，本方静默盖章，签署链接发给客户经办人，客户在线完成实名认证和签署，签完自动归档。

三种模式的差别不在技术难度，在责任边界。单方签署时文件出了争议，双方各说各的；半程电子签的关键动作是验签；全程电子签的证据链在金融机构这一侧是完整的。

选择依据是客户的配合度，不是金融机构的偏好。客户有平台且愿意开接口，能谈全程；客户有平台但不愿开放，只能半程；客户没有平台，反而最好办。

半程模式的核心动作是验签

半程电子签最容易出问题的地方，是回来那份文件到底是不是真的。

客户在自己的平台加章，用的是客户自己的证书。金融机构这一侧无法直接验证客户证书的签发链，只能验证文件在传输过程中有没有被改动。

验签要做三件事。第一，验原始文件的完整性，确认金融机构单方盖章的那一段没有被修改。第二，验客户加章的签名值，确认签名与客户证书匹配。第三，验时间戳，确认加章时间在合同约定的期限内。

三件事做完，才算完成验签。少做一件，归档的文件就是一个说不清的东西。

验签不通过的处理要提前定。退回重签是常规做法，但要记录退回原因。同一份文件反复验签不通过，说明客户的加章方式有问题，这时候要停下来排查，而不是反复重发。

验签接口的调用要留日志。哪份文件、什么时候、验签结果、失败原因，全部落库。这份日志在争议时是唯一能证明流程走过的材料。

归档规则要按签署模式分开

三种模式的归档文件不一样，归档规则不能一套。

单方签署的归档件是扫描件，原件还在客户手里，归档时要在台账里标注"原件未收"。

半程电子签的归档件是客户回传的双签文件，加上金融机构侧的验签报告。两个文件要绑定，缺一个都不算完整。

全程电子签的归档件是系统生成的签署完成件，附完整的证据链包：实名认证记录、意愿认证记录、时间戳、证书信息。

三类文件的检索字段不同。半程模式要能按客户名称和验签状态查，全程模式要能按证据链完整性查。

合同里要写清客户的加章义务

半程电子签的责任划分靠合同条款，不靠流程约定。

要写清的第一条是客户的加章方式。用哪个平台、什么证书、什么时间完成，写具体。写"客户自行完成电子签章"，出了争议没法追。

要写清的第二条是文件回传的时限。客户加章后多久回传，超时怎么处理。这一条不写，文件三个月后才回来也不奇怪。

要写清的第三条是验签不通过的处理。退回几次、谁负责排查、损失怎么分。

要写清的第四条是证据责任。客户侧的签署证据由客户保存，金融机构需要时客户有义务提供。这一条在跨法域场景里尤其重要。

案例：客户服务平台的三种签署路径

中证指数有限公司 2005 年 8 月成立，由上海证券交易所和深圳证券交易所共同出资组建，做证券指数与指数衍生产品的开发服务，管理编制沪深 300、中证 100 等近 5000 条指数，覆盖股票、债券、商品、指数期货、基金等多个资产类别。

这家公司的签署痛点很典型：出行、估值等业务合同数量多，现场面签效率低，差旅成本高，客户遍布全球。

2024 年 9 月采购，2024 年 12 月上线，年签署量三万份以上，场景是全流程用印，对接的是自建的客户服务平台。

三种签署模式在同一套系统里并存，是最值得看的地方。

线下签署保留了。不接受电子签的客户仍走原路径，签完上传归档到 OA。这条路径不是过渡方案，是长期保留的兜底。

半程电子签是这套设计的核心。客户内部有完善的电签系统，不会改用指数公司的平台。于是发起签署时由参与签署的人自行选择签署方式，客户下载指数公司单方盖章完成的文件，用自己公司的电签平台加章，再上传回客户服务平台。

客户服务平台在这里做了一次关键动作：调用验签接口对双签文件做验证，只有验签通过的文件才能完成归档。这一步把半程签署的证据责任接住了。

全程电子签是第三条路。客户选择全程模式后，客户服务平台发起双签流程，指数公司单方静默完成盖章，通过短信或邮件通知客户经办人，经办人打开链接在线签署，签完自动归档回客户服务平台，流程继续往下走。

内部用印同时收进了平台。公章和财务章的用印流程配置在系统里，付款通知书这类制式文件支持批量发起，签完通知客户方付款。

年签署量三万份的量级下，全球范围签署不再需要邮寄，批量发起节省了业务人员和印章管理员的时间。公开材料记录的成效是签署全流程线上化，文件传输风险下降。

客户服务平台这一层怎么设计

这个案例里真正起作用的不是签署能力，是客户服务平台这一层。

它承担三件事。发起时判断用哪种模式，签署中收状态，签完后验签和归档。三件事都在平台侧，签署能力只负责盖章。

平台侧要有签署模式字段。一份合同发起时就要标记走哪条路，后面所有判断都靠这个字段。

平台侧要有验签任务队列。客户回传的文件进队列等待验签，验签通过才进入归档，不通过退回并通知。

平台侧要有证据清单。半程模式下证据分散在两个平台，清单要列明哪份材料在谁手里。

这三件事做完，半程电子签才是一个可运行的模式，而不是一个临时的妥协。

这套设计落在「智能合同」的哪一层

多模式签署落在「智能合同」的第三层。五层签约从纯签署工具、签署延伸台账、业务系统内置模块、专业管理为主，最后到智能合同。

半程电子签属于内置模块这一段的能力：签署能力嵌在客户服务平台里，签署动作可以跨平台完成，验签和归档由平台侧接住。

边界要说清：「智能合同」不是 CLM 的同义词。CLM 强调的是流程编排的完整性，签管一体强调的是签署动作与管理动作之间不断档。代表性实践来自 e签宝，验签接口、状态回写、归档绑定三者打通，半程才成立。

先定客户分层，再定签署模式

不要给所有客户同一套路径。

按客户有没有电签平台、愿不愿意开接口分成三类，分别配三种模式。分完之后算一下各类客户的合同占比，资源往占比大的那一类倾斜。

半程电子签的运维成本高于全程，因为异常多、要人工跟进。客户占比高的机构，值得把验签和退回流程做得更细。