近被「诺亚财富34亿踩雷」的新闻刷屏了，报案、否认、甩锅，一波三折，如今演绎成了罗生门。承兴造假，京东否认，诺亚报案。如何通过技术方案的设计在风险发生时为业务提供强有力的举证支持是我最近一直在思考的事情，其中电子合同的有效性是我们一直在讨论的重点问题。

随着互联网金融/金融科技的发展，合同通过电子化签署逐渐被大家接受。但是受限制于国内《电子签名法》采用了技术折中的立法模式，法律法规仅从功能性和效果上的角度上提出了要求。

如何界定电子签名、数据电文及电子合同的有效性涉及较为复杂的技术知识，司法实践中对于技术路径审查的相关经验并不多，存在着对“电子签名制作数据”、“电子签名”、“数字签名”、“用户密码”等专业概念的认知偏差，对如何签出一份合法有效的电子合同则比较模糊。

针对于此，我也与很多的法务同学、电子合同服务商进行过交流，整理了下我在交流中的感受，分享出来抛砖引玉，欢迎砸我。

一、电子合同是被法律认可的合同形式

首先我们得确认电子合同是合法有效的，这是这篇文章的基础。

对于这一点，在《合同法》以及《电子签名法》中都有明确规定：

《中华人民共和国合同法》

第十条：当事人订立合同，有书面形式、口头形式和其他形式；

第十一条：书面形式是指合同书、信件和数据电文（包括电报、电传、传真、电子数据交换和电子邮件）等可以有形地表现所载内容的形式。

简而言之：电子合同属于合同的一种。

《中华人民共和国电子签名法》

第十三条 电子签名同时符合下列条件的，视为可靠的电子签名：

1. 电子签名制作数据用于电子签名时，属于电子签名人专有；
2. 签署时电子签名制作数据仅由电子签名人控制；
3. 签署后对电子签名的任何改动能够被发现；
4. 签署后对数据电文内容和形式的任何改动能够被发现。当事人也可以选择使用符合其约定的可靠的条件的电子签名；

第十四条 可靠的电子签名与手写签名或者盖章具有同等的法律效力

简而言之：《电子签名法》规定了可靠的电子签名的有效性以及可靠的电子签名的要素：专有、专控、不可篡改。

（当然，《电子签名法》中也规定了一些不适用电子签名的情况：涉及婚姻、收养、继承等人身关系的；涉及停止供水、供电、供气等公用事业服务的；法律、行政法规规定的不适用电子文书的其他情形。这些不在我们本次讨论范围之内。）

合同的成立在传统合同书中一般通过签字或者盖章的方式来体现，在电子合同中签字盖章的行为被可靠的电子签名所代替《电子签名法》第十四条^[1]。

二、先从技术层面来说

本质上电子合同的成立生效没有跳出传统合同的要件要求，这些要求我们不在此做讨论。

既然是「可靠的电子签名」与手写签名或者盖章具有同等的法律效力，那么我们只需要能在业务中能够证明符合相关要素即可。市面上的一些第三方电子合同服务商都有符合相关规定（至少是能经得起推敲）的产品方案（毕竟人家赚的就是这份钱）。

但第三方服务商的标准产品开发需要最大程度的降低其自身的风险，一般情况下会将签署合同的整个过程至于其可控范围内，其产品流程并不一定适合我们的业务系统交互需求甚至可能与业务系统相冲突。

因此部分过程需要业务系统自己完成，业务系统在风险发生时需要承担一定举证责任（不得不说，某些服务商的方案对于业务系统侵入性太大，很难接受啊）。

我们先对电子合同签署的生命流程进行拆解：

实名认证步骤，一般分为个人实名和企业实名。（不讨论线下核验的方式）

个人实名的方案很多：生物识别、银行卡验证、手机号实名认证……一般目前最保险的是扫脸认证活体检测，最好将活体的视频保存下来，以便举证。

企业实名，目前用的最多的营业执照、银行账户小额打款、法人身份证来验证。

这里顺便我说一句，我只看到一家供应商可以提供法人姓名+身份证号的认证信息，不知道市面上还有没有其他的服务商可以有此类服务提供（不是根据法人身份证对信息做二要素验证，而是根据工商注册信息对提供的法人姓名和身份证号做验证）。

意愿认证上，方式有很多。目前大部分第三方电子合同服务商都采用云托管数字证书模式，在意愿认证上针对个人一般采用短信验证码、人脸识别等来作为签署人意愿表达的行为；针对企业一般通过向企业授权人发送短信验证码、识别授权人人脸等方式或者采用 Ukey 来作为意愿表达。

这里多说一句：如果你采用 ukey 来做鉴权，需要考虑一点就是签署时使用的数字证书是否为 ukey 里存储的数字证书。如果不是（极大概率不是）一定要注意证据链完整的问题，因为本质上还是云托管数字证书来完成签署。

