本發(fā)明一般地涉及銀行卡交易技術領域，并且具體地，涉及銀行卡交易的異常清算處理方法和系統(tǒng)。

背景技術：

在銀行卡交易過程中，通常由卡組織負責銀行卡交易參與各方的信息轉接?？ńM織按照既定的規(guī)則及費用價格對參與交易的各方進行資金（包括本金和各類手續(xù)費、分潤費用）的清分清算。清分清算的要素來自于各參與方上送或傳輸?shù)膱笪男畔⒂?。隨著交易業(yè)務場景的日趨多樣化和復雜化，機構在交易中錯誤上送商戶類型、特殊計費標識、渠道、卡等級、分潤算法等影響計費結果的信息域的情況越來越普遍。這類錯誤的處理周期往往較長，影響交易各方的合理權益。

為糾正錯誤，收單機構作為交易受理方，通常需同時聯(lián)系多個發(fā)卡機構以追回損失，而發(fā)卡機構每年也會接到眾多收單機構聯(lián)系退款的事宜。目前，所有這些退款操作均需手工處理，工作量巨大，并且處置不便。發(fā)卡機構往往還缺乏核實交易信息真實性的現(xiàn)實條件，并且部分機構不愿意退還手續(xù)費。對于收單機構而言，也面臨溝通成本高、追回全部損失的可能性小之類的問題。這類因機構原因導致的異常清算一定程度上影響了參與各方開展銀行卡創(chuàng)新業(yè)務的積極性，尤其可能對于卡組織推出的創(chuàng)新支付業(yè)務心存顧慮。

因此，所期望的是設計一種可靠的異常清算方案，以幫助參與交易的各方維護其正當權益并且優(yōu)化交易流程。

技術實現(xiàn)要素：

有鑒于此，本發(fā)明提供一種異常清算處理方法和系統(tǒng)，可改善上述問題。一方面，本發(fā)明提供了一種異常清算處理方法，其包括：接收交易異常清算數(shù)據(jù)，所述交易異常清算數(shù)據(jù)包括正確的交易清算信息；從所述交易異常清算數(shù)據(jù)中提取交易識別信息；依據(jù)交易識別信息從交易歷史庫中收集已清算交易數(shù)據(jù)；將所述交易異常清算數(shù)據(jù)與所述以清算交易數(shù)據(jù)比較以確定待糾正交易；以及根據(jù)所述正確的交易清算信息對所述待糾正交易進行重新清算。

在如上所述的方法中，交易識別信息包括商戶代碼及交易日期，并且收集已清算交易數(shù)據(jù)包括：按商戶代碼和交易日期從交易歷史庫中提取已清算交易數(shù)據(jù)；按交易日期分別將已清算交易數(shù)據(jù)和交易異常清算數(shù)據(jù)進行結構化分塊存儲；在相同交易日期的已清算交易數(shù)據(jù)塊和交易異常清算數(shù)據(jù)塊中按交易要素進行匹配以確定待糾正交易。

在如上所述的方法中，交易要素包括傳輸時間、系統(tǒng)跟蹤號、受理機構代碼、發(fā)送機構代碼中的一個或多個。

如上所述的方法還可以包括用所述正確的交易清算信息替換所述待糾正交易先前的清算明細。

如上所述的方法還可以包括將重新清算的結果與先前清算的結果進行軋差；依據(jù)軋差結果確定與交易關聯(lián)的各方的費用明細；以及將費用明細形成所述各方的收付費交易。

如上所述的方法還可以包括將所述費用明細生成明細文件以及將所述明細文件發(fā)送至所述各方。

如上所述的方法還可以包括在收到交易異常清算數(shù)據(jù)之后對所述正確的交易清算信息進行審核。

如上所述的方法還可以包括在收到交易異常清算數(shù)據(jù)之后檢查所述交易異常清算數(shù)據(jù)的文件格式的規(guī)范性。

在如上所述的方法中，交易異常清算數(shù)據(jù)采用文本文件格式。

