社保財務與銀行間支付數據交換及資金處理的應用實踐

［摘 要］多渠道的社銀支付，解決的是社保與銀行之間信息傳遞的問題，實現了社保和銀行雙方不落地的數據交互，以及高效的支付數據提交、處理和反饋。交易數據通過系統間的有效傳遞，能使社保賬戶數據更加透明、支付過程有效縮短，資金流向更加精確，同時也能不斷提高參保人員的滿意度。另外，由于截斷了人工介入的渠道，資金支付風險也得到了有效的控制［1］。本文詳細介紹了社保和銀行間的交互方式、后續處理流程的觸發、對應支付資金的處理、安全性及其他數據交換等內容。實際應用證明，通過實現社銀支付的有效交互，能為社保資金支付提供更高效、便捷、安全的基金結算服務。

［關鍵詞］社會保險；按月批量支付；社銀支付；實時交互；風險控制

doi：10.3969/j.issn.1673-0194.2023.01.021

［中圖分類號］F840.61；F830.45 ［文獻標識碼］A ［文章編號］1673-0194（2023）01-0078-04

1" " "應用背景

上海社保基金結算系統與銀行間的支付內容包括以下五部分：第一，支付給個人的養老金、退休金、退職金、職業年金等按月支付業務；第二，支付給單位或個人的喪葬撫恤金和補助金、傷殘補助金、個人賬戶儲存額返回等一次性支付業務；第三，轉移支出或轉移收入退回等異地轉移接續業務；第四，本市跨險種劃轉、賬本間劃轉等資金管理類業務；第五，退誤入款、支付失敗再支付等其他業務。所有的支付業務都需要和銀行進行交互，包括社保基金所在的付款方開戶銀行和收款方的開戶銀行。交互內容包括待遇發放的數據和需支付資金的數據，這兩者有聯系也有不同。因此，高效、便捷、安全的基金結算服務顯得尤為重要。

2" " "數據交互

2.1" "交互內容

交互內容包括社保給銀行的應支付信息，也包括銀行反饋給社保的實際支付結果。

以文本文件形式交互。文件的格式，包括首記錄和明細記錄，可以是TXT格式，也可以是XML格式，社銀雙方事前約定好即可。每次交互由社保方產生應支付數據的文本文件放在交換平臺的FTP上，由銀行獲取，待銀行支付后將實際支付結果以文本文件的形式通過FTP反饋給社保，社保將FTP上的支付結果導入系統，形成一次完整的支付流程，如圖1所示。應支付信息和實際支付信息可以是對稱的，一批應支付信息對應一批實際支付信息，對每一筆支付結果都進行反饋，也可以是非對稱的，只針對支付失敗的數據進行反饋。

以報文形式交互。根據業務不同，事先約定不同格式的報文格式加以區分。由社保發起請求，將發放的數據或資金信息提供給銀行，銀行對該請求進行反饋，告知社保支付結果。由于存在跨行支付，支付結果不能當場獲取，需要社保方異步獲取支付結果，可以由社保方發起查詢也可以由銀行發起結果反饋。例如，社保待遇社銀支付就是由社保方發起查詢，通過兩個報文交互接口（社銀支付接口、社銀支付結果查詢接口）實現社銀直連實時支付，如圖2所示。

這兩種方式都需要事先約定文件或報文格式，開發程度要求較高，且各地沒有統一的規范報文格式，前期文檔規范的調研等工作需要花費較長時間［2］。

2.2" "交互對象

交互對象包括社保方（付款方）開戶行、對方（收款方）開戶行。

只對一家付款方開戶銀行交互，將需要支付的信息，包括數據和資金都發給銀行，由銀行直接從社保開戶行出資進行支付。優點是不需要和所有收款方銀行進行交互，而是只需要和一家社保開戶銀行進行交互，支付資金和數據也可以合并在一起，減少交互次數。缺點是會涉及跨行支付，到賬時間會略有延遲，不適合對到賬時間有精確要求的業務。目前當場結算支付的業務使用的是這種方式，實時進行支付，確保第一時間將支付信息提供給銀行。

同時和多家收款方開戶銀行交互，將支付數據發給銀行，資金和數據分開，先將需支付的資金劃轉給銀行，再由銀行根據支付數據進行代發操作。目前對于到賬時間有精確要求的按月養老金業務，仍使用這種方式進行，保證每月養老金準時支付到養老人員個人卡折。

2.3" "后續處理的觸發

社保及銀行后續處理的觸發方式有報文觸發、定時任務觸發、操作人員前臺點擊觸發等。

