電子銀行系統的製作方法
2023-10-17 22:22:49 1
專利名稱：電子銀行系統的製作方法
技術領域：
一般來說，本發明涉及銀行業，更具體來說，涉及用於促進銀行交易的處理的電子銀行系統。
背景技術：
用於將銀行或交易票據(例如資金轉帳、付款處理以及對帳單和報表請求)從客戶過帳給銀行機構的現行系統一般依靠過時的人工方法，這些方法費時、低效而且易於出錯和丟失。這類系統往往依靠基於紙張的方法，它們涉及對紙單證的人工幹預和物理傳遞，其中每一項都造成緩慢的處理速度和過度的延時。銀行交易的各方往往必須等待相當長的時間讓銀行完成一項具體交易。對於每天進行大量本地和國際銀行交易的較大機構，現行系統的低效變得更為明顯。
例如，在供應商與大客戶之間的典型付款交易中，供應商準備及提交要遞交給客戶的發票。客戶接收發票，並將它轉交給發起與供應商的交易的相應發起部門。發起部門審查及核准發票以便付款。已核准的發票則轉到應付帳目中，在這裡準備支票。由於該系統是基於紙張的過程，因此它極大地依靠內部郵件通信聯繫，並且可能耗費大約四周來完成。支票轉交給適當的管理人員進行確認和籤名。然後把支票遞交給供應商。收到支票的供應商隨後將它呈送給銀行以便付款。交易的這個最後部分需要進一步的處理時間(即，從一小時到三天)，要求人工幹預和零售銀行業務系統來完成交易。雖然客戶可能定期或實時地經由電子方式(例如網際網路)收到銀行對帳單，但由於低效的支票兌付及票據交換過程，使得可能需要二十至三十天使上月的發票與付款一致。如果支票在此過程中丟失，則重複此過程。
因此，需要提供一種電子銀行系統，它可自動處理客戶發出的銀行票據，以便自動處理現金業務(monetary transaction)，例如向銀行帳戶或受益人(即收款人)進行電子支付或者帳戶之間轉帳，其中具有最小延時或人工幹預，同時利用現有的硬體、軟體和通信組件。還需要一種電子銀行系統，它提供對其中涉及多家銀行的帳戶的未償債務的準確實時評估，從而縮短協調帳戶所需的時間。
發明內容
本發明涉及一種電子銀行系統，它可用來提供銀行與客戶之間的有效自動接口，其中，客戶可從其場所或設備以電子方式向系統的多個會員銀行中的一個發出銀行票據，從而發起對所請求的現金業務的自動處理。本發明的電子銀行系統可方便地適合與現有硬體、軟體及通信組件配合使用。該電子銀行系統通過全球計算機網絡還在工作上與大量專有零售銀行業務系統兼容。在本發明的一個具體實施例中，提供一種電子銀行系統，用於通過本地或全球計算機網絡(如網際網路)以最小延時和人工幹預來自動處理包括向適當貨幣帳戶進行資金轉帳的現金業務。
在本發明的一個方面，提供一種電子銀行系統，包括主辦銀行伺服器，適合接收交易請求以及處理交易請求；用於在自動操作中發起交易請求的裝置；主辦銀行伺服器與發起裝置之間的數據通信中的全球計算機網絡，用於將交易請求從發起裝置傳送給主辦銀行伺服器；以及用於將發起裝置與主辦銀行伺服器接口以及用於把交易請求轉換成與主辦銀行伺服器兼容的可讀形式並建立它們之間的安全數據通信連接的裝置。
附圖簡介以下參照附圖詳細描述本發明的各種實施例，其中相似的項目由相同的參考標號標識，附圖包括
圖1A是示意圖，說明一種支付過程，作為由根據本發明的一種電子銀行系統的實現促進的應用之一；圖1B是根據本發明的一個實施例的電子銀行系統的示意圖；圖2是本發明的一個實施例的電子銀行系統的整體結構的示意圖；圖3A至3F共同表示流程圖，詳細說明本發明的一個實施例的支付模式中的電子銀行系統的操作步驟；圖4是流程圖，詳細說明本發明的另一個實施例的對帳單及核對模式中的電子銀行系統的操作步驟；以及圖5是流程圖，詳細說明本發明的又一個實施例的對帳單顯示模式中的電子銀行系統的操作步驟。
發明詳細說明本發明針對處理現金業務的電子銀行系統及方法。在一種操作模式中，本發明的電子銀行系統適合自動處理現金業務以及以快速方式、以最小人工幹預向金融帳戶進行適當的資金轉帳(即付款)。例如，本發明的電子銀行系統還適合利用例如網際網路等全球計算機網絡以及現有硬體和軟體組件。本發明可方便地與包括但不限於銀行、支付處理中心、金融票據交換所等現金數據處理實體合作實現。
本發明的自動特徵為例如具有大量本地和國際現金業務的大機構等用戶提供以同步方式與銀行系統辦理業務的能力。這改進了處理時間，以及使用戶能夠以快速實時方式、以最少人工幹預使其支付系統與銀行系統的帳目記錄自動協調。
該系統的主要終端用戶包括財政部(treasury)用戶，他們訪問該系統以便在實施處理之前確保交易的核准。財政部用戶通常是在大機構中負責管理機構的全球不動產和金融資產、債務以及與收益、投資、債務、外匯、貸款及保險相關的風險的小組成員。因此，本發明的系統提供一種有用的工具，用於使財政部用戶能夠以集中且自動的方式維護和管理機構的日常財務經營。
在本發明的一個實施例中，電子銀行系統包括三個主要組件核心交易處理組件，用於生成和發起現金業務；核心接口組件，用於經由網際網路與銀行伺服器通信；以及銀行接口組件，它們共同配合組成與核心接口組件的通信鏈路，同時鑑權、驗證、辦理及確認本系統的交易。
本發明在其各種實施例中可提供以下功能1.向第三方進行電子資金轉帳；2.相同銀行的共同帳戶之間的電子資金轉帳；3.不同銀行的共同帳戶之間的電子資金轉帳；4.一般類型付款；5.自動日終電子銀行對帳單檢索及核對；6.對第三方生成傳真付款通知；7.對接收銀行生成傳真預期付款通知(銷售應收收入)；8.為本發明的系統提供備份的自動電報功能性；9.生成現金狀況報告以表明客戶的財務負債；以及10.通過本發明的系統直接集成、在任何會員銀行聯機檢索帳戶餘額。
參照圖1A，說明支付過程220，它表示本發明所促進的若干應用其中之一。支付過程220以步驟222開始，在其中，受益人或收款人準備並提交付款發票給客戶230、如個人、公司或大機構。假定客戶230是包括採購和財務部門的足夠大實體，在步驟224，發票傳送給客戶負責審查發票並將它送往適當部門進行進一步處理和核准的接收部門(如採購部門)。接收部門把發票信息輸入工商企業或工作流程軟體系統，在其中它被傳送到適當各方進行處理。採用電子工作流程核准過程對發票信息進行檢驗、以電子方式捕捉以及對付款進行核准，該過程在應付帳部門與發起此工作的發起部門之間協調。在步驟226，發票傳送給發起部門供其審查和核准。在步驟228，發票核准轉交給應付帳，在其中以電子支付指令的形式準備電子支付。步驟224至228通常經由工作流程核准過程在客戶230的內部實現。在步驟232，客戶230經由計算機網絡將電子支付指令轉發給銀行。銀行232則繼續處理此信息，並按照客戶230的請求進行付款。同時，在步驟234，當支付指令發送到銀行232時，傳真通知被轉發給受益人222，確認現金業務請求已經轉發到銀行。現金業務可通過多種方式中任一種進行，例如通過從客戶的帳戶向受益人的銀行帳戶進行電子劃款，或者通過向受益人發送支票。
參照圖1B，表示根據本發明的一個實施例的電子銀行系統，總體上由參考標號10表示。系統10包括串行連接的以下各項核心交易組件12，可能是銀行系統的客戶操作的計算機伺服器；與核心交易組件12通信的核心接口組件14，它在某些應用中可由提供核心交易組件12的同一個計算機伺服器支持或者由不同計算機伺服器支持；全球計算機網絡16(例如網際網路)；以及銀行接口組件18，由客戶的銀行操作的銀行伺服器20支持。銀行接口組件18經由全球計算機網絡16與核心接口組件14進行通信。系統10還可以可選地包括受益人伺服器22，它連接到全球計算機網絡16，用於與客戶進行通信。核心交易組件12以及核心接口組件14安裝在客戶的設備上。
核心交易組件12構成客戶可訪問的內聯網系統的一部分，可採用從機構用於支持和促進無紙化環境中配合工作的任何標準商業軟體中選擇的基於企業的軟體來編程。這些軟體可包括但不限於可向德國SAP AG購買的SAPR/3Enterprise ERP。雖然本發明的電子銀行系統表示及描述為採用SAP軟體及應用模塊來編程，但本發明不限於這類軟體程序，而是可通過替換本領域已知的其它軟體來修改。
一旦現金管理事務經過用戶或客戶的指定核准官員的審查和核准，則核心交易組件12編程為自動產生電子交易票據或付款指令，這是自動處理的而沒有其它人工幹預。所產生的交易票據經由數據通信鏈路24轉發給核心接口組件14。核心接口組件14準備交易票據，用於(經由數據通信鏈路26)通過全球計算機網絡16傳送給適當的銀行伺服器20。核心接口組件14通過全球計算機網絡16實現核心交易組件12與相應銀行伺服器20之間的通信。交易票據通過全球計算機網絡16傳送以及由銀行接口組件18接收，銀行接口組件18可能是例如專用計算機或者提供銀行伺服器20的計算機伺服器的一部分，並編程為鑑權、驗證、辦理及確認交易票據內包含的交易。銀行接口組件18配置成與銀行伺服器20的特定零售銀行業務系統配合工作。銀行接口組件18將交易票據製作成銀行伺服器20的零售銀行業務系統特定的形式。一旦銀行伺服器20接收到交易票據，即執行包含在交易票據中的指令。
參照圖2，針對本發明的一個實施例更詳細地說明系統10。系統10包括內聯網區域13、接口區域15、防火牆區域17以及全球計算機網絡區域19。內聯網區域13一般包括專用本地伺服器21，採用企業商業軟體系統編程，例如採用SAPR/3，它是一種綜合可定製的核心軟體系統，設計用於支持應用模塊、例如作為SAP財務會計模塊(SAP Fi)的子集的SAP財政部模塊(SAP-TR)。除其它功能外，本地伺服器21還執行本發明的核心交易組件12的操作。本地伺服器21經由通信鏈路23與至少一個工作站或客戶計算機32進行通信，以便允許接入授權用戶、如客戶的指定人員。客戶機或客戶計算機32支持圖形用戶界面(GUI)軟體、例如SAPGUI軟體版本4.6D。
內聯網區域13還包括連接到本地伺服器21的核心交易資料庫存儲器34，用於為本地伺服器21所處理的數據提供存儲及檢索裝置。核心交易資料庫存儲器34裝有適當的資料庫軟體、例如Oracle5.7.3。
接口區域15包括接口伺服器25(提供核心接口組件14的功能)，它經由本地伺服器21與接口伺服器25之間建立的通信鏈路24和防火牆38連接到本地伺服器21。防火牆38用於將客戶的內聯網區域與接口區域隔離。它的主要功能是保證對接口區域和伺服器的數據業務由相應的系統和用戶進行授權訪問。接口伺服器25採用開放式接口軟體來編程，用於通過核心交易組件12與銀行伺服器20之間的全球計算機網絡16、本例中為網際網路來實現通信。在本發明的優選實施例中，開放式接口軟體由SAPBusiness Connector開發，如以下描述的流程圖所述。實現SAPBusiness Connector的接口伺服器25通過遠程功能調用(RFC)與實現SAPR/3系統的本地伺服器21進行通信。接口伺服器25將來自本地伺服器21上的核心交易組件12的所有RFC格式的通信轉換為可擴展標記語言(XML)。在本實施例中，超文本傳輸協議(HTTP/HTTPS)格式用於通過全球計算機網絡16的通信。分別經由包括一對防火牆40和42的防火牆區域17將接口區域15保持與全球計算機網絡16分隔開。接口伺服器25經由分別通過防火牆40和42的通信鏈路26電連接到全球計算機網絡16。從接口伺服器25傳送的數據通過全球計算機網絡16、經由通信鏈路28傳遞給銀行伺服器20。
核心接口組件14還包括連接到接口伺服器25的核心接口資料庫存儲器36。核心接口資料庫36類似於核心交易資料庫存儲器34，適合為與核心接口組件14關聯的所有操作提供存儲及檢索裝置。核心接口資料庫存儲器36最好是建立在防火牆38之後，與內聯網計算機區域13同側，如圖2所示。
在本發明中，核心交易組件12對客戶的銀行處的適當銀行伺服器20產生現金業務票據以便進行現金業務，例如進行付款或者管理客戶的銀行帳戶中的現金。每個現金業務票據由在本例中屬於核心交易組件12的SAPR/3Fi-TR模塊產生。交易票據以中間文檔(IDOC)的形式製作。IDOC被轉發給接口伺服器25，在其中它們被轉換成XML，然後再轉發給客戶的銀行處的預先指定的銀行伺服器20。預先指定的銀行伺服器20接收XML，以及銀行接口組件18將XML文檔重新格式化為適合由銀行伺服器20處理的格式。
參照圖3A，表示一個流程圖，說明根據本發明的原理的系統10的支付模式。本例中，在發起付款時，核心交易組件12通過運行支付程序(即SAP中的交易F110和F111)自動選擇付款交易(例如供應商發票和員工工資)。系統10的算法在步驟50中以從核心交易資料庫34中檢索用於由支付程序準備付款建議或交易票據的參數開始。用於付款建議的參數的實例可包括典型的付款交易參數，例如過帳日期(即，應付款項已經核准支付的日期)、下一付款擠兌日期(即，用來評定應付款項到期日的下一付款擠兌的過帳數據)、公司代碼(即，要共同處理的公司代碼或公司代碼間隔的列表)、支付方法(例如，支票、匯票和銀行國外轉帳)以及供應商/客戶帳戶(即，要考慮的供應商/客戶帳戶的範圍)。
在步驟52，核心交易組件12產生交易建議，允許用戶查看所有輸出的交易票據，其中包括核心交易組件12將處理的付款。這允許用戶在實際對付款交易進行過帳之前經由計算機32實現最初的覆核。算法進入步驟54，其中，支付程序由核心交易組件12執行，從而產生準備發布的支付憑證或票據。在步驟56，算法根據採用SAPR/3程序的相應支付方法確定包括參數的配置和選擇在內的支付憑證或票據的適當格式，例如「ZFR00440」用於USD(美元)支票支付，「RFFOEDI1」用於電子資金轉帳(EFT)支付，等等。
支付憑證以中間文檔(IDOC)的形式產生，並在步驟58發布到核心接口組件14。在一個實例中，對於EFT支付，支付程序產生兩種文檔「PAYEXT」IDOC和「EUPEXR」IDOC。每個PAYEXT IDOC包含每個銀行一個收款人的支付信息。EUPEXR IDOC是對於各銀行產生的參考IDOC，並包含對相應主辦銀行發布的具有PAYEXTIDOC編號列表的支付票據的所有匯總信息。例如，在SAPR/3中，IDOC經由遠程功能調用(RFC)目標埠遞交給核心接口組件14。在本例中，當IDOC在步驟60被遞交後，核心交易組件14立即將IDOC狀態更新為「03」，其中帶有表明數據已經正確傳遞到埠的消息「數據傳遞到埠成功」。
在步驟62，核心接口組件14所接收的IDOC被存儲和排列在RFC隊列中。EUPEXR IDOC被接收，以及匯總信息與PAYEXT IDOC編號一起作為在本文中稱為T_BC_支付_參考和T_BC_支付_參考_詳細資料的表被映射及存儲。
在步驟64，算法進行檢查，以確定到核心接口組件14的通信鏈路24是否是活動的。如果核心接口組件14的伺服器25關機或者是不活動的，則SAPR/3對RFC隊列中的所有IDOC排隊，直到伺服器再次開機。隊列經過配置，使得掛起的IDOC每分鐘再次被發送給RFC埠，直到傳送成功或者嘗試次數達到999次。對於每次傳送，重試次數在步驟66中加一。在步驟68，算法查詢嘗試次數是否大於999。如果查詢為「否」，則算法進入步驟70，在其中，IDOC被重新提交給RFC隊列。否則，算法進入步驟72，在其中，SAP監測人員被告知連接問題以便允許發起故障排除。在步驟74，監測人員解決連接問題，並進入步驟70進行重新提交。SAP監測人員一般由客戶的員工組成，並由客戶授權監測構成本發明的系統的組成部分的系統、伺服器、組件及過程，其中包括其硬體和軟體兩個方面。監測人員準備實施適當動作對操作過程中可能出現的任何異常情況進行校正或故障排除。
如果在步驟64確定連接是活動的，則算法進入圖3B的步驟76。
在圖3B的步驟76，核心接口組件14接收具有支付信息的PAYEXT IDOC，並將IDOC參數欄位映射為適當的變量。在步驟78，作為接口伺服器25的核心接口組件14編程為將IDOC以本文稱為T_BC_支付_交易的資料庫表的形式存儲在又稱作電子銀行DB(資料庫)的核心接口資料庫存儲器36中。隨後，在步驟80，本地伺服器21的核心接口組件12編程為通過採用對核心接口組件14(本例中為接口伺服器25)的SAPRFC調用，將本地伺服器25的核心交易組件12中的IDOC狀態更新為「06」，其中帶有消息「轉換成功」。
在步驟82，核心接口組件14將IDOC格式化為「MT100」指令(即客戶轉帳)，它符合環球銀行間通信協會實施的標準格式。然後，所產生的MT100指令在步驟84編譯成格式化為可擴展標記語言(XML)的交易文檔。這個操作通過對匹配經由參考IDOC(即EUREXR IDOC)接收的信息的所有IDOC編號從T_BC_支付_交易表中檢索所有支付指令來實現。執行這個過程以便根據主辦銀行編譯支付指令，用於以後作為單個文檔向相應主辦銀行伺服器20進行傳送和過帳。每個交易文檔的支付指令的最大數量取決於主辦銀行。各銀行的交易文檔的正確製作和傳遞的具體要求存儲在本文中稱作EBANKING.CNF配置文件的配置文件中。
格式化為SWIFT MT100(SWIFT代表「環球銀行間通信協會」)並環繞相應的XML標記的交易文檔等待傳送到主辦銀行伺服器20。在步驟86，從EBANKING.CNF配置文件中檢索銀行相關參數或要求。在步驟88，銀行相關參數被用來採用市場出售的特定散列算法來製備具有數字籤署證書的所有交易文檔。為了安全目的，證書用於在遞送之前鑑權或數字籤署文檔。主辦銀行伺服器20採用數字籤署證書來檢驗真實性以及確保交易文檔中包含的信息在傳送過程中沒有改變。算法採用EBANKING.CNF配置文件中包含的銀行相關參數創建XML交易文檔的數字籤名。
在步驟90，核心接口組件14建立到特定主辦銀行伺服器20的安全連接。這通過建立安全套接字層(SSL)會話來實現。交易文檔的數字籤署證書與根證書認證路徑一起用來發起該會話。算法在步驟92確定是否建立了成功連接。如果沒有建立連接，則算法進入步驟94。核心接口組件14將交易文檔與銀行相關參數一起以本文稱為T_BC_故障_服務的資料庫表形式存儲在核心接口資料庫存儲器36中。該表記錄所有故障，包括核心接口組件服務。在步驟96，算法發起交易文檔的遞送的自動重試。本例中，故障服務的重試大約每三分鐘進行一次。
算法進入查詢步驟98，以便確定重試次數是否大於三。持續無法建立連接電子郵件通知被發送給技術支持及業務小組以便進行適當的校正操作。為業務小組或財政部用戶準備具有交易代碼「ZF0642」、又稱作支付狀態工具的報告，以便查看核心交易組件12發布的所有支付指令的狀態。提供若干選項，其中，作為應急方法，業務小組可重試傳送或產生自動電報/傳真，以便將交易文檔傳遞給相應銀行。
向銀行發送支付指令的應急方案或備用選項可用於核心接口組件14或主辦銀行伺服器20無法處理支付指令的情況中。在這個應急方案中，包含支付指令的交易文檔配置成具有匯總報告的適當電報格式，讓核心交易組件12的用戶產生測試代碼。電報自動傳送到銀行。
如果在步驟98的查詢為「是」，則算法進入步驟100，在其中，通過採用對核心交易組件12的SAPRFC調用，將核心交易組件12中的IDOC狀態改變為「13」，其中帶有消息「付款過帳時出錯」。在步驟102，電子郵件消息被發送給核心交易組件12的授權用戶，以便經由傳統方式建立的電報傳送手動發布交易文檔。用戶執行交易ZF0642以便查看從核心交易組件12發布的支付指令的狀態，以及對具有狀態代碼「13」的所有支付產生電報報告。向用戶顯示電報報告，在其中，根據銀行提供的保密公式計算測試代碼。每家銀行採用不同的公式。對每個銀行製作單獨的報告，表明已失敗的所有支付。
在步驟104，授權用戶經由電報傳送向主辦銀行發布交易文檔，並完成操作。在成功傳送之後，用戶將IDOC狀態代碼更新為「12」，表明支付成功地由銀行確認。
如果步驟98的查詢為「否」，則算法進入步驟88，開始重新建立與主辦銀行伺服器20的安全連接。
一旦在步驟90建立了到主辦銀行伺服器20的安全連接，並且步驟92的查詢為「是」，則算法進入步驟105。在步驟105，核心接口組件14將包含支付指令和數字籤名的交易文檔通過全球計算機網絡16傳送到主辦銀行伺服器20的銀行接口組件18。客戶的銀行27採用本領域已知的其零售銀行業務系統著手執行付款交易。
在圖3C，算法進入步驟106，在其中，核心接口組件14等待來自本例中包含在伺服器20中的銀行接口組件18、其中包含過帳到銀行的支付指令的每個的響應狀態代碼及消息的格式化為XML的響應文檔。在步驟108，核心接口組件14接收來自銀行接口組件18的響應文檔。在銀行與客戶之間傳遞的所有XML文檔均記錄在本發明的系統中，並且一般分別標識為「文檔已發送」和「文檔已接收」。在步驟110，響應文檔的返回代碼和消息以本文稱為T_BC_文檔_已接收的表的形式存儲在核心接口資料庫存儲器36中用於審計目的。核心接口組件14在步驟112處理各支付指令的響應文檔中的狀態。算法進入步驟114，在其中，各支付指令的狀態由核心接口組件確定。
對於查詢步驟114中的返回代碼「成功」，算法進入步驟116，在其中，MT100格式化支付指令被確定為由主辦銀行成功接受。然後，核心接口組件14通過採用對核心交易組件12的SAPRFC調用，將核心交易組件12中的IDOC狀態更新為「12」，其中帶有消息「支付成功地由銀行確認」。列出成功支付的報告可採用交易「ZF0642」來產生，下面將會進行說明。
對於查詢步驟114中的返回代碼「DE」、「01」或「09」，算法進入步驟120，在其中，MT100格式化支付指令被確定為無效。支付指令包含數據合法性錯誤。該錯誤通常因核心交易組件12輸入的不正確的基本數據或配置文件信息而包含在商業數據中。算法進入步驟122，在其中，核心接口組件14將核心交易組件14中的IDOC狀態更新為代碼「11」，發信號通知銀行的支付接受因合法性而失敗。算法進入圖3D的步驟124。在步驟124，核心接口組件14向核心交易組件14的用戶發送電子郵件通知，其中具有來自銀行的適當錯誤消息。算法進入查詢步驟126，在其中，確定拒絕的有效性。如果查詢為「否」，則算法進入步驟128，在其中，核心交易組件12的用戶發起交易「ZF0646」、又稱作支付撤消工具，用於將IDOC狀態設置為「31」，以及發起「ZF0642」，用於實現支付狀態報告，以及支付指令經由電報傳送提交給銀行。在步驟130，從銀行接收電報確認作為證實，以及系統10的操作完成。
如果在查詢步驟126確定拒絕為有效，則算法進入步驟132，在其中，核心交易組件12的用戶發起交易ZF0646並撤消支付。在步驟134，用戶對產生錯誤的數據進行必要的校正。在步驟136，經校正的支付指令重新輸入核心交易組件12，在其中，算法重新進入圖3A的步驟50。
再參照圖3C，對於查詢步驟114中的返回代碼「失敗」，算法進入步驟138，在其中，主辦銀行伺服器20的服務或組件被確定為出故障。算法進入步驟140，在其中，返回代碼作為銀行側的技術故障被處理，以及核心接口組件14將核心交易組件14中的IDOC狀態更新為代碼「13」，其中帶有消息「傳遞支付指令時出錯」，發信號通知銀行的支付接受因技術問題而失敗。算法進入圖3E的步驟142。在步驟142，核心接口組件14向核心交易組件12的用戶發送電子郵件通知以及因技術性問題而使支付拒絕的原因。算法進入步驟144，在其中，核心交易組件12的用戶發起交易「ZF0642」用於支付報告，以及支付指令經由電報傳送提交給銀行。在步驟146，從銀行接收電報確認作為證實，以及系統10的操作完成。
再參照圖3C，對於查詢步驟114中的返回代碼「DUDE」或「DUOK」，算法分別進入步驟148或步驟150，在其中，支付指令被確定為重複。銀行對於隨DE錯誤而拒絕的支付而返回「DUDE」返回代碼。銀行伺服器20對於在前一次傳送中接受的支付而返回「DUOK」返回代碼。在步驟148或150其中任一個步驟，算法進入圖3F的步驟152。在查詢步驟152，核心接口組件14確定返回代碼是「DUDE」還是「DUOK」。如果返回代碼為「DUDE」，則算法進入步驟154，在其中，核心接口組件14檢查核心交易組件12中的支付指令的上一個IDOC狀態。在查詢步驟156，核心接口組件14確定狀態代碼是否為「11」或者支付被銀行拒絕。如果查詢為「否」，則算法進入圖3D的步驟124。如果查詢為「是」，則算法進入步驟158，在其中，核心接口組件14向技術人員發送電子郵件通知，用於進行為什麼再次傳遞支付的故障診斷，以及系統10的操作完成。
在查詢步驟152，如果返回代碼為「DUOK」，則算法進入步驟160，在其中，核心接口組件14檢查核心交易組件12中的支付指令的上一個IDOC狀態。在查詢步驟162，核心接口組件14確定狀態代碼是否為「12」或者支付成功地由銀行確認。如果查詢為「否」，則算法進入步驟164，在其中，核心接口組件14將核心交易組件14中的IDOC狀態更新為代碼「12」，其中帶有消息「支付成功地由銀行確認」。系統10的操作完成。
在查詢步驟162，如果結果為「是」，則算法進入步驟166，在其中，核心接口組件14向核心交易組件12的用戶和技術人員發送關於支付為重複的以及要採取校正操作的電子郵件通知。系統10的操作完成。
要注意，如果出現錯誤，傳送給主辦銀行伺服器20的支付指令不應當由銀行接口組件18自動修復。所有具有錯誤的支付指令被返回給核心接口組件14，其中具有詳細消息及返回代碼。
核心接口組件14可配置成採用交易「ZF0642」對於所有成功支付(即狀態代碼「12」)產生支付通知報告。
參照圖4，針對本發明的另一個操作模式和實施例示出詳細說明系統10的操作的流程圖。銀行對帳單通常在銀行營業時問之後每天檢索一次以及在商定時間檢索，用於自動核對。這個時間通常在第二天的早晨。從銀行接收的數據包含關於銀行對帳單中每項交易的性質的信息。例如，表明交易代碼，以便說明例如支票付款交易、電子支付、銀行轉帳或客戶收據。
相對每項的參考信息(例如支票編號、參考編號)也可包含在銀行對帳單中。根據銀行對帳單中包含的信息，存儲在核心交易組件12中的所有未決交易可在核對時自動清算。電子銀行對帳單被接收並由核心接口組件14轉換成核心交易組件12可識別的格式。
在步驟168，核心交易組件12發起對帳單請求，它被發送給核心接口組件14。在步驟170，核心接口組件14接收對帳單請求並將它轉換成XML文檔。在步驟172，核心接口組件14從EBANKING.CNG配置文件中檢索要求參數，以便通過全球計算機網絡16建立安全套接字層(SSL)會話。在步驟180中建立經由銀行接口組件18到主辦銀行伺服器20的安全連接。算法進行到查詢步驟182，以便確定是否成功建立連接。如果查詢為「否」，則算法進行到查詢步驟174，以便確定嘗試次數是否大於三。如果查詢為「否」，則算法回到步驟180。如果查詢步驟174中的查詢為「是」，則算法進行到步驟176，在其中，核心接口組件14向核心交易組件12的用戶和技術人員發送電子郵件通知，告知他們連接問題。在步驟178，核心接口組件14向核心交易組件12提出「故障」異常情況，以便手動重新發起對帳單請求。
如果建立了成功的連接，則算法進入步驟184，在其中，XML對帳單請求由接口伺服器25的核心接口組件14經由全球計算機網絡16傳遞給主辦銀行伺服器20。在步驟186，主辦銀行伺服器20將包含銀行對帳單的請求響應發送給相關銀行接口組件18，在其中對帳單、即MT940對帳單被轉換成XML，然後經由全球計算機網絡16轉發給核心接口組件14。在步驟188，核心接口組件14分別以本文稱作T_BC_文檔_已發送和T_BC_文檔_已接收的表的形式將對帳單請求和請求響應存儲在核心接口資料庫36中用於審計目的。在步驟190，根據SWIFT標準格式化成MT940的銀行對帳單從請求響應中提取，並存儲在核心交易組件12中。在步驟192，核心交易組件12導入銀行對帳單中包含的數據以便核對交易。系統10的操作完成。
參照圖5，針對本發明的另一個操作模式和另一個實施例示出詳細說明系統10的操作的流程圖。在本發明中，在本例中經由計算機32為用戶提供在線銀行對帳單訪問，用於直接從主辦銀行伺服器20實時查看對帳單。提供對帳單查看訪問只是用於查看目的而不用於調整。在步驟194，響應用戶請求，核心交易組件12通過又稱作在線對帳單報告工具的交易「ZF0640」發起對帳單請求，用於查看在線銀行對帳單。在步驟196，核心接口組件14接收對帳單請求並將該請求格式化為XML文檔。在步驟198，核心接口組件14檢索銀行相關要求，以便通過全球計算機網絡16建立與主辦銀行伺服器20的SSL連接。建立安全連接的嘗試在步驟200進行。在查詢步驟202，核心接口組件14確定是否已經建立安全連接。如果查詢為「否」，則算法進入步驟204，在其中，向請求用戶顯示與「ZF0640」功能對應的返回連接錯誤消息，以及系統10的操作完成。
如果查詢步驟202中的查詢為「是」，則算法進入步驟206，在其中，包含對帳單請求參數的對帳單請求被傳遞給銀行接口組件18。銀行接口組件18處理該對帳單請求，用於上傳給主辦銀行伺服器20。主辦銀行伺服器20以SWIFT MT940的格式產生銀行對帳單，送往銀行接口組件18。銀行接口組件18將銀行對帳單轉換成XML格式，並將它傳送給核心接口組件14。在步驟208，核心接口組件14接收銀行對帳單。在步驟210，核心接口組件14將來自銀行對帳單的MT940數據處理成結構化輸出，並將輸出上傳給核心交易組件12，用於向用戶顯示。
雖然以上已經詳細表示和描述了本發明的各種實施例，但它們不是意味著限制。本領域的技術人員可能知道對這些實施例的某些修改，這些修改打算由所附權利要求涵蓋。例如，雖然全球計算機網絡16、如網際網路表示為用於提供客戶的本地伺服器21與銀行的伺服器20之間的數據連接通路或鏈路，但網絡16也可以是用於在客戶及其銀行所在的大建築物內進行通信的區域網(LAN)、或者例如其中客戶及其銀行位於共同商業區的廣域網(WAN)。
權利要求
1.一種用於允許銀行客戶遠程授權和請求由其銀行進行計算機化現金業務的自動銀行系統的方法，所述方法包括以下步驟在客戶的場所提供計算機化系統；在客戶的系統上接收客戶手動輸入的對於客戶的銀行辦理現金業務的請求；響應請求，在客戶的系統上自動運行現金業務程序，用於產生正確格式化的現金業務文檔作為中間文檔(IDOC)；在客戶的系統中自動將所述IDOC在遠程功能調用(RFC)隊列中保持預定的時段，從而允許所述IDOC被傳遞到客戶的系統的電子銀行接口伺服器中以便進一步處理；將所述接口伺服器編程為自動將所述IDOC轉換成可擴展標記語言(XML)格式化文檔；自動通過計算機網絡將所述XML格式化IDOC從所述客戶的系統傳送到所述客戶的銀行中的兼容電子銀行伺服器；以及響應所述IDOC，經由所述銀行的所述伺服器自動處理所請求的現金業務。
2.如權利要求1所述的方法，其特徵在於，還包括以下步驟自動操作所述銀行的電子銀行伺服器向所述客戶發送XML格式化狀態文檔；在所述客戶的系統上自動接收所述狀態文檔；操作所述客戶的系統以允許所述客戶閱讀所述接收的狀態文檔；以及自動將所述接收的狀態文檔記錄到所述客戶的系統中的核心交易資料庫存儲器中。
3.如權利要求1所述的方法，其特徵在於，自動運行所述現金業務程序的所述步驟包括以下步驟輸入用於所述請求的現金業務的參數；創建現金業務建議；以及執行現金業務運行以產生所述IDOC。
4.如權利要求1所述的方法，其特徵在於，所述RFC隊列保持步驟包括以下步驟向所述客戶的銀行中的電子銀行伺服器的RFC目的地發布所述IDOC；將IDOC狀態更新為表明數據成功傳遞到埠的數位化代碼；使在所述埠接收的所述IDOC編制到RFC隊列中；以及檢查以確定到所述客戶的銀行中的所述伺服器的通信鏈路是活動的還是不活動的。
5.如權利要求4所述的方法，其特徵在於還包括以下步驟通過對重試計數器的數值加「1」，對所述銀行的所述接口伺服器為不活動的進行響應；確定重試次數是否大於預定最大數值；以及如果所述重試次數沒有超過所述最大數值，則向所述RFC隊列重新提交所述IDOC；以及重複所述檢查步驟。
6.如權利要求5所述的方法，其特徵在於還包括以下步驟通過通知故障排除人員在建立與銀行的所述接口伺服器之間的通信鏈路時的問題，對所述重試次數大於所述預定數值進行響應；響應連結問題已經解決的通信，向所述RFC隊列重新提交所述IDOC；以及重複所述檢查步驟。
7.如權利要求4所述的方法，其特徵在於還包括以下步驟通過將IDOC參數欄位映射到適當的變量，對活動的接口伺服器進行響應；將IDOC數據存儲在電子銀行DB(資料庫)中；更新所述IDOC狀態以表明可接受的轉換；將所述IDOC格式化為符合環球數據銀行通信協會實施的標準格式的指令；將所述格式化的IDOC以及後續格式化的IDOC均編譯成格式化為可擴展標記語言(XML)的交易文檔；從eBanking.CNF配置文件中檢索銀行相關參數；採用客戶證書為每個XML格式化文檔創建數字籤名；建立到所述客戶的銀行中的所述計算機伺服器的安全連接；確定是否成功建立了安全連接；以及通過經由計算機網絡將包含交易指令和數字籤名的每個交易文檔傳送給所述客戶的銀行中的所述計算機伺服器，對成功建立的安全連接進行響應。
8.如權利要求7所述的方法，其特徵在於還包括以下步驟通過將所述XML文檔與銀行相關參數一起記錄在標為「故障服務」的資料庫中，對建立安全連接的失敗進行響應；自動重試創建數字籤名、建立安全連接以及確定是否已經建立安全連接的這些相繼步驟；確定所述重試次數是否大於預定最大數值；以及如果所述重試次數不大於所述最大數值，則繼續進行所述自動重試步驟。
9.如權利要求8所述的方法，其特徵在於還包括以下步驟通過將所述IDOC狀態更新為表明付款過帳時錯誤的代碼，對所述重試次數超過所述最大數值進行響應；對於經由先前以傳統方式建立的電報或傳真傳輸發布付款，向客戶的授權職員發送電子郵件通知；響應所述電子郵件，所述授權職員經由電報或傳真向所述銀行發布或提供所述現金業務文檔；以及更新IDOC狀態代碼以表明所述現金業務成功完成已經由所述銀行確認。
10.如權利要求7所述的方法，其特徵在於還包括以下步驟等待來自所述銀行的所述計算機網絡上的響應；從所述銀行接收格式化成XML的響應文檔，其中包含傳遞給所述客戶的銀行的每個現金支付指令的響應狀態代碼和消息；在電子銀行資料庫中存儲所述響應文檔；為每個相關現金業務指令處理所述響應文檔中的狀態；以及確定來自各現金業務的銀行的狀態。
11.如權利要求10所述的方法，其特徵在於，確定各現金業務的狀態的步驟包括以下步驟為成功地由所述銀行處理的現金業務指明相當於「成功」的狀態代碼；以及將相關IDOC狀態更新為具有表明所述銀行已經通知了所述現金業務成功進行的代碼。
12.如權利要求10所述的方法，其特徵在於還包括以下步驟表明與導致所述銀行拒絕所述現金業務的數據錯誤對應的狀態代碼；以及將所述交易的所述IDOC狀態更新為表明因數據錯誤引起的交易拒絕的代碼。
13.如權利要求12所述的方法，其特徵在於還包括以下步驟向客戶的授權職員發送電子郵件通知，表明所述現金業務的拒絕的原因；通過所述授權職員的操作確定所述拒絕是否有效；通過所述授權職員的操作響應有效的拒絕，採用電子銀行交易請求以撤消所述現金業務請求；經由所述授權職員的操作校正導致所述銀行拒絕所述現金業務的所述數據；以及通過所述銀行系統重新處理所述已校正現金業務以便完成。
14.如權利要求13所述的方法，其特徵在於還包括以下步驟通過所述授權職員的操作響應無效的拒絕，採用適當的電子銀行交易代碼，用於經由測試電報傳輸向所述銀行發布所述現金業務；以及經由所述客戶的計算機系統接收來自所述銀行的證實所述現金業務完成的確認。
15.如權利要求10所述的方法，其特徵在於還包括以下步驟為銀行因未知原因無法完成所述現金業務表明與「失敗」對應的狀態代碼；以及響應所述「失敗」代碼而將IDOC狀態更新為表明失敗的現金業務的代碼。
16.如權利要求15所述的方法，其特徵在於還包括以下步驟經由電子郵件通知從所述銀行向所述授權職員發送所述銀行無法完成所述現金業務的原因；通過所述授權職員的操作，採用適當的電子銀行交易代碼，經由測試電報或傳真向所述銀行發布授權以完成所述現金業務；以及經由從所述銀行到所述客戶的電報或傳真接收完成所述現金業務的確認。
17.如權利要求10所述的方法，其特徵在於還包括以下步驟從所述銀行表明返回狀態代碼，它對應於因數據錯誤而被銀行拒絕的前一次傳輸的電子銀行的重複傳輸所用的「DUDE」，或者對應於銀行成功處理的前一次傳輸的電子銀行的重複傳輸所用的「DUOK」；經由所述客戶的計算機系統確定所述返回狀態代碼是對應於DUDE還是DUOK；響應DUDE的狀態代碼而確定所述現金業務的上一個IDOC狀態是否表明所述交易因數據錯誤而被銀行拒絕；響應因數據錯誤引起的拒絕，向技術人員發送電子郵件通知，用於對所述現金業務重複傳到銀行的原因進行故障排除；以及響應不是因數據錯誤引起的拒絕，向客戶的授權職員發送電子郵件通知，表明現金業務被銀行拒絕的原因。
18.如權利要求17所述的方法，其特徵在於還包括以下步驟響應「DUOK」的狀態代碼，確定所述現金業務的上一個IDOC狀態是否表明所述交易由銀行成功處理；響應所述緊靠前面的確定步驟中的「否」回答，將所述IDOC狀態改為表明成功處理的代碼；以及響應前一個相關確定步驟中的「是」回答，向客戶的授權職員以及客戶的技術人員發送電子郵件通知，用於表明所述現金業務在所述自動銀行系統中被重複。
19.如權利要求1所述的方法，其特徵在於還包括以下步驟採用調度程序通過所述客戶的操作發起對銀行對帳單的請求；將所述請求傳遞給客戶的所述接口伺服器，用於轉換為XML文檔；從電子銀行配置文件中檢索所要求的在所述計算機網絡上建立安全套接字層(SSL)會話所必需的參數；在所述計算機網絡上建立到所述銀行的電子銀行伺服器的安全連接；確定是否成功建立所述連接；響應不成功連接，確定重試次數是否大於所允許的最大數值；響應所述重試次數未超過所述最大數值，重複所述安全連接建立步驟；響應所述重試次數超過所述最大數值，向客戶的職員以及技術人員發送電子郵件，通知連接或對帳單檢索故障；以及向調度程序提出「失敗」異常情況，以便允許對所述對帳單的手動請求。
20.如權利要求19所述的方法，其特徵在於還包括以下步驟通過將包含對帳單請求參數的XML文檔傳遞給所述銀行的電子銀行伺服器，響應所述安全連接建立步驟中的成功連接；在來自所述銀行的XML格式化響應中檢索客戶的系統對帳單；將所述XML格式化請求以及響應都存儲在所述客戶的電子銀行資料庫中；從所述電子銀行資料庫中檢索所述對帳單，以便在指定文件夾中創建文件；以及通過使用標準化銀行商業軟體來核對所述對帳單。
21.如權利要求1所述的方法，其特徵在於還包括以下步驟通過所述客戶的操作，採用電子銀行交易代碼發起請求顯示已完成的現金業務的對帳單；經由客戶的所述接口伺服器，將所述請求轉換為XML格式化文檔；從電子銀行配置文件中檢索所要求的在所述計算機網絡上建立到所述銀行的電子銀行伺服器的安全連接所必需的參數；在所述計算機網絡上建立到所述銀行的電子銀行伺服器的安全連接；確定是否成功建立所述連接；以及通過返回向所述客戶顯示的連接錯誤消息，響應所述連接的不成功建立。
22.如權利要求21所述的方法，其特徵在於還包括以下步驟通過向所述銀行的所述電子銀行伺服器傳遞包含對帳單請求參數的XML文檔，響應所述連接的成功建立；在所述客戶的所述電子銀行接口伺服器上接收來自所述銀行的XML格式化對帳單的響應；以及提取所述對帳單，用於向所述客戶顯示。
23.一種用於發起和自動處理現金業務的自動電子銀行系統，所述系統包括發起裝置，用於允許銀行的遠程客戶有選擇地發起要自動處理的現金業務請求；銀行主伺服器，適合自動接收和處理所述現金業務請求；所述銀行主伺服器裝置與所述發起裝置之間數據通信的計算機網絡，用於將付款交易請求從所述客戶的發起裝置傳送給所述銀行主伺服器；以及接口裝置，位於所述發起裝置與所述計算機網絡之間，用於自動將所述發起裝置與所述銀行主伺服器接口，以及用於將所述現金業務請求轉換為與所述銀行主伺服器兼容的可讀形式。
24.如權利要求23所述的系統，其特徵在於還包括安全裝置，用於建立所述發起裝置與所述銀行主伺服器之間的數據的安全傳送。
25.如權利要求23所述的系統，其特徵在於還包括編程裝置，用於操作所述發起裝置、接口裝置以及銀行主伺服器來自動響應所述現金業務請求，從而所述銀行主伺服器完成所述現金業務，以及確保產生詳細說明完成付款交易中執行的每個必要跟蹤步驟的全部必要的電子記錄。
26.如權利要求23所述的系統，其特徵在於，所述發起裝置包括至少一臺計算機，用於允許客戶產生所述現金業務請求；客戶的本地計算機伺服器，連接在所述至少一臺計算機與所述接口裝置之間；以及核心交易資料庫存儲器，用於存儲用於操作所述本地計算機伺服器執行以下步驟的必要電腦程式通過製備中間文檔(IDOC)形式的現金業務票據以及各種相關支付參數的所有必要跟蹤記錄，響應客戶的現金業務請求。
27.如權利要求26所述的系統，其特徵在於，所述接口裝置包括客戶的接口計算機伺服器，連接在所述本地計算機伺服器與所述計算機網絡之間；以及核心接口資料庫存儲器，用於存儲操作所述接口計算機伺服器將通信從所述本地計算機伺服器轉換成所述通信網絡上的通信所用的格式所用的必要電腦程式，以及用於存儲所述IDOC、交易文檔、返回代碼以及涉及與所述銀行主伺服器裝置的交易的消息。
全文摘要
一種用於發起和自動處理現金業務的自動電子銀行系統包括發起裝置，用於保存交易記錄並允許銀行的遠程客戶有選擇地發起要自動處理的現金業務請求；銀行主伺服器，適合自動接收及處理現金業務請求；銀行主伺服器裝置與發起裝置之間數據通信的計算機網絡，用於將付款交易請求從客戶的發起裝置傳送給銀行主伺服器；以及接口裝置，位於發起裝置與計算機網絡之間，用於自動將發起裝置與銀行主伺服器接口，並用於將現金業務請求轉換成與銀行主伺服器兼容的可讀形式，其中客戶的發起裝置定期從銀行主伺服器的響應中接收確認數據，以便允許發起裝置每天自動核對交易記錄。本發明還針對一種用於允許銀行客戶遠程授權及請求由其銀行進行計算機化現金業務的自動電子銀行系統的方法。
文檔編號G06Q20/00GK1703706SQ03821811
公開日2005年11月30日 申請日期2003年9月16日 優先權日2002年9月16日
發明者A·M·阿爾－阿利 申請人:沙烏地阿拉伯石油公司