另一方面，本發(fā)明還提供了一種異常清算處理系統(tǒng)，其包括：數(shù)據(jù)接收裝置，用于接收交易異常清算數(shù)據(jù)，其中所述交易異常清算數(shù)據(jù)包括正確的交易清算信息；信息提取裝置，用于從交易異常清算數(shù)據(jù)中提取交易識別信息；數(shù)據(jù)收集裝置，用于依據(jù)交易識別信息從交易歷史庫中收集已清算交易數(shù)據(jù)；比較裝置，用于將所述交易異常清算數(shù)據(jù)與所述以清算交易數(shù)據(jù)比較以確定待糾正交易；以及清算處置裝置，用于根據(jù)所述正確的交易清算信息對所述待糾正交易進行重新清算。

附圖說明

本發(fā)明的前述和其他目標、特征和優(yōu)點根據(jù)下面對本發(fā)明的實施例的更具體的說明將是顯而易見的，這些實施例在附圖中被示意。

圖1 是根據(jù)本發(fā)明一個示例的異常清算處理的示意應用場景。

圖2是根據(jù)本發(fā)明一個示例的異常清算處理方法的示意流程圖。

圖3是根據(jù)本發(fā)明一個示例的異常清算處理方法的示意流程圖。

圖4是根據(jù)本發(fā)明一個示例的異常清算處理系統(tǒng)的示意框圖。

具體實施方式

現(xiàn)在參照附圖描述本發(fā)明的示意性示例，相同的附圖標號表示相同的元件。下文描述的各示例有助于本領域技術人員透徹理解本發(fā)明，且各示例意在示例而非限制。圖中各元件、部件、模塊、裝置及設備本體的圖示僅示意性表明存在這些元件、部件、模塊、裝置及設備本體同時亦表明它們之間的相對關系，但并不用以限定它們的具體形狀；流程圖中各步驟的關系也不以所給出的順序為限，可根據(jù)實際應用進行調整但不脫離本申請的保護范圍。

圖1 是根據(jù)本發(fā)明一個示例的異常清算處理的示意應用場景。如前所述，本發(fā)明可以適用于銀行卡交易過程中，機構上送交易報文域信息錯誤，從而導致卡組織計費錯誤的情況。根據(jù)本發(fā)明的異常清算處理能夠實現(xiàn)在卡組織的平臺上，由此對交易的計費各參與方進行統(tǒng)一的異常清算，包括異常計費處置、資金劃付、流水文件對賬等。圖1所示的付差方機構可以是交易的收單機構或者發(fā)卡機構，其可能發(fā)現(xiàn)錯誤上送交易清算的關鍵信息，并且多支付了費用，因此希望能夠糾正清算結果。相應地，收差方機構可以交易的另外關聯(lián)方，其可能由于交易清算信息的錯誤上送而多收取了費用。根據(jù)不同的支付方式，每個交易可能有不同數(shù)量的關聯(lián)方。在本文中將涉及異常清算的各方按照其費用情況劃分為付差方機構和收差方機構。

圖2是根據(jù)本發(fā)明一個示例的異常清算處理方法的示意流程圖。將結合圖1所示的應用場景來解釋本發(fā)明的方法，然而本領域技術人員能夠理解這并非是限制性的。

首先，在步驟21中，卡組織的處理平臺可以從付差方機構或收差方機構接收交易異常清算數(shù)據(jù)，該交易異常清算數(shù)據(jù)通常需要包括正確的交易清算信息。付差方機構可以針對信息錯誤的交易向卡組織的處理平臺發(fā)送異常清算申請，在該申請中包含正確的交易清算數(shù)據(jù)。同時，在付差方機構提出的申請中還應包含能夠對待校正的交易進行識別的信息，即識別具體交易的關鍵要素。舉例來說，付差方機構可以在異常清算申請中包括交易傳輸時間、系統(tǒng)跟蹤號、受理機構代碼、發(fā)送機構代碼等交易要素信息。此外，付差方機構還可以上送例如清算日期、卡號、接收機構代碼、發(fā)卡機構代碼、交易金額、商戶代碼、錯誤上送信息域（如商戶類型、特殊計費類型檔次、渠道、卡等級等）、應正確上送的信息域等等。

在一些實現(xiàn)中，可以要求付差方機構以文本文件格式向卡組織的處理平臺提交包含正確清算信息的異常清算申請，例如通過卡組織的機構服務頁面提交。

