MT940報文在銀企直連中應用的方法及系統與流程

2023-10-18 19:39:39 2

本發明涉及信息化管理技術領域和網際網路技術領域，具體涉及一種銀企直連發匯打款系統。

背景技術：

外貿電子商務平臺作為電子商務平臺的一種，在實際的業務運營過程中也自然存在對於平臺入駐商戶進行結算的流程。從海外買家下單支付，到商戶發貨以及買家確認收到貨物，再到外貿電子商務平臺為商戶進行放款，最後商戶進行自主提現，由平臺財務運營人員為商戶進行結算。

在傳統外貿電商平臺結算處理的流程中，財務運營人員需要對於從平臺下載導出的商戶提現數據進行核對及格式調整後，由經辦人員將提現數據上傳到銀行的企業網銀，並由具有權限的審核人員進行審核後，款項才正常進行下發。公開號為CN105069684A一種財務銀企互聯信息系統，雖然在實現銀企直連,但是限於部分外資銀行並不提供實時的下發接口,所以即便是銀企直連後仍需要根據銀行打款的情況，再將結果回傳到系統中，以便於商戶了解提現成功與否，對於失敗的情況需要人工操作銀行打款失敗原因以及將退回款項返還到商戶的平臺資金帳戶中。這個過程中由於涉及人為操作的環節過多，所以有相當大的操作風險，同時相應的運營效率和準確性也是很低的。同時商戶無法通過電子商務平臺來獲取銀行水單，導致商戶經常諮詢財務人員款項是否已經真實下發。現有技術方案中，對於銀企直聯發匯結果更新的環節，還需要完全依賴於財務人員手動在發匯銀行下載流水，並在系統中進行手工更新。非常麻煩，而且時效性差，同時存在較大的操作風險。

MT940是SWIFT(環球同業銀行金融電訊協會)制定的一種標準的全球銀行間清算的報文協議。其中MT940可以理解為銀行對帳單，上面會清晰記錄每一筆帳戶收支的詳細信息。

技術實現要素：

針對上述的難題，本發明提出MT940報文在銀企直連中應用的方法及系統，以達到結算款項下髮結果自動確認，降低運營風險和效率的目的。

本發明的技術方案是：一種MT940報文在銀企直連中應用的方法，建立MT940報文發匯信息模型，包括：

S1、用戶發起提現申請，平臺記錄用戶提現申請信息；

S2、平臺審核提現申請，並登記發匯批次信息；

S3、將發匯信息發送給發匯銀行；

S4、發匯銀行處理髮匯請求，生成MT940報文發匯信息；

S5、平臺定時獲取MT940報文發匯信息；

S6、解析MT940報文並跟新發匯批次和提現申請信息；

S7、對提現信息進行判斷和處理；

所述步驟S4中，發匯銀行處理失敗時將退回用戶的提前請求；所述步驟S7中，如果提現成功，則獲取並更新銀行水單，如果失敗則退回處理。

在上述任一方案中優選的是，所述的MT940報文發匯信息模型包括如下模塊：

發匯批次信息模塊，用於記錄有關發匯批次匯總的信息；

發匯明細信息模塊，用於記錄每一筆發匯明細信息；

提現申請信息模塊，用於記錄商戶提現的明細信息；

發匯銀行流水信息模塊，用於記錄導入的MT940客戶銀行帳單的記錄；

發匯銀行提現退回信息模塊，用於記錄銀企直連發匯的退回信息。

在上述任一方案中優選的是，所述發匯批次信息模型包含：發匯批次號、發匯幣種、業務類型、發匯通道、發匯時間、發匯總筆數、發匯總金額、成功總金額、成功總筆數、失敗總金額、失敗總筆數、狀態、審核人、審核時間、參考號中至少一種。

在上述任一方案中優選的是，所述的發匯明細信息模型包含：發匯批次號、發匯幣種、業務類型、發匯通道、開戶人、卡號、金額、開戶行、開戶地、狀態、銀行手續費、登記時間、登記人中至少一種。

在上述任一方案中優選的是，所述的提現申請信息模型包含：提現申請ID、提現申請人、平臺商戶號、提現申請時間、提現幣種、提現金額、開戶人、卡號、狀態、發匯批次號中至少一種。

