基于深證通FDEP平臺的電子指令管理系統設計

楊葶

（上海寶信軟件股份有限公司 上海市 201203）

1 引言

《信托公司集合資金信托計劃管理辦法》要求信托計劃資金實行保管制，使得信托計劃的資金保管業務已成為商業銀行重要的中間業務，信托公司和商業銀行之間形成了密不可分的業務關系[1][2]。根據國家監管要求，集合信托產品要求在銀行設立保管戶，保管戶內的資金進出須委托保管銀行進行操作[3]。這就使得信托公司在銀行賬戶體系設置上和一般的非金融公司有比較大的差異，日常的轉賬業務在管理、操作規范、操作流程上有明顯的行業特點。

本文以信托公司為例，重點討論基于深證通金融數據交互FDEP 平臺，建設信托公司電子指令管理系統，和保管銀行托管網銀系統建立系統間對接，實現信托公司保管戶線上電子劃款、支付結果查詢、交易流水查詢、實時余額查詢等功能。

2 系統設計原則

電子指令管理系統是以深證通金融數據交換平臺FDEP 平臺為基礎，和商業銀行的托管網銀系統對接的電子指令管理系統。設計時需充分考慮以下原則：

2.1 基本原則

（1）安全性設計原則：由于電子指令消息通道的應用必將會極大提高企業的支付的效率， 但同時也大大提高了支付的風險，因此系統安全性是電子指令系統設計方案中基本并且重點的需求。

（2）網絡安全：公司防火墻在網絡協議層發揮安全功能，將許可的源目的IP 地址和端口之外的所有網絡通信攔截在外。

（3）通用性原則：由于信托計劃的資金實行保管制，這就使得信托公司和商業銀行在業務合作上的密不可分在系統設計上，需要考慮滿足和大多數商業銀行的托管網銀系統電子對接的行業通用及流行的技術開發工具。

（4）實用性原則：電子指令系統的使用者主要是業務人員和資金管理人員，因此系統在安全可靠的前提下，必須易學、易用，方便快捷[4]。

2.2 可擴展性原則

系統設計要考慮當前信息技術發展趨勢，采用微服務、組件化的設計原則，對系統進行整體規劃和實施。

2.3 參數驅動原則

采用參數驅動的設計方法，可以增加系統對業務適應的靈活度。業務的發展變化，可通過調整系統參數配置的方式，快速實現對業務的支持。

2.4 組件化設計原則

將應用系統的功能、對象、數據加工邏輯進行分析、抽取，形成組件庫。減少系統的重復開發的資源冗余，保持系統在相同對象使用上，設計風格一致，減少開發成本，有效提高開發效率。

2.5 模塊化設計原則

將系統設計成多個相互獨立的應用模塊。通過對各個模塊的靈活組合，向不同的用戶群體提供不同的個性化系統。

圖1：系統邏輯結構圖

圖2：報文傳輸系統架構圖

3 總體設計概述

3.1 系統目標

（1）建立資金結算電子指令管理系統，對資金結算指令進行統一管理，與保管銀行托管網銀系統建立劃付直連。

（2）建立電子指令管理系統，利用現代化技術，提供自動化支付手段及通知提醒機制，減少手工操作，提高資金人員工作效率。

（3）提供授權嚴密的電子支付操作流程，保證系統劃付的安全性和可審計性。

（4）信息傳輸過程中防止被他人截取、篡改和破壞，使用電子消息報文加密機制。

3.2 系統邏輯結構

電子指令管理系統邏輯結構分為5 層：業務層、服務層、數據層、接口層、應用層。具體如圖1 所示。

業務層：需要通過電子指令系統進行支付和查詢的業務系統。電子指令系統接收各業務系統發出的資金調撥申請。

服務層：系統平臺提供的基礎服務，包括系統登陸管理、安全訪問管理、組織機構等。

數據層：用于基礎資料的維護管理、指令系統從銀行查詢的銀行余額和銀行流水等數據的存貯層。

接口層：通過通信協議，報文加密、報文解密、報文解析、身份認證等完成業務系統、FDEP 和電子指令系統的數據傳輸。

用戶層：只通過該系統進行電子支付、流水交易查詢、余額查詢的用戶。

3.3 報文傳輸系統結構

信托公司電子指令信托、深證通FDEP 平臺和銀行托管網銀信托之間消息交換路徑如圖2 所示。

4 系統功能設計

4.1 系統功能結構

電子指令系統功能上主要包括基礎數據管理、制單管理、支付指令管理、查詢指令管理、指令報文管理5 個模塊。

4.2 主要功能介紹

4.2.1 基礎數據管理

主要用于維護電子指令系統使用的基礎代碼。包括公司的資產組合信息、銀行賬號信息、常用收款人、業務類型、數據權限的新增、修改、刪除功能。

4.2.2 制單管理

制單管理模塊功能包括：手工制單、批量導入制單、劃款審批。

4.2.3 支付指令管理

（1）電子指令通道開關設置。按銀行賬號設置電子指令開關。區分電子支付開關、余額查詢開關、交易流水查詢開關三種查詢的參數設置。

根據和銀行接口開通情況，設置相應查詢的開關參數，這種設計極大的提高了系統使用的靈活度。