報文觸發。每次社保或銀行發起交互信息后，通過發送報文給對方，代替交接單進行告知，直接觸發入庫操作，并提示操作人員數據已入庫。操作人員針對已入庫數據進行核對，實現無紙化操作。

定時任務觸發，類似于報文觸發，在系統中設置定時任務，按一定時間間隔進行輪詢，查看FTP上是否有支付結果反饋文件，如有反饋文件則對數據進行入庫，同樣可以實現無紙化操作。

操作人員前臺點擊觸發。每次社保或銀行發起交互信息后，通過紙質交接單、紙質銀行回單或電子回單告知對方，由對方的操作人員對數據和紙質內容進行核對后入庫。

當前社保在金保二期中采用的是無紙化的報文觸發方式。通過文件交互時，將文件放到FTP后發送報文給對方，觸發對方的后臺應用。通過報文交互時，發起支付結果查詢，實時獲取支付結果。

2.4" "支付資金處理

對于代發銀行，一批數據支付一筆資金給銀行，由銀行進行代發。因各種原因代發失敗的資金也通過一筆資金反饋給社保。代發銀行將數據對應的資金合并為一筆支出銀行賬及一筆收入銀行賬，如沒有失敗數據，則沒有這筆收入的銀行賬。通過這種方式，針對大數據量的支付，可以減少大量的銀行賬操作，減輕財務人員的工作量。

2.5" "反饋時間間隔

采用報文實時交互的方式，可以實時查詢支付結果，由銀行告知支付失敗、成功或是支付途中結果未知。適合支付量小，響應時間要求高的業務。但支付數據量太大時，如對方還有對報文的各種校驗，反饋時間一般較長，導致超時報錯，無法獲取支付結果。可以針對整個報文進行結果查詢，也可以針對報文中的部分數據進行查詢。接口規范需根據實際業務需要進行協商。

以文件形式交互的數據。即每月月底產生支付文件交給銀行，由銀行按日進行支付，到月底對稱反饋支付結果的形式。優點是支付文件只需產生一次，減少了工作量，缺點是反饋和實際支付時間的間隔長，遇到月初支付不成功的數據，再次支付要等第二個月，參保人員體驗較差。因此，在金保二期的改造過程中，將每月一次的支付文件按日拆分。雖然發送給銀行的數據頻次增加了，但銀行進行支付后就能直接對稱反饋支付結果，最快第二天就能對支付失敗數據進行再支付操作，大大縮短了再支付的時間，提升了服務質量。

通過郵政儲匯支付的數據。由于情況特殊，郵匯往往需要三個月甚至更長時間才能提供支付成功還是失敗的反饋信息。因此，反饋支付結果入庫后，另有接口支持郵匯隔一個或多個月后將失敗數據反饋給社保。

2.6" "安全性

由于社保支付數據量大，數據安全就顯得尤為重要。

各家銀行申請專線和社保對接，銀行端與社保端各放置一臺前置機，通過專線連接。社保中心防火墻上開啟允許前置機對社保前置機的Socket訪問。銀行與企業采用傳統報文交互的方式，通過前置機與銀行服務進行通信。

從原先使用的FTP協議改為使用SFTP協議。SFTP針對每家銀行設置專用目錄及權限，一家銀行一個用戶，各個銀行使用用戶名登錄后，只能看到本銀行目錄下的信息。文件按一定命名規則存放，不能刪除、覆蓋，保留軌跡。

對報文進行加密。采用RSA數字簽名和3DES加密相結合的方式進行加密，針對每家銀行的公鑰和密鑰都不相同，確保報文安全。

全程不落地。文件直接通過SFTP交互，通過發送和接收報文進行觸發，只能入庫SFTP上的文件。操作人員可以對文件進行抽樣檢查，但沒有權限上傳已修改或未修改的文件。不需要操作人員上傳本地文件，也不需要將文件通過U盤、光盤等形式交互。

為防止重復支付，每條支付數據都有唯一編碼標識。在自身不重復支付的前提下，也供銀行校驗是否有多次同樣編號的數據進行了支付，防止誤操作、多支付。

2.7" "借用第三方進行支付處理

根據實際要求，現有部分支付數據需通過第三方進行支付，如職業年金的支付需要通過支付計劃的機構，職業傷害需要通過相應的商業保險機構等。交互方式同社保與銀行間交互類似，根據支付數據量大小，選擇實時報文或SFTP文件形式進行交互。

2.8" "實時查詢

通過和銀行間交互，實現實時查詢交易流水，實時查詢當前賬戶實時余額，實時對賬等財務查詢要求。不需每月由銀行出具紙質對賬單，在線上就能獲取銀行簽名的PDF版本對賬單、銀行每月流水，實現全程無紙化。

3" " "風險控制

3.1" "風險點