在上述任一方案中優選的是，所述的發匯銀行流水信息模型包含：日期、借貸標識、金額、餘額、交易類型、識別碼、關聯ID、發匯關聯號、消息ID、備註、入庫時間、核對標識中至少一種。

在上述任一方案中優選的是，所述的發匯銀行提現退回信息模型包含：登記日期、發匯關聯號、退回金額、發匯批次號、發匯明細ID、發匯日期、發匯金額、發匯手續費、賣方暱稱、戶名、帳號、銀行識別碼、處理標識、處理狀態、複合狀態、實際退回入帳金額、操作人、操作時間、備註中至少一種。

在上述任一方案中優選的是，所述步驟S3包括以下子步驟：

S301、根據發會信息，生成發匯銀企直聯iFile文件；

S302、通過文件傳送協議，使用Axway客戶端發送給發匯銀行；

S303、發匯銀行校驗文件格式，校驗成功則進行下發處理。

在上述任一方案中優選的是，所述步驟S302是使用Axway加密軟體將iFile文件加密傳輸到發匯銀行伺服器。

在上述任一方案中優選的是，所述步驟S303，當校驗失敗時，將返回返回File Exception Report，平臺解析異常文件通知。更新異常文件批次為失敗，重新生成批次，退回到步驟S301重新生成文件。

在上述任一方案中優選的是，在銀行校驗失敗的同時將發送郵件進行提醒。

在上述任一方案中優選的是，所述步驟S303中，當校驗通過後，返回文件上傳報表並更新批次狀態為受理成功。

在上述任一方案中優選的是，提現記錄模塊、財務人員操作管理模塊、發匯批次信息模塊和通知處理模塊。

在上述任一方案中優選的是，所述提現記錄模塊來記錄平臺所有用戶的提現申請，所述財務人員操作管理模塊包括財務人員審核提現記錄，生成發匯批次信息，退回提現申請操作，所述發匯批次信息模塊實現了提現申請記錄自動轉換成發匯批次信息，並發送給發匯銀行，所述通知處理模塊實現了定時自動獲取發匯銀行伺服器的MT940報文信息，並自動解析報文，根據結果不同進行不同的消息通知處理。

在上述任一方案中優選的是，所述提現記錄模塊用於記錄平臺用戶的提現申請信息，查看提交申請的審核狀態，賣家的提現申請只有在帳號餘額大於0的時候才能進行提現申請，並且提現申請中的資金數額會從餘額中扣除，提現狀態以高亮文字顯示。

在上述任一方案中優選的是，所述財務人員操作管理模塊具有可通過系統查看所有賣家的提現申請記錄並進行管理，可以通過系統進行審核並生成發匯批次信息的功能。

在上述任一方案中優選的是，所述的發匯批次信息模塊具有將發匯批次信息進行編碼生成iFile文件，並通過文件傳送協議協議，使用Axway客戶端發送給發匯銀行的功能。

在上述任一方案中優選的是，所述的通知處理模塊具有定時獲取發匯服務的MT940報文信息，解析報文並及時更新提前申請和發匯申請狀態，接收發匯銀行的文件異常通知和校驗成功通知並及時處理這些通知的功能。

由於採用上述技術方案，解決了結算流程人工運營環節較多、款項下髮結果不及時、操作風險、平臺不能為商戶提供銀行水單的問題。有效的降低了財務的運營成本，大大提高了銀企直連的自動化程度。

附圖說明

圖1按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的滙豐銀企直聯數據模型；

圖2按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的外貿電子商務平臺的滙豐銀企直連下發流程圖；

圖3按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的滙豐銀企直聯網絡架構圖；

圖4按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的滙豐MT940在銀企直聯的應用流程圖；

圖5按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的跨境電商平臺銀企直連繫統的MT940帳單獲取模式說明圖；

圖6按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的跨境電商平臺銀企直連繫統的舊的滙豐銀企直聯發匯流程圖；

圖7按照本發明的MT940報文在銀企直連中應用的方法及系統的一個優選實施例的跨境電商平臺銀企直連繫統的新的滙豐銀企直聯發匯流程圖。

具體實施方式

下面詳細描述本發明的實施例，所述實施例的示例在附圖中示出，其中自始至終相同或類似的標號表示相同或類似的器件或具有相同或類似功能的器件。下面通過參考附圖描述的實施例是示例性的，僅用於解釋本發明，而不能解釋為對本發明的限制。