至于合同生成和司法举证，去找第三方服务商吧，如果这些事情都要自己做，那你就是自己在做一个电子合同平台了。

三、举证能力的一些思考

其实技术上没有难点，主要在举证问题上有一些思考：

1. 如何证明已经进行完善的实名信息

一般来说，我们做实名都是调用第三方数据接口，我们需要尽量保证调用记录的完整性及可查性。在出现电子合同有效性问题时可以提供我方已经进行应尽的实名义务，并在力所能及的范围内做到了对用户的实名认证。

针对企业实名，要至少核验包括包括企业名称、统一社会信用代码，最好对法人姓名及身份证号进行核验，同时应对经办人进行个人实名核验，以及企业核心隐私数据的核验，例如对公银行打款、开具指定金额发票等核验方式；

也可通过电子认证服务机构颁发的数字证书进行实名核验（这一点某 CA 的一个服务可以实现通过全国大部分（小）银行发放的 ukey进行实名认证，不过大行很少）。

这里需要注意的一点是我们在选择第三方数据服务商的时候一定要主要选择政府权威部门的数据库或者取得政府权威部门授权或认可的电子数据库（比如国政通……国政通麻烦广告费结下）

2. 在意愿认证上尽可能多的收集签署时的信息。

在合法合规的前提下，除通过短信验证码、人脸识别或 ukey 认证等方式完成用户意愿认证外，管理系统还应该尽可能的收集用户在签署时的IP 地址、操作设备 MAC 地址、操作系统信息等可以佐证是用户自身操作的信息。

3. 自动签署（或者说代签署）是否有效。

目前大部分系统对接第三方电子合同服务商的时候为了不让电子合同系统侵入业务系统都采用了各家服务商提供的「自动签署」方案（这一点我要吐槽下拉，各家差不多都有这样的接口，但是在使用上并没有很好的给用户说明。）

首先，我们要说的是《电子签名法》第十三条里提到的「签署时电子签名制作数据仅由电子签名人控制」这一项规定是对电子签名过程中电子签名制作数据归谁控制的要求。这里所规定的控制是指一种实质上的控制，即基于电子签名人的自由意志而对电子签名制作数据的控制。

在电子签名人实施电子签名行为的过程中，无论是电子签名人自己实施签名行为，还是委托他人代为实施签名行为，只要电子签名人拥有实质上的控制权，则其所实施的签名行为，满足本法此项规定的要求。（这段话不是我说的，是全国人大关于《电子签名法》的释法^[2]）

在中国互联网金融协会《互联网金融个体网络借贷电子合同安全规范（征求意见稿）》第 8 司法举证要求（d）中也提到「电子签名人委托他人代为实施签名行为时，从业机构或第三方电子合同订立系统服务商提供电子签名制作数据由电子签名人控制的证据，包括调用电子签名制作数据的时间和方式、电子签名人位置、IP地址、授权及认证方式、授权及认证记录等；」

所以，自动签署的方案大家还是可以放心用，只需要你能通过其他方式来证明电子签名人拥有实质上的控制权即可。

4. 关于举证责任

关于电子签名，有一个举证的坑。

《电子签名法》第二十八条：电子签名人或者电子签名依赖方因依据电子认证服务提供者提供的电子签名认证服务从事民事活动遭受损失，电子认证服务提供者不能证明自己无过错的，承担赔偿责任。

也就是说，关于电子签名，举证责任倒置。即对方提出的侵权事实，电子认证提供者如果予以否认，则应负举证责任，证明自己没有过错。

在司法实践上，《袁斌与合肥梦川玖贸易有限公司等小额借款合同纠纷二审案件》【案号：北京市第三中级人民法院（2018）京03民终4903号】^[3]中，法院也是这样认定的。

当然，只要电子认证服务提供者能够证明自己对于电子签名人或者电子签名依赖方所遭受的损失没有过错，就不承担责任。而对于电子认证服务提供者来讲，只要能够证明其所提供的服务完全是严格按照本法和符合国家规定并向国务院信息产业主管部门备案的电子认证业务规则实施的，则应能够证明没有过错。（《电子签名法释义 法律责任》^[4]）

5. 电子签名无效的法律后果

电子签名无效仅仅表示该电子签名并非当事人真实意愿的表达，并不必然影响当事人之间的部分关系（比如债权债务关系、劳动关系）的成立。

如果能够从其他方面来证明当事人之间存在相关关系，法院大概率上会要求侵权方承担民事责任。但一些合同上具体规定可能无法予以认定。

比如上边提到的《袁斌与合肥梦川玖贸易有限公司等小额借款合同纠纷二审案件》中，法院虽然认定电子签名无效，但是从实名认证信息、操作记录等方面认定借款合同有效。