在一些實現(xiàn)中，在對交易異常清算數(shù)據(jù)進行處理之前，還可以在卡組織的處理平臺上首先對付差方機構上送的文件格式的規(guī)范性進行審查。此外，還可以對交易的合規(guī)性進行檢查，例如對交易異常清算數(shù)據(jù)中所包含的正確交易清算信息進行審核，例如商戶類型（MCC）、特殊計費類型檔次等信息是否符合要求等。在審核通過之后可認為機構提交的正確交易清算信息生效，并在此基礎上進行異常清算處置。

在步驟23中，卡組織的處理平臺可以從所收到的交易異常清算數(shù)據(jù)中提取交易識別信息。舉例來說，交易識別信息可以是商戶代碼、交易日期、交易傳輸時間、系統(tǒng)跟蹤號、受理機構代碼、發(fā)送機構代碼等等。

在步驟25中，卡組織的處理平臺將依據(jù)所提取的交易識別信息從交易歷史庫中收集已清算交易數(shù)據(jù)。該已清算交易數(shù)據(jù)可包括針對交易識別信息所指示的交易在先前所有已成功清算的交易明細。為此，卡組織的處理平臺也可以首先將所有申請機構的交易進行裝載（例如裝載到內存），并從中抽取先前的交易清分明細信息。

在步驟27中，卡組織的處理平臺將所收到的交易異常清算數(shù)據(jù)與從交易歷史庫中提取的已清算交易數(shù)據(jù)進行比對來確定待糾正交易。將在下文中結合圖2的示例來進行具體說明。然而，本領域技術人員能夠理解，可以采用任何比對方法，只要能夠從歷史交易數(shù)據(jù)中找到與需要糾正的清算結果相關的交易信息。

在步驟29中，可以根據(jù)在所收到的異常清算數(shù)據(jù)中所包含的、正確的交易清算信息來對待糾正交易進行重新清算。具體地，可以例如按照標準的清算流程逐比交易進行重新清算，獲得各方的手續(xù)費及分潤費用等信息。

在一些實現(xiàn)中，還可以進一步將重新清算的結果與先前清算的結果進行軋差、依據(jù)軋差結果確定與交易關聯(lián)的各方的費用明細、以及將費用明細形成所述各方的收付費交易。在這個過程中，可以形成單筆交易各類費用明細結果，最后按照機構代碼對各類費用明細進行匯總軋差，形成各方借記、貸記最終費用結果。該費用結果可以被形成為對付差方機構和收差方機構的收付費交易，或生成大額支付文件，從而要求各方完成最終的資金劃付。

在一些實現(xiàn)中，卡組織的處理平臺還可以根據(jù)每筆交易費用的明細情況生成明細文件，通過文件系統(tǒng)下發(fā)至各付差方和收差方機構，以供對賬處理。

在一些實現(xiàn)中，卡組織的處理平臺還可以用正確的交易清算信息替換交易歷史庫中先前的清算明細，并就此進行標記。

通過采用本方法所提供的方法，可以通過由卡組織統(tǒng)一受理、集中批量處理、對資金進行統(tǒng)一劃付、提供固定格式對賬流水的方式來有效解決日常銀行卡交易中，因為錯誤上送關鍵信息域導致交易各參與方分潤計費錯誤的現(xiàn)象。通過采用本發(fā)明所提供的方法可最大化地解決銀行卡交易參與方因為此類錯誤導致的損失，解決了交易各參與方自行溝通的高昂成本，保護了銀行卡交易過程中各參與方的合理權益，也有助于提升卡組織的權威性，增強交易參與方對卡組織的粘性，有利于銀行卡相關創(chuàng)新業(yè)務的開展。

圖3是根據(jù)本發(fā)明一個示例的異常清算處理方法的示意流程圖。在結合圖3的這個示例中，依然示例而非限制地結合圖1所示的應用場景進行說明。下文為結合圖3對如圖2所示方法200中的步驟23、25以及27的一種示例性實現(xiàn)進行詳細描述。