一種MT940報文在銀企直連中應用的方法，包括以下步驟：

S1、用戶發起提現申請，平臺記錄用戶提現申請；

S2、平臺審核提現申請，並登記發匯批次信息；

S3、將發匯信息發送給滙豐銀行；

S4、滙豐銀行處理髮匯請求，生成MT940報文發匯信息；

S5、平臺定時獲取MT940報文發匯信息；

S6、解析MT940報文並跟新發匯批次和提現申請信息；

S7、對提現信息進行判斷和處理。

所述步驟S4中，滙豐銀行處理失敗時將退回用戶的提前請求；所述步驟S7中，如果提現成功，則獲取並更新銀行水單，如果失敗則退回處理。

本案中將以外貿電子商務平臺A為例，說明本發明如何實現MT940在銀企直連中的應用過程。我們首先建立了如下的發匯信息模型：

所述的MT940報文信息模型包括：

S201、建立發匯批次信息模型，記錄有關發匯批次匯總的信息；

S202、建立發匯明細信息模型，記錄每一筆發匯明細信息；

S203、建立提現申請信息模型，記錄商戶提現的明細信息；

S204、建立發匯銀行流水信息模型，記錄導入的MT940客戶銀行帳

單的記錄；

S205、建立發匯銀行提現退回信息模型，記錄滙豐銀企直連發匯的退回信息。

如圖1所示，包含了5張數據信息表。分別包含的信息：

所述的S201發匯批次信息：用來記錄有關發匯批次匯總的信息。包含發匯批次號、發匯幣種、業務類型、發匯通道、發匯時間、發匯總筆數、發匯總金額、成功總金額、成功總筆數、失敗總金額、失敗總筆數、狀態、審核人、審核時間、參考號。

所述的S202發匯明細信息：用來記錄每一筆發匯明細信息。包含發匯批次號、發匯幣種、業務類型、發匯通道、開戶人、卡號、金額、開戶行、開戶地、狀態、銀行手續費、登記時間、登記人。

所述的S203提現申請信息：用來記錄商戶提現的明細信息。包含提現申請ID、提現申請人、平臺商戶號、提現申請時間、提現幣種、提現金額、開戶人、卡號、狀態、發匯批次號。

所述的S204豐銀行流水信息：用來記錄導入的MT940客戶銀行帳單的記錄。包含日期、借貸標識、金額、餘額、交易類型、識別碼、關聯ID、滙豐關聯號、消息ID、備註、入庫時間、核對標識。

所述的S205發匯銀行提現退回信息：用來記錄滙豐銀企直連發匯的退回信息。包含登記日期、滙豐關聯號、退回金額、發匯批次號、發匯明細ID、發匯日期、發匯金額、滙豐手續費、賣方暱稱、戶名、帳號、銀行識別碼、處理標識、處理狀態、複合狀態、實際退回入帳金額、操作人、操作時間、備註。

所述步驟S3中通過銀企直連方法包括：

S301、根據發會信息，生成滙豐銀企直聯iFile文件；

S302、通過文件傳送協議，使用Axway客戶端發送給滙豐銀行；

S303、滙豐銀行校驗文件格式，校驗成功則進行下發處理。

所述步驟S302是使用Axway加密軟體將iFile文件加密傳輸到滙豐銀行伺服器。

所述步驟S303，當校驗失敗時，將返回返回FileExceptionReport，平臺解析異常文件通知。更新異常文件批次為失敗，重新生成批次，退回到步驟S301重新生成文件。

所述步驟S303中，在滙豐校驗失敗的同時將發送郵件進行提醒。

所述步驟S303中，當校驗通過，返回文件上傳報表並更新批次狀態為受理成功。

如圖2所示，外貿電子商務平臺的滙豐銀企直連下發流程：

1、賣家申請提現美元，登記提現申請信息。具體實現流程為賣家登錄系統平臺，點擊個人中心，查看帳號信息，這裡提供唯一外匯提現申請入口，賣家點擊外匯提現申請，填寫外匯提現申請信息，點擊確定按鈕，將提現申請信息錄入系統資料庫。

2、財務人員在系統的操作管理模塊中進行操作，選擇發匯幣種美元、通道滙豐，對於銀行帳戶暫停和資金帳戶凍結的賣家，將提現操作失敗退回，並通過郵件下發給賣家提醒。對於通過校驗的提現記錄，系統登記發匯明細信息,來記錄每一筆發匯明細信息。