6. 一定要用数字签名么？

其实这一点上，《最高人民法院关于互联网法院审理案件若干问题的规定》第十一条^[5]已经明确指出：「当事人提交的电子数据，通过电子签名、可信时间戳、哈希值校验、区块链等证据收集、固定和防篡改的技术手段或者通过电子取证存证平台认证，能够证明其真实性的，互联网法院应当确认。」

最后多说一句，如果有钱花一点钱找服务商做个证据保全系统或者直接和司法鉴定中心、公证处之类的合作，毕竟法官不是开发小哥，你跟他讲技术远不如公证处或者司法鉴定中心的一个章子管用。

四、我为了写这篇东西，翻了多少材料

1. 《电子签名法》：这个就不用说了，自己百度就好了；
2. 详细的研究了各家服务商的材料（至少 Top3 的PPT 和接口文档我都比对了好几遍，其他一些的 PPT 我也都又翻了一遍）
3. 《GB∕T36298-2018 电子合同订立流程规范》：商务部18 年新搞的推荐标准，至少目前各家服务商的 PPT 中我还没看到把这个拿出来写。有想要 PDF 的可以找我，不过也是图片扫描版的。
4. 《互联网金融 个体网络借贷电子合同安全规范（征求意见稿）》：这个不说了，都是当年的存货。（我不说当年我收集了中互金以及各地区的P2P 的规定、措施等等材料，毕竟当年也算家大业大。）
5. 《JR/T 0118-2015 金融电子认证规范》：这个简单学习了下。
6. 法律实践，说白了就是判例。一个在做法务的小伙伴跟我说，你问我不如去看判例……这里安利下「无讼」这个平台比文书网好用多了。

#References#

[1]《电子签名法》第十四条:可靠的电子签名与手写签名或者盖章具有同等的法律效力。

[2]全国人大关于《电子签名法》的释法:http://t.cn/AiYEl4bm

[3]《袁斌与合肥梦川玖贸易有限公司等小额借款合同纠纷二审案件》【案号：北京市第三中级人民法院（2018）京03民终4903号】:http://t.cn/AiYEOrYd

[4]《电子签名法释义 法律责任》:http://t.cn/AiYElv5w

[5]《最高人民法院关于互联网法院审理案件若干问题的规定》第十一条:http://www.court.gov.cn/zixun-xiangqing-116981.html

#相关阅读#

互金业务中经常提到的电子合同，到底是个啥？

#专栏作家#

张小璋，公众号：张小璋的碎碎念（ID：SylvainZhang），人人都是产品经理专栏作家。野蛮生长的产品经理，专注于互联网金融领域。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

TTP协议简介

尽量使用谷歌/火狐/360极速浏览器

在Web应用中，服务器把网页传给浏览器，实际上就是把HTML代码发给浏览器，让浏览器显示出来，而浏览器和服务器之间的传输协议就是HTTP

（1） HTML是一种定义网页的文本

（2） HTTP是在网络上传输HTML的协议，用于通信

Chrome浏览器提供了一套调试工具，非常适合web调试

在Chrome中下面的位置中或者ctrl+shift+i快捷键：

打开后的界面

我们打开网络调试助手

进入界面

接下来我们用Chrome访问我们本地服务

先启动服务，此时我们就模拟了服务器

然后在浏览器中访问服务器，输入以下内容，点击回车

浏览器会进入请求状态

我们在模拟服务器中也会提取到信息

这些内容就是HTTP协议中的一部分内容

GET / HTTP/1.1

Host: 127.0.0.1:8080

Connection: keep-alive

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate, br

Accept-Language: zh-CN,zh;q=0.9

其中GET后面是/了，但是如果我们在浏览器访问中加访问内容的话它就会变化了，比如下面就不会是/了，这个GET就向服务器"要东西"。这就是协议中的意义，是有规定目的的。

Host: 127.0.0.1:8080 这个内容就很明显了，表示访问到地址。

Connection: keep-alive 表示长连接，先记下。

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 表示能接收的格式。

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36 表示浏览器的访问版本。这个可以练习下，用市面上常见的浏览器访问下，看下浏览器访问版本。

那么我们现在知道浏览器向服务器访问的格式，那么服务器返回给浏览器我们该怎么看呢？

比如我们访问，看看返回什么？

进入浏览器，先改下位置，这样比较舒服

调试工具就到下面了

访问百度，我们看下面的地方

这里就是给浏览器的内容

可以点击查看内容

我们来看我们访问的百度地址后，返回的信息，这里面很多内容需要我们慢慢掌握

下面这个就是我们请求的内容

这个就是响应的概要内容，就可以针对性的查询协议内容

而主要内容是在这里：

我们利用调试助手模拟服务器向浏览器发送信息，就可以查看到信息