對于支付數據，主要風險點在于多支付資金、少支付資金、支付數據遺漏、重復支付、支付的對方賬戶信息錯誤等。包括應支付數據錯誤和實際支付時的錯誤。

3.2" "原因分析

操作問題。操作時繳費基數、月份、對方銀行賬戶等信息錄入錯誤，會導致應支付數據遺漏、支付金額有誤、支付對象錯誤。漏操作會導致應支付數據遺漏。重復操作或未將問題數據完整撤銷，會導致應支付數據重復。

程序問題。這種情況容易發生在政策調整、計算規則有變化的時候，如程序未及時調整到位，或對特殊人群的處理沒有考慮周全。由于不是操作問題個案，會有大批量應支付數據產生異常。

網絡問題。當出現網絡延遲、中斷，數據交換平臺短時間內無法連接等情況，社保發送給接收銀行或接收銀行發送給社保的報文就會接收不到，有可能導致數據重復發送、重復支付。

銀行端問題。銀行反饋支付結果與實際結果不一致，實際支付失敗，反饋給社保成功；或者相反，實際支付成功，反饋給社保失敗。每筆支付的結果都需要銀行在線反饋給社保并提供相應的電子回單。如果銀行反饋數據有誤，就會導致支付成功失敗結果和電子回單有差異，最終使社保方的銀行賬和實際支付情況不一致。

3.3" "風控方案

事前預防。在數據發送到銀行進行支付前的風險控制，預防應支付信息有誤。

業務在操作變更時增加對數據的校驗，增加提示和卡口。對于相同對象相同金額的支付數據，提示操作人員一天內已有同樣的支付變更，請操作人員先行判斷本次錄入的信息是否重復。

財務在批量支付數據匯總和審核時，以資金安全為關注點，通過對支付數據的比對，以限額預警、重復支付、異常情況分析等為切入點，統一篩選出基金支付中存在的疑似風險數據，再逐一進行核查，從而規避基金運行風險，減少基金損失。

一是大額支付預警。以批量的支付數據為基礎，覆蓋全部支付險種，按照險種和支付類型分別設置預警閾值，對于超過預警閾值的數據進行預警并核實，在支付前核查所有預警數據，防止基金產生重大損失。

二是重復支付預警。深入挖掘業務經辦過程中的相關疑似數據，在生成基金支付批量和社銀數據時，系統自動篩選出同一批支付數據中同險種、同對象且支付金額相同的人員、單位的支付信息，在支付前予以進一步核查，減少對基金造成的損失。

三是異常分析。依據一定歷史時間的支付情況，按照險種、支付項目和支付方向分別自動計算出支付總額、筆數和平均金額，按允許的差異偏離度進行判斷，提前發現支付總筆數、總金額、平均值等指標異常的數據。對部分業務的收款人全稱字數設置下限，如支付到單位或機構的戶名不能少于5個字，減少部分戶名有誤的情況。

事中控制。指銀行收到應支付信息但尚未支付時的校驗，是社保對銀行提出的校驗要求。提供給銀行的支付數據都有唯一流水號，網絡延遲、中斷等情況會使銀行多次收到同一個流水號的支付請求。銀行對于同一個流水號的數據只能進行一次支付，不允許多次對同一個支付流水號的數據進行支付操作。銀行反饋的支付結果需要和反饋的電子回單信息保持一致，也應與實際支付結果保持一致。一筆成功支付的資金對應一筆電子回單信息，不能有一對多或多對多的情況。

事后檢驗核實。社保在逐筆記錄銀行日記賬時，需要銀行反饋的支付結果與電子回單保持一致才能記賬。如有不一致的情況產生，需及時和銀行聯系，最終以實際支付結果入賬。每月月中可隨時核對銀行支付流水，定期在月末進行逐筆對賬，及時處理異常數據，防止并糾正社保數據與銀行不一致的情況。

4" " "小 結

通過對不同應用場景的分析，上海社保靈活采取以上各種數據交互、數據處理的方式，有效地提高了財務支付效率，實現“秒到賬”；顯著減少了財務工作人員的工作量；通過專線對接，報文加密，全程不落地，截斷了人為干預修改數據的渠道，防控了風險［3］。

主要參考文獻

［1］賈小強，郝宇曉，盧闖.財務共享的智能化升級：業財稅一體化的深度融合［M］.北京：人民郵電出版社，2020.

［2］徐燕. 財務數字化建設 助力企業價值提升［M］.廣州：華南理工大學出版社，2021.

［3］濰坊市社保中心.濰坊市：“社銀直聯”開通社保支付“高速路”［J］. 山東人力資源和社會保障，2018（12）：42-43.