（2）電子支付指令發送。將付款賬號是托管賬號的資金調撥申請，統一歸集到電子指令系統。電子指令系統有即時支付和預約支付兩種模式。即時支付，即刻將電子支付指令發送到深證通，深證通發送到銀行，托管銀行收到電子支付指令后，馬上進行處理。預約支付是約定在未來某天將電子支付指令發送到托管銀行。指令發送前需要先校驗該付款銀行賬號，是否已經打開了支付開關，支付開關關閉時，該付款賬號不可以進行電子劃款。系統按照該付款銀行在系統中配置的支付報文參數，組織報文數據，形成電子支付指令，發送到銀行。付款指令發送動作完成，付款指令狀態須馬上更新，防止系統并發或者其他錯誤導致的用戶再次發送該筆指令造成重復支付。執行指令發送后，該筆電子支付指令是否發送銀行成功，需要通過銀行反饋的應答報文來判斷。

（3）指令撤銷。已經發送到托管銀行的指令，如需中斷支付，則需主動發起指令撤單。資管人發送撤單指令給托管行，托管銀行馬上反饋響應報文。通過銀行響應報文可以判斷銀行是否撤單成功。

（4）指令作廢。未發送到銀行的資金調撥申請，將其作廢后，該調撥申請將不再執行付款。

（5）電子對賬。電子支付系統每日接收銀行交易流水，付款流水每日日終自動和發送到銀行的電子指令進行對賬，確保每筆資金轉賬成功。收款流水則根據收款銀行賬號分發給對口業務系統，進行業務對賬。

（6）異常處理。根據銀行返回的報文，報文解密、解析后，電子支付指令狀態為“銀行接收失敗”、“支付失敗”、“銀行拒絕”等支付狀態，系統則依據不同的支付狀態設計不同的指令處理流程。銀行反饋指令接收失敗，則返回報文中會有比較明確的原因告知發送方指令不被接收的原因。用戶可以修改系統中的指令上的非敏感信息后重新發送指令，或者作廢該指令重新錄入一筆新的資金調撥單，經過審批后在進行線上支付。如果銀行反饋是支付失敗狀態，則系統發出支付失敗通知給指令發送人，發送人線下聯系銀行詢問支付失敗具體原因，根據銀行線下交流反饋決定該筆指令是修改后重新提交，還是等待銀行繼續支付。如果銀行返回拒絕或者作廢的狀態，則該單據在銀行將不被繼續執行支付，發送方可以作廢該筆指令或者修改非敏感信息后重新發送電子支付指令到銀行再次支付。

異常處理主要功能包括：電子支付指令發送失敗異常處理、電子支付指令支付失敗異常處理、電子支付指令銀行審批拒絕處理、電子支付指令撤單失敗處理等功能。

4.2.4 報文管理

由于各家銀行接口要求傳入的報文字段和格式不同，系統采用報文參數配置模式組裝報文。資管人發送給銀行的電子指令報文，需根據銀行接口要求進行加密處理。收到銀行的報文，則需要按照雙方約定進行解密，然后根據系統報文參數配置，對報文進行解析。

報文管理模塊主要功能包括：各家銀行報文組裝格式參數設置、報文組裝、報文加密、報文解密等功能。

4.2.5 查詢指令管理

通過建立和FDEP 平臺的電子消息交換通道，可以發送查詢指令通過FDEP 平臺到托管銀行，查詢每日交易流水、歷史交易流水、當前實時余額及電子付款指令的最新付款狀態。

查詢指令管理模塊主要功能包括：支付指令進度狀態查詢、銀行當日交易流水查詢、銀行歷史交易流水查詢、銀行當前余額查詢。

5 實施效果

來手工劃款模式下，從一筆付款指令的錄入到最終支付，需要經過審批、單據打印、傳真、郵件、查詢網銀流水，反饋支付狀態等大約7 個環節。不考慮每個中間環節和銀行處理的等待時間，按照順行持續執行的時間，一筆支付從錄入到最終支付完成，全流程最快需要6 分鐘完成。同一筆付款指令，從電子指令系統劃款，可以節省中間3～4 個人工環節，最快執行時間可以達到3 分鐘。極大提高了資管人日常業務劃款效率和劃款的準確度。

不考慮銀行處理等待時間，按照資金人員連續作業不停頓的時間估算，電子指令的支付效率，比傳統手工線下支付效率提升至少50%。

6 結論

從上述系統分析與設計可以看出，以深證通金融數據交換平臺作為數據交換通道，建設資金劃付電子指令系統，是一種適合金融行業資管人和銀行托管網銀系統之間通用的、可行的系統方案。這種數據交換模式在資管人和保管人間經過多年的使用和驗證，技術發展的已經越來越成熟。這種三方相結合構建的電子指令消息通道的管理模式，已經被更多的金融企業和托管銀行所認可，并形成了一種行業規范和行業模式。特別是由于信托公司、深證通、商業銀行三方在網絡、系統安全、數據等方面采取了更加嚴格的安全保障措施，保障了業務的平穩運行和各方的資金安全，從而得到了客戶的認可。該方案建成的電子指令系統，提升了效率，帶來了利潤的增長，為公司業務擴展贏得了機會，必將會得到更為廣泛的應用。