在該示例中，可以將商戶代碼和交易日期作為上述步驟23中的交易識別信息。由此，為收集已清算交易數(shù)據(jù)，可以首先在步驟31中按商戶代碼和交易日期從交易歷史庫中提取已清算交易數(shù)據(jù)。在一些實現(xiàn)中，卡組織處理平臺可以將交易歷史庫中的歷史清算信息全部裝載入內存，并按照商戶代碼和交易日期從中抽取相關的所有已成功清算的交易明細。

在步驟33中，可以按交易日期將已清算交易數(shù)據(jù)和交易異常清算數(shù)據(jù)分別進行結構化分塊存儲。

在步驟35中，在相同交易日期的已清算交易數(shù)據(jù)塊和交易異常清算數(shù)據(jù)塊中按交易要素進行匹配以確定待糾正交易。具體地，可以在數(shù)據(jù)塊之間首先根據(jù)交易日期進行勾兌匹配。如果匹配成功則進入下一輪處理，而勾兌失敗則對該交易日期塊中的所有交易清分明細予以丟棄刪除。這可以包括當數(shù)據(jù)在內存中被處理時，將交易異常清算數(shù)據(jù)塊和已清算交易數(shù)據(jù)塊兩者都刪除。在交易日期匹配成功的情況下，對同一交易日期的兩個數(shù)據(jù)塊按交易要素進行主鍵勾兌匹配，保留勾兌匹配成功的交易明細，并將其確定為待糾正交易。交易要素可以包括傳輸時間、系統(tǒng)跟蹤號、受理機構代碼、發(fā)送機構代碼中的一個或多個，并且勾兌匹配可以是逐個按交易要素遞歸地進行匹配。

在一些實現(xiàn)中，對于已成功勾兌匹配完成的交易日期塊，則可更新覆蓋到原有交易日期的交易清分明細集合中，即按照異常清算交易要素中正確的商戶類型、特殊計費類型檔次、渠道、卡等級等信息，修改內存中的交易明細，以供后續(xù)重新清算。

在有大量交易需要進行重新清算的情況下，可以按上述方法循環(huán)對所有交易日期進行分塊勾兌匹配處理，直至完成整個交易清分明細集合的更新。

由于銀行卡交易數(shù)量巨大，交易歷史數(shù)據(jù)庫中通常存儲了每日近億筆，按年度數(shù)百億筆交易清分明細數(shù)據(jù)。按照圖3所示的方法，以商戶為單位、在交易時間段內一次性讀取清算明細，并按交易日期數(shù)據(jù)分塊之后進行遞歸式勾兌，這樣大大減少了對數(shù)據(jù)庫的頻繁訪問所帶來的數(shù)據(jù)庫日志開銷、IO開銷等性能問題。

圖4是根據(jù)本發(fā)明一個示例的異常清算處理系統(tǒng)的示意框圖。如圖4所示，異常清算處理系統(tǒng)400包括數(shù)據(jù)接收裝置41、信息提取裝置43、數(shù)據(jù)收集裝置45、比較裝置47以及清算處置裝置49。數(shù)據(jù)接收裝置41可用于接收交易異常清算數(shù)據(jù)，其中交易異常清算數(shù)據(jù)包括正確的交易清算信息。信息提取裝置43可用于從交易異常清算數(shù)據(jù)中提取交易識別信息。數(shù)據(jù)收集裝置45可用于依據(jù)交易識別信息從交易歷史庫中收集已清算交易數(shù)據(jù)。比較裝置47可用于將所述交易異常清算數(shù)據(jù)與所述以清算交易數(shù)據(jù)比較以確定待糾正交易。清算處置裝置49可用于根據(jù)所述正確的交易清算信息對所述待糾正交易進行重新清算。本領域技術人員能夠理解異常清算處理系統(tǒng)400能夠以各種硬件的方式來實現(xiàn)，并且其中模塊的劃分也并非是限制性的。

應當說明的是，以上具體實施方式僅用以說明本發(fā)明的技術方案而非對其進行限制。盡管參照上述具體實施方式對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解，依然可以對本發(fā)明的具體實施方式進行修改或對部分技術特征進行等同替換而不脫離本發(fā)明的實質，其均涵蓋在本發(fā)明請求保護的范圍中。