3、財務人員在系統的操作管理模塊中進行操作，點擊發匯審核，校驗通過的發匯記錄並生成發匯批次信息，來記錄有關發匯批次匯總的信息。將發匯批次匯總信息通過加密方式生成滙豐iFILE文件，使用Axway客戶端發送給滙豐銀行。

4、滙豐銀行系統對接收到的iFILE文件進行格式校驗，若格式校驗失敗，則滙豐會生成文件異常報告，並以通知系統平臺，平臺收到通知後對報告進行解析出滙豐提現退回信息，解析過程如下：對於涉及具體校驗格式失敗行為對應的發匯數據，操作發匯失敗退回，同時更新發匯狀態及提現狀態。發送郵件提醒。

5、滙豐銀行系統對接收到的iFILE文件進行格式校驗，若格式校驗通過，則滙豐會生成文件上傳報告並進行發匯處理，生成滙豐銀行流水信息，然後把滙豐銀行流水信息加密生成MT940報文放到滙豐文件傳送協議伺服器上，系統獲取滙豐上傳報告並解析，對於批次明細狀態為01的記錄，操作發匯成功，同時更新發匯狀態及提現狀態，批次狀態更新為「處理中」。

如圖3所示，滙豐銀行收到Axway轉發的發匯文件，並且處理完成後，會在次日約定的時間將昨日的MT940文件放在滙豐文件傳送協議伺服器上。當Axway的客戶端檢測到滙豐生成MT940報文之後，會主動從滙豐伺服器獲取對應的文件信息，並發送給跨境電子商務平臺。跨境電子商務平臺收到MT940文件之後進行解析，解析出滙豐銀行流水信息。

圖4所示，一種應用MT940報文的銀企直連繫統的流程如下，首先通過文件傳送協議伺服器獲取帳戶MT940報文，然後進行解析，獲得報文信息。根據報文信息，更新發匯批次狀態和提現狀態，接下來進行提現失敗的判斷，若失敗則退回處理，若成功則獲取及更新銀行水單。

系統每日獲取上日的對帳單進行解析並進行入庫(滙豐銀行流水信息)處理，對應關係如下表所示：

若借貸標識為貸，關聯ID為退款開頭，核對標識為否，同時截取該欄位的8-16為存儲在滙豐關聯號中。此時關聯ID應為空值。若為BIB-HEGUANG INTL，核對標識為「是」。若借貸表示借，關聯ID為數字，則核對標識「否」，其他情況，核對標識為「是」。

入庫完成後然後根據當日對帳單中的發匯明細ID及發匯金額匹配系統中對應的發匯記錄進行更新。對於發匯明細ID一致，發匯金額不一致的情況，則發送簡訊提示財務人員，簡訊內容為如下：

賣方暱稱開戶人帳號前六後四於發匯日期打款系統發匯金額100$與滙豐實際下發金額99$不一致，請核查。

如果核對一致的話，根據發匯明細ID更新對應的發匯明細狀態以及發匯批次的成功筆數、成功金額。更新滙豐日記帳流水中該條核對標識為「是」。同時更新發匯批次狀態為「成功」，若發匯批次狀態已經為成功，則不再進行更新。對於狀態成功過的發匯記錄，在入庫時同時將對應的銀行流水保存在平臺的文件傳送協議地址上，並將對應的下載路徑提供給客戶，方便客戶進行自助下載。至此環節，MT940報文在銀企直連中的系統實現了整個外匯提現流程。以下是對異常情況的處理。

對於發匯失敗退回的處理，根據滙豐關聯號模糊匹配(正常滙豐關聯號為16位，退款的為9位，只能定位到批次)以及根據退回金額分別嘗試加上(7.75、14.86、7.11、7.76、14.87)且識別碼為TRF且銀行識別碼不為HSBC開頭匹配查詢滙豐日記帳流水信息：

若查詢到唯一對應的關聯號且為已核對的記錄，則根據對應的發匯明細ID查詢對應的發匯記錄信息，登記滙豐提現退回處理信息，同時更新滙豐日記帳流水中該筆退款對應的關聯ID。登記日期、滙豐關聯號、退回金額、發匯批次號、發匯明細ID、發匯日期、發匯金額、滙豐手續費、賣方暱稱、戶名、帳號、銀行識別碼、處理標識(初始為空)、處理狀態(待審核)滙豐手續費為跟據滙豐關聯號且識別碼為收費類型所對應的金額。

