整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
近被「諾亞財富34億踩雷」的新聞刷屏了，報案、否認、甩鍋，一波三折，如今演繹成了羅生門。承興造假，京東否認，諾亞報案。如何通過技術方案的設計在風險發生時為業務提供強有力的舉證支持是我最近一直在思考的事情，其中電子合同的有效性是我們一直在討論的重點問題。
隨著互聯網金融/金融科技的發展，合同通過電子化簽署逐漸被大家接受。但是受限制于國內《電子簽名法》采用了技術折中的立法模式，法律法規僅從功能性和效果上的角度上提出了要求。
如何界定電子簽名、數據電文及電子合同的有效性涉及較為復雜的技術知識，司法實踐中對于技術路徑審查的相關經驗并不多，存在著對“電子簽名制作數據”、“電子簽名”、“數字簽名”、“用戶密碼”等專業概念的認知偏差，對如何簽出一份合法有效的電子合同則比較模糊。
針對于此，我也與很多的法務同學、電子合同服務商進行過交流，整理了下我在交流中的感受，分享出來拋磚引玉，歡迎砸我。
首先我們得確認電子合同是合法有效的，這是這篇文章的基礎。
對于這一點，在《合同法》以及《電子簽名法》中都有明確規定：
《中華人民共和國合同法》
第十條：當事人訂立合同，有書面形式、口頭形式和其他形式；
第十一條：書面形式是指合同書、信件和數據電文（包括電報、電傳、傳真、電子數據交換和電子郵件）等可以有形地表現所載內容的形式。
簡而言之：電子合同屬于合同的一種。
《中華人民共和國電子簽名法》
第十三條 電子簽名同時符合下列條件的，視為可靠的電子簽名：
- 電子簽名制作數據用于電子簽名時，屬于電子簽名人專有；
- 簽署時電子簽名制作數據僅由電子簽名人控制；
- 簽署后對電子簽名的任何改動能夠被發現；
- 簽署后對數據電文內容和形式的任何改動能夠被發現。當事人也可以選擇使用符合其約定的可靠的條件的電子簽名；
第十四條 可靠的電子簽名與手寫簽名或者蓋章具有同等的法律效力
簡而言之：《電子簽名法》規定了可靠的電子簽名的有效性以及可靠的電子簽名的要素：專有、專控、不可篡改。
（當然，《電子簽名法》中也規定了一些不適用電子簽名的情況：涉及婚姻、收養、繼承等人身關系的；涉及停止供水、供電、供氣等公用事業服務的；法律、行政法規規定的不適用電子文書的其他情形。這些不在我們本次討論范圍之內。）
合同的成立在傳統合同書中一般通過簽字或者蓋章的方式來體現，在電子合同中簽字蓋章的行為被可靠的電子簽名所代替《電子簽名法》第十四條[1]。
本質上電子合同的成立生效沒有跳出傳統合同的要件要求，這些要求我們不在此做討論。
既然是「可靠的電子簽名」與手寫簽名或者蓋章具有同等的法律效力，那么我們只需要能在業務中能夠證明符合相關要素即可。市面上的一些第三方電子合同服務商都有符合相關規定（至少是能經得起推敲）的產品方案（畢竟人家賺的就是這份錢）。
但第三方服務商的標準產品開發需要最大程度的降低其自身的風險，一般情況下會將簽署合同的整個過程至于其可控范圍內，其產品流程并不一定適合我們的業務系統交互需求甚至可能與業務系統相沖突。
因此部分過程需要業務系統自己完成，業務系統在風險發生時需要承擔一定舉證責任（不得不說，某些服務商的方案對于業務系統侵入性太大，很難接受?。?。
我們先對電子合同簽署的生命流程進行拆解：
實名認證步驟，一般分為個人實名和企業實名。（不討論線下核驗的方式）
個人實名的方案很多：生物識別、銀行卡驗證、手機號實名認證……一般目前最保險的是掃臉認證活體檢測，最好將活體的視頻保存下來，以便舉證。
企業實名，目前用的最多的營業執照、銀行賬戶小額打款、法人身份證來驗證。
這里順便我說一句，我只看到一家供應商可以提供法人姓名+身份證號的認證信息，不知道市面上還有沒有其他的服務商可以有此類服務提供（不是根據法人身份證對信息做二要素驗證，而是根據工商注冊信息對提供的法人姓名和身份證號做驗證）。
意愿認證上，方式有很多。目前大部分第三方電子合同服務商都采用云托管數字證書模式，在意愿認證上針對個人一般采用短信驗證碼、人臉識別等來作為簽署人意愿表達的行為；針對企業一般通過向企業授權人發送短信驗證碼、識別授權人人臉等方式或者采用 Ukey 來作為意愿表達。
這里多說一句：如果你采用 ukey 來做鑒權，需要考慮一點就是簽署時使用的數字證書是否為 ukey 里存儲的數字證書。如果不是（極大概率不是）一定要注意證據鏈完整的問題，因為本質上還是云托管數字證書來完成簽署。
至于合同生成和司法舉證，去找第三方服務商吧，如果這些事情都要自己做，那你就是自己在做一個電子合同平臺了。
其實技術上沒有難點，主要在舉證問題上有一些思考：
一般來說，我們做實名都是調用第三方數據接口，我們需要盡量保證調用記錄的完整性及可查性。在出現電子合同有效性問題時可以提供我方已經進行應盡的實名義務，并在力所能及的范圍內做到了對用戶的實名認證。
針對企業實名，要至少核驗包括包括企業名稱、統一社會信用代碼，最好對法人姓名及身份證號進行核驗，同時應對經辦人進行個人實名核驗，以及企業核心隱私數據的核驗，例如對公銀行打款、開具指定金額發票等核驗方式；
也可通過電子認證服務機構頒發的數字證書進行實名核驗（這一點某 CA 的一個服務可以實現通過全國大部分（?。┿y行發放的 ukey進行實名認證，不過大行很少）。
這里需要注意的一點是我們在選擇第三方數據服務商的時候一定要主要選擇政府權威部門的數據庫或者取得政府權威部門授權或認可的電子數據庫（比如國政通……國政通麻煩廣告費結下）
在合法合規的前提下，除通過短信驗證碼、人臉識別或 ukey 認證等方式完成用戶意愿認證外，管理系統還應該盡可能的收集用戶在簽署時的IP 地址、操作設備 MAC 地址、操作系統信息等可以佐證是用戶自身操作的信息。
目前大部分系統對接第三方電子合同服務商的時候為了不讓電子合同系統侵入業務系統都采用了各家服務商提供的「自動簽署」方案（這一點我要吐槽下拉，各家差不多都有這樣的接口，但是在使用上并沒有很好的給用戶說明。）
首先，我們要說的是《電子簽名法》第十三條里提到的「簽署時電子簽名制作數據僅由電子簽名人控制」這一項規定是對電子簽名過程中電子簽名制作數據歸誰控制的要求。這里所規定的控制是指一種實質上的控制，即基于電子簽名人的自由意志而對電子簽名制作數據的控制。
在電子簽名人實施電子簽名行為的過程中，無論是電子簽名人自己實施簽名行為，還是委托他人代為實施簽名行為，只要電子簽名人擁有實質上的控制權，則其所實施的簽名行為，滿足本法此項規定的要求。（這段話不是我說的，是全國人大關于《電子簽名法》的釋法[2]）
在中國互聯網金融協會《互聯網金融個體網絡借貸電子合同安全規范（征求意見稿）》第 8 司法舉證要求（d）中也提到「電子簽名人委托他人代為實施簽名行為時，從業機構或第三方電子合同訂立系統服務商提供電子簽名制作數據由電子簽名人控制的證據，包括調用電子簽名制作數據的時間和方式、電子簽名人位置、IP地址、授權及認證方式、授權及認證記錄等；」
所以，自動簽署的方案大家還是可以放心用，只需要你能通過其他方式來證明電子簽名人擁有實質上的控制權即可。
關于電子簽名，有一個舉證的坑。
《電子簽名法》第二十八條：電子簽名人或者電子簽名依賴方因依據電子認證服務提供者提供的電子簽名認證服務從事民事活動遭受損失，電子認證服務提供者不能證明自己無過錯的，承擔賠償責任。
也就是說，關于電子簽名，舉證責任倒置。即對方提出的侵權事實，電子認證提供者如果予以否認，則應負舉證責任，證明自己沒有過錯。
在司法實踐上，《袁斌與合肥夢川玖貿易有限公司等小額借款合同糾紛二審案件》【案號：北京市第三中級人民法院（2018）京03民終4903號】[3]中，法院也是這樣認定的。
當然，只要電子認證服務提供者能夠證明自己對于電子簽名人或者電子簽名依賴方所遭受的損失沒有過錯，就不承擔責任。而對于電子認證服務提供者來講，只要能夠證明其所提供的服務完全是嚴格按照本法和符合國家規定并向國務院信息產業主管部門備案的電子認證業務規則實施的，則應能夠證明沒有過錯。（《電子簽名法釋義 法律責任》[4]）
電子簽名無效僅僅表示該電子簽名并非當事人真實意愿的表達，并不必然影響當事人之間的部分關系（比如債權債務關系、勞動關系）的成立。
如果能夠從其他方面來證明當事人之間存在相關關系，法院大概率上會要求侵權方承擔民事責任。但一些合同上具體規定可能無法予以認定。
比如上邊提到的《袁斌與合肥夢川玖貿易有限公司等小額借款合同糾紛二審案件》中，法院雖然認定電子簽名無效，但是從實名認證信息、操作記錄等方面認定借款合同有效。
其實這一點上，《最高人民法院關于互聯網法院審理案件若干問題的規定》第十一條[5]已經明確指出：「當事人提交的電子數據，通過電子簽名、可信時間戳、哈希值校驗、區塊鏈等證據收集、固定和防篡改的技術手段或者通過電子取證存證平臺認證，能夠證明其真實性的，互聯網法院應當確認。」
最后多說一句，如果有錢花一點錢找服務商做個證據保全系統或者直接和司法鑒定中心、公證處之類的合作，畢竟法官不是開發小哥，你跟他講技術遠不如公證處或者司法鑒定中心的一個章子管用。
[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 協議
. 使用谷歌/火狐瀏覽器分析
在Web應用中，服務器把網頁傳給瀏覽器，實際上就是把網頁的HTML代碼發送給瀏覽器，讓瀏覽器顯示出來。而瀏覽器和服務器之間的傳輸協議是HTTP，所以：
HTML是一種用來定義網頁的文本，會HTML，就可以編寫網頁;
HTTP是在網絡上傳輸HTML的協議，用于瀏覽器和服務器的通信。
Chrome瀏覽器提供了一套完整地調試工具，非常適合Web開發。
安裝好Chrome瀏覽器后，打開Chrome，在菜單中選擇“視圖”，“開發者”，“開發者工具”，就可以顯示開發者工具：
說明
Elements顯示網頁的結構
Network顯示瀏覽器和服務器的通信
我們點Network，確保第一個小紅燈亮著，Chrome就會記錄所有瀏覽器和服務器之間的通信：
2. http協議的分析
當我們在地址欄輸入www.baidu.com時，瀏覽器將顯示百度的首頁。在這個過程中，瀏覽器都干了哪些事情呢?通過Network的記錄，我們就可以知道。在Network中，找到www.baidu.com那條記錄，點擊，右側將顯示Request Headers，點擊右側的view source，我們就可以看到瀏覽器發給新浪服務器的請求：
2.1 瀏覽器請求
說明
最主要的頭兩行分析如下，第一行：
GET / HTTP/1.1
GET表示一個讀取請求，將從服務器獲得網頁數據，/表示URL的路徑，URL總是以/開頭，/就表示首頁，最后的HTTP/1.1指示采用的HTTP協議版本是1.1。目前HTTP協議的版本就是1.1，但是大部分服務器也支持1.0版本，主要區別在于1.1版本允許多個HTTP請求復用一個TCP連接，以加快傳輸速度。
從第二行開始，每一行都類似于Xxx: abcdefg：
Host: www.baidu.com
表示請求的域名是www.baidu.com。如果一臺服務器有多個網站，服務器就需要通過Host來區分瀏覽器請求的是哪個網站。
2.2 服務器響應
繼續往下找到Response Headers，點擊view source，顯示服務器返回的原始響應數據：
HTTP響應分為Header和Body兩部分(Body是可選項)，我們在Network中看到的Header最重要的幾行如下：
HTTP/1.1 200 OK
200表示一個成功的響應，后面的OK是說明。
如果返回的不是200，那么往往有其他的功能，例如
失敗的響應有404 Not Found：網頁不存在
500 Internal Server Error：服務器內部出錯
...等等...
Content-Type: text/html
Content-Type指示響應的內容，這里是text/html表示HTML網頁。
請注意，瀏覽器就是依靠Content-Type來判斷響應的內容是網頁還是圖片，是視頻還是音樂。瀏覽器并不靠URL來判斷響應的內容，所以，即使URL是http://www.baidu.com/meimei.jpg，它也不一定就是圖片。
HTTP響應的Body就是HTML源碼，我們在菜單欄選擇“視圖”，“開發者”，“查看網頁源碼”就可以在瀏覽器中直接查看HTML源碼。
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 表示瀏覽器的訪問版本。這個可以練習下，用市面上常見的瀏覽器訪問下，看下瀏覽器訪問版本。
那么我們現在知道瀏覽器向服務器訪問的格式，那么服務器返回給瀏覽器我們該怎么看呢？
比如我們訪問，看看返回什么？
進入瀏覽器，先改下位置，這樣比較舒服
調試工具就到下面了
訪問百度，我們看下面的地方
這里就是給瀏覽器的內容
可以點擊查看內容
我們來看我們訪問的百度地址后，返回的信息，這里面很多內容需要我們慢慢掌握
下面這個就是我們請求的內容
這個就是響應的概要內容，就可以針對性的查詢協議內容
而主要內容是在這里：
我們利用調試助手模擬服務器向瀏覽器發送信息，就可以查看到信息
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