若沒有查詢到對應的記錄或者查詢到多條記錄，則直接登記滙豐提現退回處理信息。登記日期、滙豐關聯號、退回金額、處理標識(初始為空)、處理狀態(待審核)、備註。

若查詢到多條記錄，則需要登記備註信息的內容為：序號、賣方ID、戶名、銀行帳戶、發匯金額、銀行識別碼。

序號按照查詢到的多條記錄數排序。若沒有查詢到對應記錄，則無需更新備註欄位。

一種MT940報文在銀企直連中應用的系統，包括：提現記錄模塊、財務人員操作管理模塊、發匯批次信息模塊和通知處理模塊。

所述提現記錄模塊來記錄平臺所有用戶的提現申請，所述財務人員操作管理模塊包括財務人員審核提現記錄，生成發匯批次信息，退回提現申請操作，所述發匯批次信息模塊實現了提現申請記錄自動轉換成發匯批次信息，並發送給發匯銀行，所述通知處理模塊實現了定時自動獲取發匯銀行伺服器的MT940報文信息，並自動解析報文，根據結果不同進行不同的消息通知處理。

所述提現記錄模塊用於記錄平臺用戶的提現申請信息，查看提交申請的審核狀態，賣家的提現申請只有在帳號餘額大於0的時候才能進行提現申請，並且提現申請中的資金數額會從餘額中扣除，提現狀態以高亮文字顯示。

所述財務人員操作管理模塊具有可通過系統查看所有賣家的提現申請記錄並進行管理，可以通過系統進行審核並生成發匯批次信息的功能。

所述的發匯批次信息模塊具有將發匯批次信息進行編碼生成iFile文件，並通過文件傳送協議協議，使用Axway客戶端發送給發匯銀行的功能。

所述的通知處理模塊具有定時獲取發匯服務的MT940報文信息，解析報文並及時更新提前申請和發匯申請狀態，接收發匯銀行的文件異常通知和校驗成功通知並及時處理這些通知的功能。

如圖5為跨境電商平臺銀企直連繫統的帳單獲取模式說明。

對於跨境電子商務企業來說，一般傳統採用模式二的方式，由財務運營人員直接在滙豐銀行後臺下載帳戶的對帳單，再根據出入帳的明細，對銀企直連的發匯結果進行更新。在本案中，通過引入模式一，由滙豐銀行直接發送MT940報文的形式，有效的解決了財務的運營成本，增加了銀企直連的自動化程度。

通過圖7可以明顯看出在圖6的方案中，對於銀企直聯發匯結果更新的環節，還需要完全依賴於財務人員手動在滙豐銀行下載流水，並在系統中進行手工更新。非常麻煩，而且時效性差，同時存在較大的操作風險。在圖七的新方案中，由於引入了MT940的銀行對帳單，使得需要人工操作的流程完全實現了自動化，同時可以支持給賣家直接顯示銀行流水，降低了賣家對於款項到帳諮詢的疑問。

備註：

本系統中，銀行前置機需要使用銀行U-KEY，並由財務人員事先將U-KEY分配權限。

通過本案的實施，使外貿電子商務平臺A的結算下發流程有了比較顯著的改善。首先提現數據產生到登記發匯批次的流程上，實現了完全系統化處理，減少了人工參與的環節，不需要再將發匯文件上傳到銀行網銀，降低了財務運營成本及減少了操作風險。其次，對於銀行網銀執行的結果，通過MT940報文系統對接之後，能夠及時自動更新商戶提現狀態，對於失敗的提現申請直接操作失敗，同時將款項返還到商戶平臺資金帳戶中。最後，對於提現發匯處理成功的記錄，系統會自動將提現記錄與銀行返回的流水相關聯，使客戶能夠在外貿電子商務平臺下載銀行流水，提升了客戶體驗，降低了運營成本。

本方案保護的範圍是MT940報文在銀企直連中更新處理的機制。

以上對本發明的一個實施例進行了詳細說明，但所述內容僅為本發明的較佳實施例，不能被認為用於限定本發明的實施範圍。凡依本發明申請範圍所作的均等變化與改進等，均應仍歸屬於本發明的專利涵蓋範圍之內。