專利名稱：綜合支付集中器系統(tǒng)中管理支付處理的系統(tǒng)、方法和程序的制作方法
技術(shù)領(lǐng)域：
文中公開的實施例一般地涉及用于管理金融支付處理的系統(tǒng)、方法和計算機(jī)程序 產(chǎn)品，更具體地涉及在綜合支付集中器環(huán)境中動態(tài)選擇和安排支付處理。
背景技術(shù)：
目前，在美國市場，基于途徑的傳統(tǒng)產(chǎn)品之后是金融支付處理。這意味著在金融機(jī) 構(gòu)收到特定產(chǎn)品庫之前指定支付。庫支付處理發(fā)生在圖像捕獲之前并且包括一系列線性處 理步驟，其中接收的支付輸入形式在很多種情況下與支付匯款/結(jié)算相同。例如，如果支付 是電子輸入，那么產(chǎn)品庫在多種情況下電子輸出支付。因此，每種支付類型例如票據(jù)、圖像、 電子、電報、自動交換所(ACH)等都有其自己的產(chǎn)品庫和通道，因此在交易提交之前就選擇 庫。這些單獨的產(chǎn)品庫沒有被完全地集成，這樣它們就可以作為獨立的系統(tǒng)自治地操作。在 這方面，特定的產(chǎn)品庫需要特定的邏輯處理和處理硬件，基于該支付類型/產(chǎn)品設(shè)置庫以 適應(yīng)。國際支付系統(tǒng)稍微有些不同，因為這些支付被指定用于低價通道或者高價通道， 但是類似于美國支付處理，這些支付都是在傳送之前預(yù)處理的。在成本效率、支付時間性或者其它支付因素方面，國內(nèi)支付和國際支付都沒有考 慮客戶/支付者以及在一些情況中的支付處理金融機(jī)構(gòu)。例如，當(dāng)客戶不關(guān)心用什么途徑 進(jìn)行支付時，它們通常關(guān)心收款人收到支付的速度。在大部分情況中，客戶/支付者都希望 收款人能盡快收到支付，然而，在一些情況中，支付者希望延遲支付接受以確保在指定的支 付賬戶中有充足的資金。除了時間性方面，客戶/支付者可能關(guān)心支付交易的質(zhì)量或風(fēng)險， 即，確保支付在指定時間和目的地和/或以客戶/支付者支付花費(fèi)的成本進(jìn)行。從金融機(jī) 構(gòu)的立場看，金融機(jī)構(gòu)關(guān)心以最節(jié)省成本的方式進(jìn)行支付，從而可以最大化它們的利益，同 時在時間和支付風(fēng)險方面考慮客戶的需求。因此，需要開發(fā)系統(tǒng)、方法和計算機(jī)程序產(chǎn)品等來更有效和低成本地處理金融支 付。期望的系統(tǒng)、方法和計算機(jī)程序產(chǎn)品等應(yīng)當(dāng)允許在綜合支付處理系統(tǒng)中處理所有類型 的支付請求。另外，期望的系統(tǒng)、方法和計算機(jī)程序產(chǎn)品應(yīng)當(dāng)以高效方式處理支付請求，使 得對金融機(jī)構(gòu)和客戶(即，支付者和/或收款人)都節(jié)約成本。另外，期望的系統(tǒng)、方法和 計算機(jī)程序產(chǎn)品等應(yīng)當(dāng)允許客戶/支付者基于每個支付或每個支付文件或者預(yù)先定義的 支付排列(arrangement)或者動態(tài)定義支付排列，從而在支付時間性、支付成本、支付質(zhì)量 等方面滿足客戶/支付者的需求。另外，期望的系統(tǒng)、方法和計算機(jī)程序產(chǎn)品等應(yīng)當(dāng)允許金 融機(jī)構(gòu)作出支付途徑?jīng)Q定，其不但考慮了客戶的/支付者的需求和關(guān)切，還考慮了金融機(jī)構(gòu)對最小化與每個交易相關(guān)的成本的關(guān)切。而且，通過提供方法、系統(tǒng)和計算機(jī)程序產(chǎn)品等允許基于每個支付在預(yù)定的支付排列和/或動態(tài)排列支付中客戶/支付者有更多的選項， 金融機(jī)構(gòu)可以在支付處理中實現(xiàn)不同的價格點。

發(fā)明內(nèi)容
為了提供對本發(fā)明實施例的基本理解，下文中提供了一個或更多個實施例的簡要 概述。概述不是所有預(yù)期實施例的擴(kuò)展性綜述，其目的不是為了標(biāo)識所有實施例的關(guān)鍵或 重要元件也不是為了描述任意或所有實施例的范圍。唯一目的就是以簡化形式提供一個或 更多個實施例的概念作為后面將要詳述的序言。文中描述的方法、設(shè)備、系統(tǒng)和計算機(jī)程序產(chǎn)品用于管理支付處理，尤其是在綜合 支付集中器環(huán)境中管理支付處理，其提供了不受支付輸入通道影響的支付處理。根據(jù)本發(fā) 明公開的實施例，管理支付處理包括自動確定支付處理和自動確定支付處理的排列。文中 描述的排列另外可以作為支付處理的排列、流程或順序。這樣，支付處理可以被安排成順序 處理、并行處理或者順序和并行的組合處理。支付處理的確定和處理的排列可以在支付輸 入通道、支付/結(jié)算類型和/或支付屬性的基礎(chǔ)上基于每個支付請求被動態(tài)地確定，支付屬 性例如支付者定義的屬性、收款人定義的屬性和/或金融機(jī)構(gòu)定義的屬性。確定支付處理 和排列的動態(tài)特性允許基于之前處理的輸出或者在進(jìn)行支付處理時所定義的屬性在處理 支付期間通過增加或刪除支付處理或改變排列來改變支付處理。這樣，文中描述的方法、系 統(tǒng)和計算機(jī)程序產(chǎn)品提供了對處理支付的高效和成本節(jié)約的方法。根據(jù)本發(fā)明的一個實施例，定義了一種用于處理金融支付的方法。該方法包括接 收金融支付請求以及確定對于與金融支付請求關(guān)聯(lián)的支付處理和多個與金融支付請求關(guān) 聯(lián)的支付處理的排列。文中使用的“排列，，可以是執(zhí)行支付處理的順序，可以是順序、并行 或者順序和并行的組合順序。該方法進(jìn)一步包括根據(jù)確定的排列執(zhí)行多個支付處理并且提 供與金融支付請求關(guān)聯(lián)的金融支付。支付處理可以包括但不限于支付途徑，管理將來日期支付和重復(fù)支付的啟動，貸 方和借方相關(guān)，驗證支付，處理大量金融支付請求，存儲至少一個支付歷史，將來日期的支 付或者重復(fù)支付，確保支付合法性(compliance)，提供外匯兌換處理，提供金融風(fēng)險評估， 提供金融支付異常應(yīng)對處理等。根據(jù)方法的特定實施例，接收金融支付請求可以另外包括從多個不同支付輸入通 道中的一個接收金融支付請求。在該實施例中，執(zhí)行多個支付處理進(jìn)一步包括執(zhí)行多個支 付處理而不用管支付輸入通道類型。根據(jù)方法的另一實施例，確定支付處理的排列可以進(jìn)一步包括基于至少一個支付 輸入通道、支付類型或支付屬性確定支付處理的排列，在該實施例中，該方法進(jìn)一步包括基 于一個或更多個途徑規(guī)則確定對于支付請求的支付途徑，其中支付途徑定義了支付類型。 另外，基于支付屬性確定支付處理的排列進(jìn)一步包括基于支付者定義的支付屬性、收款人 定義的支付屬性或金融機(jī)構(gòu)定義的支付屬性確定支付處理的排列。根據(jù)方法的特定實施例，可以在支付處理的開始或者現(xiàn)行支付處理期間基于每個 支付請求動態(tài)確定支付處理的排列。例如，可以基于多個支付處理中的一個或更多個的結(jié) 果確定排列(即，重新排列)。
類似地，根據(jù)方法的其它實施例，確定支付處理進(jìn)一步包括基于至少一個支付輸 入通道、支付類型或支付屬性確定與金融支付請求關(guān)聯(lián)的支付處理。在該實施例中，方法可 以進(jìn)一步包括基于一個或更多個途徑規(guī)則確定支付請求的支付途徑，其中支付途徑定義了 支付類型。另外，基于支付屬性確定支付處理進(jìn)一步包括基于支付者定義的支付屬性、收款 人定義的支付屬性或金融機(jī)構(gòu)定義的支付屬性確定支付處理。根據(jù)方法的特定實施例，支付處理可以在支付處理開始或現(xiàn)行支付處理期間基于 每個支付請求動態(tài)確定。例如，可以基于多個支付處理中的一個或更多個的結(jié)果確定支付
處理。處理金融支付的設(shè)備定義了本發(fā)明的另一實施例。該設(shè)備包括一包含至少一個處 理器和存儲器的計算平臺。該設(shè)備還包括存儲在存儲器中的支付處理模塊，其可由處理器 執(zhí)行并且包括多個支付處理子模塊，每個支付處理子模塊都可用來執(zhí)行一個或更多個支付 處理。支付處理模塊進(jìn)一步包括處理管理邏輯，用于確定與支付請求關(guān)聯(lián)的多個支付處理 并且確定對于多個支付處理的排列。文中描述的排列可以是執(zhí)行支付處理的順序，可以是 順序的、并行的或者二者的組合。根據(jù)設(shè)備的特定實施例，支付處理子模塊可以包括但不限于支付途徑子模塊，將 來支付管理子模塊，借方和貸方子模塊，驗證子模塊，批量支付子模塊，支付數(shù)據(jù)庫，合法性 子模塊，外匯兌換子模塊，金融風(fēng)險評估子模塊，以及異常處理子模塊。根據(jù)設(shè)備的另外實施例，支付處理模塊用于從多個支付輸入通道中接收支付請 求，多個支付處理子模塊用于執(zhí)行一個或更多個支付處理而不受支付輸入通道的影響的類 型。在這方面，支付處理模塊能夠處理從不同的輸入通道發(fā)起的支付請求。根據(jù)設(shè)備的其它可選實施例，處理管理邏輯進(jìn)一步用于基于支付輸入通道、支付 類型或支付屬性中的至少一個確定對于多個支付處理的排列。在該實施例中，多個支付處 理子模塊可以包括基于一個或更多個途徑規(guī)則確定對于支付請求的支付途徑的支付途徑 子模塊，其中支付途徑定義了支付類型。另外，處理管理邏輯進(jìn)一步用于基于一個或更多個 支付者定義的支付屬性，收款人定義的支付屬性或金融機(jī)構(gòu)定義的支付屬性確定對于多個 支付處理的排列。根據(jù)設(shè)備的另一實施例，處理管理邏輯在支付處理器開始時或者現(xiàn)行支付處理期 間基于每個支付請求動態(tài)確定對于多個支付處理的排列。例如，基于多個支付處理中的一 個或更多個的結(jié)果確定排列(即，重新排列)。在設(shè)備的另一實施例中，處理管理邏輯用于基于支付輸入通道、支付類型或者支 付屬性中的至少一個確定與金融支付請求關(guān)聯(lián)的多個支付處理。在該實施例中，多個支付 處理子模塊可以包括支付途徑子模塊，用于基于一個或更多個途徑規(guī)則確定對于支付請求 的支付途徑，其中支付途徑定義了支付類型。根據(jù)設(shè)備的另一實施例，處理管理邏輯用于在支付處理開始或者在現(xiàn)行支付處理 期間基于每個支付請求動態(tài)確定支付處理。例如，可以基于一個或更多個支付處理的結(jié)果 確定支付處理。本發(fā)明的另一實施例提供了一種計算機(jī)程序產(chǎn)品，其包括計算機(jī)可讀介質(zhì)。該介 質(zhì)包括第一組代碼，用于使計算機(jī)接收金融支付請求，第二組代碼，用于使計算機(jī)確定與金 融支付請求關(guān)聯(lián)的多個支付處理，以及第三組代碼，用于使計算機(jī)確定對與金融支付請求關(guān)聯(lián)的多個支付處理的排列。該介質(zhì)另外還包括第四組代碼，用于使計算機(jī)根據(jù)確定的排 列執(zhí)行多個支付處理，以及第五組代碼，用于使計算機(jī)提供與金融支付請求關(guān)聯(lián)的金融支 付。因此，文中提供的設(shè)備、系統(tǒng)和計算機(jī)程序產(chǎn)品用于管理金融支付處理，尤其是管 理綜合支付集中器環(huán)境中的金融支付處理，其提供了支付處理以及支付途徑的確定而不受 支付輸入通道的影響。根據(jù)文中公開的實施例，管理支付處理包括自動確定支付處理和自 動確定支付處理的排列。如此，文中描述的方法、系統(tǒng)和計算機(jī)程序產(chǎn)品提供了處理支付的 高效和成本節(jié)約的方法。為了實現(xiàn)上文和相關(guān)的目的，一個或更多個實施例包括后文中完整描述的特征尤 其是在權(quán)利要求中提出的特征。下面的描述和附圖詳細(xì)列出了一個或更多個實施例的一些 示意性特征。然而這些特征是可采用各種實施例的原理的各種方式中的少量幾種的示例， 并且該描述目的在于包含所有這些實施例以及它們的等同物。


以通用術(shù)語描述了本發(fā)明的實施例，現(xiàn)在將參照附圖，附圖并不必然是按比例繪 制的，在附圖中圖1是根據(jù)本發(fā)明的一個實施例的被配置為在支付集中器環(huán)境中提供支付處理 管理的設(shè)備的框圖；圖2是根據(jù)本發(fā)明的一個實施例的被配置為在支付集中器環(huán)境中提供支付處理 管理的設(shè)備的詳細(xì)框圖；圖3是根據(jù)本發(fā)明的一個實施例的被配置為提供基于規(guī)則的金融支付途徑的設(shè) 備的詳細(xì)框圖；圖4是根據(jù)本發(fā)明的一個實施例的用于處理金融支付請求的方法的流程圖；圖5是根據(jù)本發(fā)明的一個實施例的金融支付輸入通道的框圖；圖6是根據(jù)本發(fā)明的另一實施例的支付排列屬性/規(guī)則資源的框圖；圖7是根據(jù)本發(fā)明的實施例的包含可選處理的特定支付處理的框圖；圖8是根據(jù)本發(fā)明的實施例的支付驗證處理的框圖；圖9是根據(jù)本發(fā)明的實施例的途徑規(guī)則的實例的框圖；圖10是根據(jù)本發(fā)明的另一實施例的匯款和結(jié)算通道的框圖；圖11是根據(jù)本發(fā)明的另一實施例的在支付集中器環(huán)境中提供支付處理管理的方 法的流程圖的框圖。
具體實施例方式下文中本發(fā)明的實施例將結(jié)合附圖進(jìn)行完整地描述，其中示出了本發(fā)明的一部分 但不是所有的實施例。實際上，本發(fā)明可以以多種不同形式體現(xiàn)，并且不應(yīng)當(dāng)限于文中提出 的實施例；相反，提供這些實施例使得本發(fā)明可以滿足可應(yīng)用的法律需求。在下面的描述 中，為了解釋清楚，提出了大量的特定細(xì)節(jié)從而提供對一個或更多個實施例的透徹理解。然 而，明顯的是，可以在沒有這些特定細(xì)節(jié)的情況下實施這些實施例。全文中相同的附圖標(biāo)記 表示相同的元件。
根據(jù)包括大量設(shè)備、組件、模塊等的系統(tǒng)或者設(shè)備提供了各種實施例或者特征?？梢岳斫夂兔靼椎氖?，各種系統(tǒng)或者設(shè)備可以包括額外的設(shè)備、組件、模塊等和/或可以不包 括在附圖中所討論的所有的設(shè)備、組件、模塊等。也可以使用這些手段的組合。結(jié)合文中公開的實施例描述的方法或者算法的步驟和/或動作可以直接在硬件、 由處理器執(zhí)行的軟件，或者二者的結(jié)合中實現(xiàn)。軟件模塊可以駐存在RAM存儲器、閃存、ROM 存儲器、EPROM存儲器、EEPROM存儲器、寄存器、硬盤、可移動盤、CD-ROM或者現(xiàn)有技術(shù)中已 知的任意其它形式的存儲器介質(zhì)。示例性的存儲器介質(zhì)可以耦接到處理器，以便處理器可 以從存儲器介質(zhì)讀取信息以及向其中寫入信息?？商娲?，存儲器介質(zhì)可以集成到處理器 中。另外，在某些實施例中，處理器和存儲器介質(zhì)可以駐存在專用集成電路(ASIC)中?？?替代的，處理器和存儲器介質(zhì)可以在計算設(shè)備中作為分立的組件駐存。另外，在某些實施例 中，方法或算法的時間和/或動作可以在機(jī)器可讀介質(zhì)和/或計算機(jī)可讀介質(zhì)上作為一個 編碼和/或指令或者其任意組合或集合駐存，其可以并入到計算機(jī)程序產(chǎn)品中。在一個或更多個實施例中，可以在硬件、軟件、固件或其任意組合中實現(xiàn)文中描述 的功能。如果在軟件中實現(xiàn)的話，這些功能可以作為計算機(jī)可讀介質(zhì)上的一個或更多個指 令或者編碼存儲或者傳送。計算機(jī)可讀介質(zhì)包括計算機(jī)存儲介質(zhì)和通信介質(zhì)，其包括便于 計算機(jī)程序從一個地方傳輸?shù)搅硪粋€地方的任意介質(zhì)。存儲器介質(zhì)可以是能夠由計算機(jī)訪 問的任意可用介質(zhì)。舉例而言(并非限制)，這種計算機(jī)可讀介質(zhì)包括RAM、ROM、EEPROM、 CD-ROM或者其它光盤存儲器、磁盤存儲器或者其它磁存儲器設(shè)備、或者任意其它能夠以指 令或者數(shù)據(jù)結(jié)構(gòu)形式傳送或者存儲需要的程序編碼以及可由計算機(jī)訪問的介質(zhì)。而且，任 意連接都可以叫做計算機(jī)可讀介質(zhì)。例如，如果軟件是從網(wǎng)站、服務(wù)器或者其它使用同軸纜 線、光纖纜線、雙扭線、數(shù)字用戶線(DSL)或者例如紅外線、無線電和微波的無線技術(shù)的遠(yuǎn) 程資源傳送的，那么同軸纜線、光盤纜線、雙扭線、DSL或者例如紅外線、無線電或微波的無 線技術(shù)都包含在介質(zhì)的定義中。這里使用的“磁盤(disk)”和“光盤(disc)”包括高密度 光盤(⑶)、激光盤、光盤、數(shù)字通用光盤(DVD)、軟盤和藍(lán)光盤，其中磁盤通常以磁的方式再 現(xiàn)數(shù)據(jù)，而光盤通常利用激光以光的方式再現(xiàn)數(shù)據(jù)。上述內(nèi)容的組合也應(yīng)當(dāng)包含在計算機(jī) 可讀介質(zhì)的范圍內(nèi)這樣，這里描述的方法、設(shè)備、系統(tǒng)和計算機(jī)程序產(chǎn)品用于管理金融支付處理，尤 其用于在綜合支付集中器環(huán)境中管理金融支付處理，其中提供了支付處理，在某些實施例 中，確定支付途徑而不受支付輸入通道的影響。根據(jù)文中描述的實施例，管理支付處理包括 自動確定支付處理和自動確定支付處理的排列。文中描述的排列可以是支付處理的排列、 流程或順序。這樣，支付處理可以排列成順序發(fā)生、并行發(fā)生或者以順序處理和并行處理的 任何組合發(fā)生。確定支付處理和排列處理可以基于支付輸入通道、支付/結(jié)算類型和/或 支付屬性(例如支付者定義的屬性、收款人定義的屬性和/或金融機(jī)構(gòu)定義的屬性)在每 個支付請求的基礎(chǔ)上動態(tài)地確定。支付處理的動態(tài)確定特性和排列允許支付處理基于之前 處理的結(jié)果或者正在進(jìn)行支付處理時所定義的屬性，通過在支付處理期間增加或刪減支付 處理或者改變排列來改變支付處理。這樣，文中描述的方法、系統(tǒng)和計算機(jī)程序產(chǎn)品使得支 付處理高效和成本節(jié)約。參考圖1，描述了根據(jù)本發(fā)明的實施例提供的用于金融支付處理的設(shè)備100的框 圖。如前所述，設(shè)備100可以包括一個或更多個設(shè)備。在多個設(shè)備實施例中，設(shè)備可以是在相互聯(lián)網(wǎng)的環(huán)境中。設(shè)備100包括計算平臺110，其具有至少一個處理器120和存儲器130。設(shè)備100的存儲器130包括支付處理模塊150，文中也稱作支付集中器，其包括多 個支付處理子模塊152。根據(jù)文中描述的實施例，支付處理模塊150是能夠進(jìn)行處理支付而 不受支付輸入通道的影響的綜合支付處理系統(tǒng)。在本發(fā)明的一個實施例中，不受支付輸入 通道影響的處理支付請求的能力是通過將支付請求的最初格式轉(zhuǎn)換為標(biāo)準(zhǔn)化或正規(guī)化格 式而提供的。支付處理子模塊152可以包括但不限于能夠進(jìn)行支付途徑確定、計劃將來的和/ 或重復(fù)的支付、借方和貸方相關(guān)、支付驗證、批量支付處理、支付數(shù)據(jù)存儲器、支付合法性檢 查、外匯兌換處理、支付風(fēng)險評估、支付異常處理等的模塊。每個支付子模塊152可以包括 一個或更多個支付處理154，它們可以作為支付請求的一部分被請求或者被執(zhí)行。支付處理模塊150還包括處理管理邏輯140，用于基于每個支付請求確定可應(yīng)用 到支付請求上的支付處理154和支付處理排列142。如文中描述的處理排列142可以是進(jìn) 行處理的流程、排列和/或順序。這些處理可以被排列為順序發(fā)生、并行發(fā)生、或者以順序 處理和并行處理的組合發(fā)生。在本發(fā)明的一個實施例中，支付處理和排列可以在支付處理 開始時確定并在整個處理期間保持靜態(tài)不變。在本發(fā)明的其它實施例中，支付處理和排列 可以在整個支付處理期間被確定或者重新評估。例如，一個處理的結(jié)果可以造成支付處理 的增加或刪減和/或處理的結(jié)果可以規(guī)定支付處理的重新排列。在這方面，處理的確定和 /或處理的排列可以在整個支付處理期間保持為動態(tài)。在本發(fā)明的特定實施例中，支付處理154的確定和/或支付處理的排列142可以 基于支付輸入通道、支付類型或支付屬性。支付屬性可以由支付者、收款人或執(zhí)行支付處理 的金融機(jī)構(gòu)定義。支付屬性可以是存儲在支付者、收款人和/或金融機(jī)構(gòu)數(shù)據(jù)庫中的預(yù)先 定義的屬性，或者支付屬性可以是在支付請求處理期間定義的動態(tài)屬性。圖2提供了根據(jù)本發(fā)明的另一實施例的設(shè)備100的更詳細(xì)描述。除了提供更為詳 細(xì)的描述，圖2突出了各種可選實施例。設(shè)備100可以包括一個或更多個計算設(shè)備的任意 類型和/或組合，例如個人計算機(jī)、膝上/便攜計算機(jī)、無線或手持計算設(shè)備、服務(wù)器等。計 算平臺110用于接收和執(zhí)行模塊、例程和應(yīng)用，例如支付處理模塊150、處理管理邏輯140 等。計算平臺110包括存儲器130，其可以包括易失性和非易失性存儲器，例如只讀和/或 隨機(jī)存取存儲器(RAM和R0M)、EPR0M、EEPR0M、閃存卡或者任意計算平臺通用的存儲器。另 夕卜，存儲器130可以包括一個或更多個閃存單元，或者可以是任意二級或三級存儲器設(shè)備， 例如磁介質(zhì)、光介質(zhì)、磁帶、或者軟盤或硬盤。另外，計算平臺110還包括處理器120，其可以是專用集成電路(”ASIC”)，或者其 它芯片集、處理器、邏輯電路、或者其它數(shù)據(jù)處理設(shè)備。處理器120或其它例如ASIC的處理 器可以執(zhí)行應(yīng)用程序接口( “API”)層200，其與存儲在設(shè)備100的存儲器130中的任何駐 存的程序(例如支付處理模塊150、處理管理邏輯140等)接口。處理器120包括在硬件、固件、軟件及其組合中實現(xiàn)的各種處理子系統(tǒng)220，其使能操作設(shè)備100的功能以及網(wǎng)絡(luò)上設(shè)備的可操作性。例如，處理子系統(tǒng)220允許啟動并且 保持與其它網(wǎng)絡(luò)設(shè)備之間的通信和數(shù)據(jù)交換。設(shè)備130的存儲器130包括支付處理模塊150，其包括多個支付處理子模塊152。 如前所述，支付處理模塊150是能夠在不顧支付輸入通道的情況下處理支付的綜合支付處理系統(tǒng)。在本發(fā)明的一個實施例中，通過將支付請求的啟動格式轉(zhuǎn)化為標(biāo)準(zhǔn)化或正規(guī)化格 式，提供不管支付輸入通道的處理支付請求的能力。另外，結(jié)合圖3進(jìn)行詳細(xì)討論的支付途 徑確定子模塊170提供確定支付途徑(即，支付類型或結(jié)算/匯款輸出)而不受支付輸入 通道的影響。這樣，支付輸入通道可以不同于支付輸出通道。應(yīng)當(dāng)注意描述的支付處理模塊150是一個單獨的模塊，但是根據(jù)本實施例，該模 塊可以包括多個模塊，并且多個模塊可以包含在各種不同的設(shè)備中。這樣，在支付處理模塊 150中描述的例程、應(yīng)用、數(shù)據(jù)庫和邏輯可以包含在多個模塊中。同樣，關(guān)于支付處理模塊 150所討論的規(guī)則和邏輯可以被包含或者實現(xiàn)在多個應(yīng)用或例程中。如圖2所示，支付處理子模塊152可以包括但不限于支付途徑確定子模塊170、計 劃和循環(huán)支付子模塊710、關(guān)系(correlation)子模塊720、支付驗證子模塊730、批量支付 處理子模塊740、支付數(shù)據(jù)庫/倉庫750、支付合法性子模塊810、外匯兌換子模塊820、支付 風(fēng)險評估子模塊830、和/或支付異常處理子模塊840等。每個支付子模塊152可以包括一 個或更多個支付處理154，其作為支付請求的一部分被要求和執(zhí)行。結(jié)合圖4描述了支付途徑確定子模塊170。計劃和循環(huán)支付子模塊710管理將來 日期的和循環(huán)支付的啟動，包括對于計劃/循環(huán)支付使用預(yù)先定義的定制模板設(shè)置。借方/ 貸方關(guān)系子模塊720包括定時和順序處理以確保原始支付關(guān)聯(lián)的關(guān)系。在這方面，當(dāng)在支 付項級處理時單獨的信用被關(guān)聯(lián)和平衡(balance)到原始的借方。驗證子模塊730用于驗證支付和相關(guān)的賬戶屬性以確保支付的正結(jié)算。批量支付 子模塊740用于對于大的支付文件聚集和優(yōu)化到外部系統(tǒng)的通信，所述大的支付文件具有 多個單獨支付項，而多個單獨支付項具有相同的記入賬戶。合法性處理子模塊810用于確保支付的反洗錢。合法性處理可以包括已知的與違 法支付處理關(guān)聯(lián)的個人、公司等的海外資金控制辦公室(OFAC)名單的安全檢查。外匯兌換 /單一歐元支付區(qū)(SEPA)子模塊820，用于最大化外幣匯率，提供多貨幣支持并確保符合 SEPA規(guī)則和規(guī)章。金融風(fēng)險評估子模塊830用于提供對于整個支付處理的信用和風(fēng)險管理。在這方 面，金融風(fēng)險評估處理可以提供債務(wù)風(fēng)險評估分?jǐn)?shù)等，其接下來由基于規(guī)則的途徑確定用 于限制或規(guī)定(mandate)可以實現(xiàn)的匯款/結(jié)算途徑類型。例如，如果確定金融風(fēng)險為高， 途徑確定可以將電報支付排除作為匯款/結(jié)算支付選項。異常處理子模塊840用于提供對所有支付類型的集中式異常處理和管理。異常處 理考慮了支付處理中的錯誤，例如格式化錯誤，并且可以實現(xiàn)對于普通異常/錯誤的自動 修正。對異常的自動修正需要較少的人工干預(yù)并提高了直通支付處理率。在前面結(jié)合圖1描述的，支付處理模塊150還包括處理管理邏輯140，用于基于每 個支付請求確定可應(yīng)用于支付請求的支付處理154以及支付處理排列142。處理可以安排 成順序發(fā)生、并行發(fā)生、或者以順序處理和并行處理的組合發(fā)生。在本發(fā)明的一個實施例 中，支付處理和排列可以在支付處理的開始時確定并且在整個處理期間保持靜態(tài)不變。在 本發(fā)明的其它實施例中，支付處理和排列可以在整個支付的處理期間被確定或者被重新評 估。例如，一個處理的結(jié)果會造成支付處理的增加或刪減，和/或處理的結(jié)果會指示支付處 理的重新排列。在這方面，處理的確定和/或處理的排列可以在整個支付的處理期間保持 動態(tài)變化。
在本發(fā)明的特定實施例中，支付處理154的確定和/或支付處理的排列142可以 基于支付輸入通道、支付類型或支付屬性。支付輸入通道可以包括但不限于開放式金融交換(OFX)/移動、網(wǎng)頁、交互語音響 應(yīng)(IVR)/電話、銀行中心、自動柜員機(jī)(ATM)、借記卡/信用卡、商人、支票、圖像、電報、自動 交換所(ACH)等。支付屬性可以由支付者、收款人或者執(zhí)行支付處理的金融機(jī)構(gòu)定義。支付屬性250 可以是支付者定義的/收款人定義的屬性260和/或金融機(jī)構(gòu)/銀行定義的支付屬性270。 支付者定義的/收款人定義的支付屬性260可以包括 但不限于價格262、時間264、風(fēng)險/ 質(zhì)量266、匯款要求267、目的地268或者任意其它可以應(yīng)用于處理管理的適當(dāng)屬性269。金 融機(jī)構(gòu)/銀行定義的支付屬性270可以包括但不限于成本272、時間274、風(fēng)險/質(zhì)量276、 匯款要求277、目的地278或者任意其它可應(yīng)用于處理管理的其它適當(dāng)屬性279。支付屬性260和270可以是存儲在支付者、收款人和/或金融機(jī)構(gòu)數(shù)據(jù)庫中的預(yù) 先定義的屬性，或者支付屬性可以是在支付請求處理期間定義的動態(tài)屬性。這樣，存儲器 130可以包括用于存儲支付屬性的支付者簡檔數(shù)據(jù)庫280、收款人簡檔數(shù)據(jù)庫290和/或金 融機(jī)構(gòu)/銀行數(shù)據(jù)庫294。這樣，支付者簡檔數(shù)據(jù)庫280可以包括多個支付者/客戶特征 282，并且每個特征282包括與支付者關(guān)聯(lián)的支付屬性260。收款人簡檔數(shù)據(jù)庫290可以包 括多個收款人簡檔292，并且每個特征292包括與收款人關(guān)聯(lián)的支付屬性260。金融機(jī)構(gòu)/ 銀行數(shù)據(jù)庫294可以包括與輸入支付請求類型關(guān)聯(lián)的支付屬性270或者任意其它關(guān)聯(lián)。圖3提供了根據(jù)本發(fā)明的其它可選實施例的設(shè)備100的更詳細(xì)的描述。設(shè)備100 的存儲器130可選地包括支付轉(zhuǎn)換模塊210，支付轉(zhuǎn)換模塊210與處理器120通信并用于標(biāo) 準(zhǔn)化支付請求然后將所處理的支付請求轉(zhuǎn)換為所確定的支付途徑/類型的格式。支付類型 的標(biāo)準(zhǔn)化允許支付模塊140使用類似的處理和技術(shù)在支付倉庫類型環(huán)境中處理所有類型 的支付請求。這樣，支付轉(zhuǎn)換模塊210包括由處理器120執(zhí)行的標(biāo)準(zhǔn)化邏輯230并且用于 將進(jìn)入的支付請求轉(zhuǎn)換/標(biāo)準(zhǔn)化為經(jīng)標(biāo)準(zhǔn)化的格式，例如國際標(biāo)準(zhǔn)化組織(ISO) 20022通用 金融工業(yè)信息方案等等。支付轉(zhuǎn)換模塊210另外還包括支付格式化邏輯240，支付格式化邏 輯240可由處理器120執(zhí)行并且用于將后支付處理器、經(jīng)標(biāo)準(zhǔn)化的格式轉(zhuǎn)換為所確定的支 付途徑/結(jié)算類型的格式。支付處理模塊150用于接收支付指令，驗證支付并且確定用于支付的途徑。根據(jù) 本發(fā)明的當(dāng)前可選實施例，支付處理模塊140用于基于每個支付確定支付途徑，以便基于 與支付和/或支付者和/或收款人和/或處理支付的金融機(jī)構(gòu)相關(guān)的特征確定匯款和結(jié)算 支付的方式。在這方面，可以通過支付者、收款人和/或金融機(jī)構(gòu)在支付處理的成本、支付 處理的時間性和支付處理的質(zhì)量/風(fēng)險方面實現(xiàn)支付優(yōu)化。對于支付轉(zhuǎn)換模塊210和支付處理模塊150描述了單獨的模塊，但是根據(jù)本實施 例，這些模塊可以包括多個模塊并且多個模塊可包含在各種不同的設(shè)備中。這樣，關(guān)于支付 轉(zhuǎn)換模塊210和支付處理模塊150所描述的例程、應(yīng)用、數(shù)據(jù)庫和邏輯可被包含在多個模塊 中。同樣，關(guān)于支付轉(zhuǎn)換模塊210和支付處理模塊150所討論的規(guī)則和邏輯可以被包含在 多個應(yīng)用或例程中或者在多個應(yīng)用或例程中實現(xiàn)。支付處理模塊150包括途徑規(guī)則數(shù)據(jù)庫158，途徑規(guī)則數(shù)據(jù)庫158包括一個或更多 個途徑規(guī)則160。途徑規(guī)則160可以與支付途徑因素(例如，但不限于，處理支付的價格/成本、處理支付的時間要求、質(zhì)量/風(fēng)險要求或者處理支付的容差(即，保證匯款和結(jié)算，中 止支付的能力等)、支付目的地等相關(guān)。這樣，途徑規(guī)則160可以包括一個或更多個成本/ 價格相關(guān)途徑規(guī)則162、一個或更多個時間相關(guān)途徑規(guī)則164、一個或更多個風(fēng)險/質(zhì)量相 關(guān)途徑規(guī)則166、一個或更多個目的地相關(guān)途徑規(guī)則168或其它途徑規(guī)則169。成本/價格相關(guān)途徑規(guī)則162可以定義基于支付者和/收款人愿意承擔(dān)的對于正 進(jìn)行的支付的價格、或者金融機(jī)構(gòu)愿意承擔(dān)的或向支付者收取的對于處理支付的成本選擇 匯款結(jié)算類型180。在這方面，不同的匯款結(jié)算類型可以與不同的支付價格關(guān)聯(lián)以便一種匯 款/結(jié)算類型的支付在支付價格上比其它匯款/結(jié)算類型高或低。時間相關(guān)途徑規(guī)則164可以定義為了完成支付交易，基于支付者的、收款人的和 /或金融機(jī)構(gòu)的可接受的時間，選擇哪種匯款/結(jié)算類型180。在大多數(shù)情況中，支付者和/ 或收款人期望盡量及時地完成支付，而處理支付的金融機(jī)構(gòu)期望將匯款/結(jié)算延遲盡量長 的時間段。然而，應(yīng)當(dāng)明白，在大多數(shù)情況中，支付者關(guān)心盡量及時地進(jìn)行支付，而在其它情 況中，支付者可能期望延遲支付時間(例如，如果要從其進(jìn)行支付的賬戶中當(dāng)前沒有足夠 的資金)。與風(fēng)險/質(zhì)量相關(guān)的途徑規(guī)則166可以定義基于確?；虮ＷC將會進(jìn)行支付的能 力(換句話說，提供給支付的服務(wù)等級或者與不同支付匯款/結(jié)算類型關(guān)聯(lián)的失敗幾率數(shù)) 選擇哪種匯款/結(jié)算類型180。其它風(fēng)險/質(zhì)量途徑規(guī)則166可以定義支付處理期間的返 回或中止支付的能力、數(shù)據(jù)核對能力，例如如何平衡資金或者任意與質(zhì)量或風(fēng)險屬性關(guān)聯(lián) 的其它途徑規(guī)則，所述質(zhì)量或風(fēng)險屬性由支付者、收款人和/或進(jìn)行支付處理的金融機(jī)構(gòu) 定義。
與目的地相關(guān)的途徑規(guī)則168可以定義基于支付目的地選擇哪種匯款/結(jié)算類 型180。例如，國內(nèi)支付可以規(guī)定匯款/結(jié)算的某些類型，同時國際支付可以規(guī)定其它類型
的匯款/結(jié)算。其它途徑規(guī)則169可以另外定義其它用于選擇匯款/結(jié)算類型180的規(guī)則?？梢?根據(jù)進(jìn)行支付處理的金融機(jī)構(gòu)、支付者和/或收款人的需求規(guī)定其它途徑規(guī)則。支付模塊150另外包括支付途徑確定子模塊170，支付途徑確定子模塊170由處理 器120執(zhí)行并且用于從多于一個可選支付類型中基于一個或更多個途徑規(guī)則的應(yīng)用確定 對于支付交易的支付途徑(即，支付類型180，文中也稱做支付途徑)。在應(yīng)用多于一個途 徑規(guī)則來確定匯款結(jié)算類型180的情況中，支付途徑確定子模塊170可以用于確定途徑規(guī) 則的優(yōu)先級和/或作出適當(dāng)?shù)耐緩酱_定，其確保滿足支付者/收款人和/或進(jìn)行支付處理 的金融機(jī)構(gòu)的需求。支付途徑確定子模塊170用于將一個或更多個支付屬性/支付規(guī)則250應(yīng)用于一 個或更多個途徑規(guī)則160上以確定支付途徑/類型180。支付屬性可以是支付者定義的/ 收款人定義的支付屬性260和/或金融機(jī)構(gòu)/銀行定義的支付屬性270。支付者定義的/ 收款人定義的支付屬性260可以包括但不限于價格262、時間264、風(fēng)險/質(zhì)量266、匯款要 求267、目的地268或任意其它可應(yīng)用到途徑規(guī)則上的適當(dāng)屬性269。金融機(jī)構(gòu)/銀行定義 的支付屬性270可以包括但不限于成本272、時間274、風(fēng)險/質(zhì)量276、匯款要求277、目的 地278或者任意可應(yīng)用到途徑規(guī)則上的其它適當(dāng)屬性279。支付屬性/規(guī)則250可以由支付者、收款人或金融機(jī)構(gòu)在支付請求時動態(tài)定義或者支付屬性/規(guī)則250可以是與支付者、收款人和/或金融機(jī)構(gòu)關(guān)聯(lián)的預(yù)先定義的屬性。另 夕卜，在某些實施例中，支付屬性/規(guī)則可以由支付者、收款人和/或金融機(jī)構(gòu)在支付處理期 間動態(tài)定義。這樣，存儲器130可以包括支付者簡檔數(shù)據(jù)庫280、收款人簡檔數(shù)據(jù)庫290和 /或金融機(jī)構(gòu)/銀行數(shù)據(jù)庫294用于存儲支付屬性/規(guī)則，或者支付模塊可以與另一輔助設(shè) 備的存儲器(圖3未示出)通信，所述存儲器包括支付者簡檔數(shù)據(jù)庫280、收款人簡檔數(shù)據(jù) 庫290和/或金融機(jī)構(gòu)/銀行數(shù)據(jù)庫294用于存儲支付屬性/規(guī)則。這樣，支付者簡檔數(shù) 據(jù)庫280包括多個支付者/客戶簡檔282并且每一個簡檔282包括與支付者關(guān)聯(lián)的支付屬 性/規(guī)則260。收款人簡檔數(shù)據(jù)庫290可以包括多個收款人簡檔292，每個簡檔292包括與 收款人關(guān)聯(lián)的支付屬性/規(guī)則260。金融機(jī)構(gòu)/銀行數(shù)據(jù)庫294可以包括與輸入支付請求 類型或任意其它相關(guān)類型關(guān)聯(lián)的支付屬性/規(guī)則270。如前所述，支付途徑確定子模塊170可以從多于一種備選中確定任何適當(dāng)?shù)闹Ц?途徑180類型。支付途徑/類型可以包括支票/票據(jù)300、信用卡/借記卡302、電子/ACH 304、電報306、SffIFT 308、商人310、轉(zhuǎn)帳312或任意其它匯款結(jié)算支付途徑/類型314。 一種備選支付途徑包括兩個或更多個支付途徑類型。例如，支票/票據(jù)300或借方/貸方 302包括一種備選支付途徑、SWIFT 308或者轉(zhuǎn)帳312包括其它備選支付途徑和電報306或 SffIFT 308或商人310包括另一備選支付途徑。圖4提供了根據(jù)本發(fā)明的一個實施例的用于包括支付處理的確定和支付處理的 排列的支付處理組合方法400的流程圖。在事件410，通過指定的輸入通道輸入支付請求。 圖5提供了支付輸入通道500的各種實例的框圖。應(yīng)當(dāng)注意圖5示出的支付輸入通道500 僅僅是示例，并不意欲構(gòu)成限制。支付輸入通道500可以包括客戶(即，個人、接合點等) 支付輸入通道510和商人/前端支付輸入通道530?？蛻糁Ц遁斎胪ǖ?10提供了客戶到 商人支付輸入和/或客戶到消費(fèi)者(即，消費(fèi)者到消費(fèi)者)支付輸入。商人/前端支付輸 入通道530提供了商人到商人支付輸入和/或商人到消費(fèi)者支付輸入?？蛻糁Ц遁斎胪ǖ朗怯脩艚涌?，可以包括但不限于開放式金融交換(OFX)/移動 支付輸入通道512(通?？梢栽谑殖衷O(shè)備等上操作)；基于網(wǎng)頁支付輸入通道514，例如因特 網(wǎng)或者公司網(wǎng)站，其通常用于接收自動交換所(ACH)請求、電報支付請求、帳單支付等；電 話/交互式語音響應(yīng)(IVR)支付輸入通道516 ；銀行中心支付輸入通道(個人)518 ；以及自 動柜員機(jī)(ATM)支付輸入通道520。商人/前端輸入通道530包括但不限于銷售點支付輸入通道532，例如信用卡/ 借計卡刷卡等；圖像交換支付輸入通道534 ；遠(yuǎn)程儲蓄支付輸入通道536 ；批量文件消息支 付輸入通道538 ；以及直回(straight back)辦公室集成輸入通道540，其中商業(yè)應(yīng)用直接 調(diào)用/訪問金融機(jī)構(gòu)支付引擎以發(fā)起交易。再參考圖4的方法400，在事件420處，建立了支付排列屬性/規(guī)則。支付排列屬 性/規(guī)則是可配置的數(shù)據(jù)，其與消費(fèi)者支付者/收款人或者公司支付者/收款人關(guān)聯(lián)并隨 后被支付處理集中器用于處理支付請求的各個方面。圖6提供了支付排列規(guī)則/屬性資源 600的各個實例的框圖。資源600可以包括但不限于收款人簡檔/設(shè)置610。收款人簡檔 /設(shè)置610可以是收款人要接收的特定支付的動態(tài)設(shè)置。例如，收款人接收支付即將到來的 通知，并且通過適當(dāng)?shù)闹付ㄍǖ?例如通過網(wǎng)站等)收款人配置支付屬性/規(guī)則，例如對于 支付的時間要求等?？商娲?，收款人可以具有預(yù)先定義的支付簡檔，其可以被存儲在預(yù)先定義支付屬性/規(guī)則的可訪問的收款人簡檔數(shù)據(jù)庫中。支付排列規(guī)則/屬性資源600可以另外包括貨品計價和由支付者和/或收款人發(fā) 出的支付報告620，其定義了用于特定支付或一系列支付的支付排列屬性/規(guī)則，例如支付 風(fēng)險/質(zhì)量、支付目的地等。資源600另外還包括支付警告和/或支付通知630，其通常與 特定支付或一系列支付相關(guān)，并且定義由支付者、收款人或處理支付交易的金融機(jī)構(gòu)具體 指定的支付排列規(guī)則。支付排列規(guī)則/屬性資源600可以包括支付者簡檔/設(shè)置640。支付者簡檔/設(shè) 置640可以是支付者請求的對于特定支付的動態(tài)設(shè)置?？商娲?，支付者可以具有預(yù)先定 義的支付簡檔，其可被存儲在預(yù)先定義支付屬性/規(guī)則的可訪問的支付者簡檔數(shù)據(jù)庫中。再次參考圖4的方法400，在事件430處，支付請求被轉(zhuǎn)換(也稱作標(biāo)準(zhǔn)化)為標(biāo) 準(zhǔn)格式以允許處理所有不同支付而不用考慮輸入通道。如前所述，根據(jù)特定實施例，標(biāo)準(zhǔn)化 格式可以根據(jù)ISO 20022通用金融工業(yè)信息方案格式。傳統(tǒng)的已知的支付處理中每個支付 輸入通道都需要用于處理支付的指定庫。根據(jù)本實施例，轉(zhuǎn)換到標(biāo)準(zhǔn)格式允許綜合支付處 理一般地發(fā)生而不用考慮支付輸入通道的類型。在事件440處，支付處理發(fā)生在文中稱作支付處理模塊或支付集中器的位置?；?于支付請求的轉(zhuǎn)換/標(biāo)準(zhǔn)化，支付集中器能夠處理所有類型的支付輸入請求。應(yīng)當(dāng)注意，雖 然在支付處理塊中示出的事件(事件442，444，446)以順序方式發(fā)生，根據(jù)本實施例，這些 事件可以以支付集中器所確定的任何相繼或連續(xù)的順序發(fā)生，從而優(yōu)化支付處理。應(yīng)當(dāng)注意關(guān)于事件440所示出并且在文中被描述為在支付引擎中發(fā)生的例程、模 塊、應(yīng)用和函數(shù)可以被其它應(yīng)用訪問或者通過其它應(yīng)用實現(xiàn)，所述其它應(yīng)用例如為沒有實 現(xiàn)支付引擎等的其它支付處理應(yīng)用。在這方面，其它應(yīng)用可以根據(jù)需要訪問特定例程、模 塊、應(yīng)用和函數(shù)。例如，如果另外的支付處理應(yīng)用要求符合反洗錢法形式的支付驗證，應(yīng)用 可以訪問和實現(xiàn)支付集中器的特定部分，而不是實現(xiàn)支付集中器中的多個應(yīng)用或支付集中 器全部。支付處理可以包括在事件442處接收支付指令，例如支付屬性/規(guī)則、貨品計價/ 報告書、警告、通知等，它們被用于作出支付處理決定。在事件443處，確定支付處理和排列。如前所述，支付處理和排列可以基于支付輸 入通道、支付類型和/或支付屬性。支付屬性可以是收款人定義的屬性、支付者定義的屬性 和/或金融機(jī)構(gòu)定義的屬性。屬性可以是與收款人或支付者簡檔關(guān)聯(lián)的預(yù)先定義的屬性， 或者屬性可以是在支付處理期間或者其附近定義的動態(tài)屬性。應(yīng)當(dāng)注意在支付處理和排列 至少部分基于支付類型的情況中，支付途徑(事件448)的確定可以先于隨后的支付處理的 確定和隨后的支付處理的排列。在這方面以及前面所述，支付處理的確定和支付處理的排 列不限于在支付集中器內(nèi)的支付處理開始處發(fā)生，相反，可以在處理中的任何階段或者時 間點發(fā)生。在事件444處，特定支付處理基于當(dāng)前支付類型在一個或子模塊中發(fā)生。圖7是 詳細(xì)示出根據(jù)本發(fā)明的實施例可在支付集中器處實現(xiàn)的的各種示例性具體支付處理子模 塊700的框圖。應(yīng)當(dāng)注意，圖7中突出的具體支付處理子模塊700僅僅是示例而不意欲構(gòu) 成限制。另外，在一些實施例中，可以基于每個支付在支付集中器處確定支付處理的順序， 以增加支付處理模型的整體效率和有效性。
具體支付處理子模塊700可以包括計劃和重復(fù)支付子模塊710。計劃和重復(fù)子模 塊710管理將來日期和重復(fù)支付的啟動，包括使用用于計劃/重復(fù)支付的預(yù)先定義的定制 模板設(shè)置。另外，具體支付處理子模塊700可以包括貸方/借方關(guān)系子模塊720，其包括定 時和順序處理以確保最初支付關(guān)聯(lián)的關(guān)系。在這方面，當(dāng)在支付項級處理時個人借方與最 初的貸方關(guān)聯(lián)和平衡。具體支付處理子模塊700可以包括驗證子模塊730用于驗證支付和關(guān)聯(lián)的賬戶 屬性以確保支付正結(jié)清。另外，具體支付處理子模塊700可以包括批量支付子模塊740，用 于對于大的支付文件聚集和優(yōu)化與外部系統(tǒng)的通信，所述大的支付文件具有多個單獨支付 項，而多個支付項具有相同的過帳(postingaccounts)。而且，具體支付處理子模塊700可 以包括支付倉庫/數(shù) 據(jù)庫750，用于存儲將來日期的支付、支付歷史、重復(fù)支付模塊等。再次參考圖4的方法400，在可選事件445處，基于事件444處進(jìn)行的支付處理的 結(jié)果，可以進(jìn)行支付處理調(diào)整，其可以包括增加或刪減支付處理或修改/重新排列支付處 理的順序或流程。支付處理(事件440)還包括支付的驗證處理446。圖8是示出根據(jù)本發(fā)明的實施 例可以在支付集中器處實現(xiàn)的各種示例性驗證處理子模塊800的框圖。應(yīng)當(dāng)注意，圖8突 出的具體驗證處理子模塊800僅僅是例子而不意欲構(gòu)成限制。另外，在一些實施例中，可以 基于每個支付在支付集中器中確定驗證處理的順序，用于提高支付處理模型的整體效率和 有效性。驗證處理子模塊800可以包括合法性處理子模塊810用于確保符合反洗錢法。合 法性處理可以包括與違法支付處理關(guān)聯(lián)的個人、公司等的海外資金控制(OFAC)名單的安 全檢查。另外，驗證處理子模塊800包括外匯/單一歐元支付區(qū)(SEPA)子模塊820，用于最 大化外幣匯率，提供多貨幣支持并確保符合SEPA規(guī)則和規(guī)章。另外，驗證處理子模塊800可以包括金融風(fēng)險評估子模塊830，用于提供整個支付 處理的信用和風(fēng)險管理。在這方面，金融風(fēng)險評估處理可以提供債務(wù)風(fēng)險評估分?jǐn)?shù)等，其接 下來由基于規(guī)則的途徑確定用于定義或批準(zhǔn)(mandate)可以實現(xiàn)的匯款/結(jié)算途徑類型。 例如，如果確定金融風(fēng)險為高，途徑確定可以將電報支付排除作為匯款/結(jié)算支付選項。而且，驗證處理子模塊800可以包括異常處理子模塊840，用于提供所有支付類型 的集中異常處理和管理。異常處理考慮了支付處理中的錯誤，例如格式化錯誤等，并且可以 實現(xiàn)對于常見異常/錯誤的自動修正。對異常的自動修正使得較少需要人工干預(yù)并且改善 直通支付處理率。再次參考圖4的方法，在可選事件447處，基于事件446上進(jìn)行的支付處理的結(jié) 果，可以作出支付處理調(diào)節(jié)，可以包括增加或刪減支付處理或者修改/重新排列支付處理 的順序或流程。支付處理(事件440)可以包括基于規(guī)則的途徑確定處理448。根據(jù)本發(fā)明的實 施例，圖9提供可以在支付途徑確定處理中實現(xiàn)的示例性途徑規(guī)則900的框圖。僅僅通過 實例示出途徑規(guī)則。應(yīng)當(dāng)注意對于任一個途徑確定處理來說可以應(yīng)用一個或更多個途徑規(guī) 貝U。給予一個或更多個規(guī)則的優(yōu)先權(quán)可以基于支付者簡檔數(shù)據(jù)、收款人簡檔數(shù)據(jù)、通知、警 告、金融機(jī)構(gòu)規(guī)則等等。途徑規(guī)則900可以與支付途徑因素相關(guān)，例如但不限于處理支付 的價格/成本、處理支付的時間要求、處理支付的質(zhì)量/風(fēng)險或者容差(即，確保匯款和結(jié)算、中止支付的能力等)、支付目的地等。因此，途徑規(guī)則900可以包括一個或更多個時間相 關(guān)的規(guī)則910、成本/價格相關(guān)的途徑規(guī)則920、一個或更多個風(fēng)險/質(zhì)量相關(guān)的途徑規(guī)則 930、一個或更多個目的地相關(guān)的途徑規(guī)則940或其它支付者/收款人定義的途徑規(guī)則950。如前所述，時間相關(guān)途徑規(guī)則910可以定義基于支付者、收款人和/或金融機(jī)構(gòu) 對于完成支付交易的可接受的時間選擇哪種匯款/結(jié)算類型180。在多數(shù)情況中，支付者 和/或收款人期望盡量及時地完成支付，而處理支付的金融機(jī)構(gòu)期望將匯款/結(jié)算延遲盡 量長的時間段。成本/價格相關(guān)途徑規(guī)則920可以定義基于支付者和/或收款人愿意承 擔(dān)的對于支付的價格、或者金融機(jī)構(gòu)愿意承擔(dān)或向支付者收取的對于處理支付的成本選擇 哪種匯款/結(jié)算類型180。風(fēng)險/質(zhì)量相關(guān)途徑規(guī)則930可以定義基于確?；虮ＷC將進(jìn)行支付的能力(換 句話說，提供給支付的服務(wù)等級或者與不同支付匯款/結(jié)算類型關(guān)聯(lián)的可接受的失敗幾率 數(shù))選擇哪種匯款/結(jié)算類型180。其它風(fēng)險/質(zhì)量途徑規(guī)則166可以定義在支付處理期 間返回或中止支付的能力、數(shù)據(jù)核對能力，例如如何平衡資金，或者任意其它與由支付者、 收款人和/或進(jìn)行支付處理的金融機(jī)構(gòu)定義的質(zhì)量或風(fēng)險屬性相關(guān)的途徑規(guī)則。目的地相 關(guān)途徑規(guī)則940可以定義基于支付目的地選擇哪種匯款/結(jié)算類型180。例如，國內(nèi)支付 可以規(guī)定某種匯款/結(jié)算類型，同時國際支付可以規(guī)定其它的匯款/結(jié)算類型。
支付者/收款人定義的規(guī)則950可以另外規(guī)定其它的用于選擇匯款/結(jié)算類型的 規(guī)則?？梢栽谂R近支付請求時動態(tài)定義支付者/收款人定義的途徑規(guī)則950或者在支付者 或收款人簡檔中預(yù)先定義支付者/收款人定義的途徑規(guī)則950。在多數(shù)情況中，支付者或收 款人定義的途徑規(guī)則將優(yōu)先于(override)其它任意途徑規(guī)則。再次參考圖4的方法400，支付處理可以包括其它處理(圖4中未示出)，例如 匯款報告、業(yè)務(wù)處理管理(BPM)編排、交易跟蹤/可見性等。匯款報告向相關(guān)服務(wù)提供 匯款的電子報告；匯款報告的實例包括但不限于活期存款帳號(DDA)報告、帳號核對 (reconciliation)報告、平衡和交易報告等。BPM編排用于確定在支付集中器中進(jìn)行處理 的順序、確定和管理向支付倉庫傳遞信息等。基于支付輸入通道、支付屬性/規(guī)則或所確定 的支付途徑確定進(jìn)行支付的順序。這樣，BPM編排提供了一組工具用于高效排列支付處理。 交易/跟蹤可見性允許支付者、收款人或者任意其它具有指定訪問權(quán)的個人或公司看到支 付在整個處理支付流程中目前所在的位置。交易/跟蹤可見性通常通過在線用戶界面(例 如網(wǎng)頁界面等)實現(xiàn)。在事件450處，根據(jù)本實施例，經(jīng)標(biāo)準(zhǔn)化和經(jīng)處理的支付被轉(zhuǎn)換為匯款/結(jié)算目標(biāo) 結(jié)清格式。通過將支付請求最初標(biāo)準(zhǔn)化為標(biāo)準(zhǔn)格式，規(guī)定到目標(biāo)結(jié)清格式的轉(zhuǎn)化。另外，到 目標(biāo)結(jié)清格式的轉(zhuǎn)換提供通過在支付途徑確定處理時確定的支付通道的支付匯款。在事件460處，根據(jù)所確定的支付途徑對支付進(jìn)行匯款和結(jié)算。圖10提供了根據(jù) 本發(fā)明的實施例的示例性匯款/結(jié)算支付通道1000的框圖。匯款支付通道1000包括但不 限于支票支付1010、自動交換所(即，電子)支付1020、電報支付1030、世界國際金融電 訊學(xué)會(SWIFT)支付1040、借記卡/信用卡支付1050、商人支付1060、轉(zhuǎn)帳支付1070，并且 結(jié)算通道可以包括收集1070等。另外，可以實施其它匯款/結(jié)算支付通道選項1090，例如 考慮未來知道的結(jié)算和匯款選項。參考圖11，示出了根據(jù)本發(fā)明的實施例的、包括支付處理的確定和排列的金融支付處理的方法1100的流程圖。在事件1110處，從支付者那里收到金融支付交易請求。支 付者可以使用任意已知或?qū)碇赖闹Ц遁斎胪ǖ垒斎虢鹑诮灰渍埱?。支付輸入通道實?包括但不限于開放式金融交換(OFX)/移動、基于網(wǎng)頁的、交互語音響應(yīng)(IVR)/電話、銀行 中心、自動柜員機(jī)(ATM)、借記卡/信用卡、商人、支票、圖像、電報、自動交換所(ACH)等。在事件1120處，確定多個與支付請求關(guān)聯(lián)的支付處理。可以基于支付輸入通道、 支付途徑或支付類型和支付屬性確定支付處理。如前所述，支付屬性可以是支付者定義的 屬性、收款人定義的屬性或金融機(jī)構(gòu)定義的屬性。另外，屬性可以是存儲在數(shù)據(jù)庫中的預(yù)先 定義的屬性，或者屬性可以是在支付請求的開始或支付處理期間動態(tài)定義的。在事件1130處，確定支付處理的排列和順序。類似于確定支付處理，確定對處理 的排列可以基于支付輸入通道、支付途徑或者支付類型、和支付屬性。如前所述，支付屬性 可以是支付者定義的屬性、收款人定義的屬性或金融機(jī)構(gòu)定義的屬性。另外，屬性可以是存 儲在數(shù)據(jù)庫中的預(yù)先定義的屬性，或者屬性可以是在支付請求的開始或支付處理期間動態(tài) 定義的。在事件1140處，根據(jù)所確定的排列來執(zhí)行所確定的支付處理。在一個實施例中，處理發(fā)生在支付集中器中，支付集中器使得大量的支付處理基于支付類型發(fā)生。例如，支 付處理可以包括但不限于支付途徑確定處理、計劃的和/或重復(fù)的支付處理、借方和貸方 關(guān)系處理、支付驗證處理、批量支付處理、支付合法性處理、外匯兌換處理、金融風(fēng)險平估處 理、和/或支付異常處理。如前所述，對于支付處理的修改和/或排列可以基于一個或更多 個支付處理的結(jié)果發(fā)生在支付處理執(zhí)行期間。在事件1150處，通過所確定的支付類型向收款人提供金融支付。這里所描述的方法、設(shè)備、系統(tǒng)和計算機(jī)程序產(chǎn)品用于管理對金融支付的處理，尤 其是管理在提供支付處理的綜合支付集中器環(huán)境中管理對金融支付的處理，包括在不受支 付輸入通道影響的情況下確定支付途徑。根據(jù)文中公開的實施例，管理支付處理包括自動 確定支付處理以及自動確定對支付處理的排列。如此，文中描述的方法、系統(tǒng)和計算機(jī)程序 產(chǎn)品提供了高效和成本節(jié)約的支付處理的方法。雖然前面的內(nèi)容討論了示意性實施例，應(yīng)該知道，在不偏離由隨附權(quán)利要求限定 的所描述的方面和/或?qū)嵤├姆秶那闆r下可以對本發(fā)明進(jìn)行各種改變和修改。另外， 雖然描述的方面和/或?qū)嵤├脑梢砸詥螖?shù)的形式進(jìn)行描述或者在權(quán)利要求中限定， 但是也可以使用復(fù)數(shù)形式，除非文中明確聲明。另外，任意實施例的所有或者一部分都可以 使用任意其它實施例的所有或者一部分，除非文中另有說明。雖然描述和以附圖形式示出了某些示例性實施例，但是應(yīng)當(dāng)明白這些實施例只是 示意性的而不是用于限定本發(fā)明的范圍，本發(fā)明并未限定到所描述和示出的具體結(jié)構(gòu)和排 列，因為除了上面提到的這些內(nèi)容之外可以對其進(jìn)行各種其它的改變、組合、省略、修改和 替代。本領(lǐng)域技術(shù)人員明白在不偏離本發(fā)明的精神和范圍的情況下可以對描述的實施例進(jìn) 行各種適應(yīng)性修改。因此，應(yīng)明白，在隨附權(quán)利要求限定的范圍內(nèi)(而不限于這里所具體描 述的)可以實現(xiàn)本發(fā)明。
權(quán)利要求
一種用于處理金融支付的方法，該方法包括接收金融支付請求；確定與所述金融支付請求關(guān)聯(lián)的多個支付處理；確定對與所述金融支付請求關(guān)聯(lián)的多個支付處理的排列；根據(jù)所確定的排列執(zhí)行所述多個支付處理；以及提供與所述金融支付請求關(guān)聯(lián)的金融支付。
2.根據(jù)權(quán)利要求1所述的方法，其中接收金融支付請求進(jìn)一步包括從多個支付輸入通 道中的一個接收所述金融支付請求。
3.根據(jù)權(quán)利要求2所述的方法，其中執(zhí)行所述多個支付處理進(jìn)一步包括執(zhí)行所述多個 支付處理而不考慮支付輸入通道類型。
4.根據(jù)權(quán)利要求1所述方法，其中確定對多個支付處理的排列進(jìn)一步包括基于支付輸 入通道、支付類型或支付屬性中的至少一個確定對多個支付處理的排列。
5.根據(jù)權(quán)利要求4所述的方法，進(jìn)一步包括基于一個或更多個途徑規(guī)則確定對于支付 請求的支付途徑，其中支付途徑定義支付類型。
6.根據(jù)權(quán)利要求4所述的方法，其中基于支付屬性確定對多個支付處理的排列進(jìn)一步 將支付屬性定義為與支付者、收款人或金融機(jī)構(gòu)中的至少一個關(guān)聯(lián)。
7.根據(jù)權(quán)利要求1所述的方法，其中確定對多個支付處理的排列進(jìn)一步包括動態(tài)地確 定對與所述金融支付請求關(guān)聯(lián)的多個支付處理的排列。
8.根據(jù)權(quán)利要求7所述的方法，其中動態(tài)確定對多個支付處理的排列進(jìn)一步包括基于 多個支付處理中的一個或更多個的結(jié)果確定對多個支付處理的排列。
9.根據(jù)權(quán)利要求1所述的方法，其中確定對多個支付處理的排列進(jìn)一步包括確定兩個 或更多個支付處理的順序排序或者兩個或更多個支付處理的并行處理中的一個或更多個。
10.根據(jù)權(quán)利要求1所述的方法，其中確定多個支付處理進(jìn)一步包括基于支付輸入通 道、支付類型或支付屬性中的至少一個確定與所述金融支付請求關(guān)聯(lián)的多個支付處理。
11.根據(jù)權(quán)利要求10所述的方法，進(jìn)一步包括基于一個或更多個途徑規(guī)則確定對于支 付請求的支付途徑，其中支付途徑定義支付類型。
12.根據(jù)權(quán)利要求10所述的方法，其中基于支付屬性確定與所述金融支付請求關(guān)聯(lián)的 多個支付處理進(jìn)一步將支付屬性定義為與支付者、收款人或金融機(jī)構(gòu)中的至少一個關(guān)聯(lián)。
13.根據(jù)權(quán)利要求1所述的方法，其中確定多個支付處理進(jìn)一步包括動態(tài)確定與所述 金融支付請求關(guān)聯(lián)的多個支付處理。
14.根據(jù)權(quán)利要求13所述的方法，其中動態(tài)確定多個支付處理進(jìn)一步包括基于多個支 付處理中的一個或更多個的結(jié)果確定多個支付處理中的一個或更多個。
15.根據(jù)權(quán)利要求1所述的方法，其中確定多個支付處理進(jìn)一步包括確定多個支付處 理，其中所述支付處理包括支付途徑，管理將來日期的和循環(huán)的支付的啟動，借方和貸方相 關(guān)，認(rèn)證支付，處理批量金融支付請求，存儲支付歷史、將來日期的支付或循環(huán)的支付中的 至少一個，確保支付合法性，提供外匯兌換處理，提供金融風(fēng)險評估以及提供金融支付異常 應(yīng)對處理中的兩個或更多個。
16.一種用于處理金融支付的設(shè)備，該設(shè)備包括計算平臺，包括至少一個處理器和存儲器；以及支付處理模塊，被存儲在所述存儲器中，可由所述處理器執(zhí)行，并且包括多個支付處理子模塊，每個都用于執(zhí)行一個或更多個支付處理，和處理管理邏輯，用于確定多個與支付請求關(guān)聯(lián)的支付處理并且確定對于多個支付處理 的排列。
17.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述支付處理模塊用于從多個支付輸入通道接 收支付請求，并且其中多個支付處理子模塊用于執(zhí)行一個或更多個支付處理而不考慮支付 輸入通道類型。
18.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于基于支付輸入通 道、支付類型或支付屬性中的至少一個確定對于多個支付處理的排列。
19.根據(jù)權(quán)利要求18所述的設(shè)備，其中所述多個支付處理子模塊進(jìn)一步包括支付途徑 子模塊，所述支付途徑子模塊用于基于一個或更多個途徑規(guī)則確定對于支付請求的支付途 徑，其中支付途徑定義支付類型。
20.根據(jù)權(quán)利要求18所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于基于支付者定義 的支付屬性、收款人定義的支付屬性或者金融機(jī)構(gòu)定義的支付屬性中的一個或更多個確定 對多個支付處理的排列。
21.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于動態(tài)確定對多個 支付處理的排列。
22.根據(jù)權(quán)利要求21所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于基于多個支付處 理中的一個或更多個的結(jié)果確定對多個支付處理的排列。
23.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于確定兩個或更多 個支付處理的順序排序或者兩個或更多個支付處理的并行處理中的一個或更多個。
24.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于基于支付輸入通 道、支付類型或支付屬性中的至少一個確定與所述金融支付請求關(guān)聯(lián)的多個支付處理。
25.根據(jù)權(quán)利要求24所述的設(shè)備，其中所述多個支付處理子模塊進(jìn)一步包括支付途徑 子模塊，所述支付途徑子模塊用于基于一個或更多個途徑規(guī)則確定對于支付請求的支付途 徑，其中支付途徑定義支付類型。
26.根據(jù)權(quán)利要求24所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于基于支付者定義 的支付屬性、收款人定義的支付屬性或者金融機(jī)構(gòu)定義的支付屬性中的一個或更多個確定 多個支付處理。
27.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于動態(tài)確定與所述 金融支付請求關(guān)聯(lián)的多個支付處理。
28.根據(jù)權(quán)利要求27所述的設(shè)備，其中所述處理管理邏輯進(jìn)一步用于基于多個支付處 理中的一個或更多個的結(jié)果確定多個支付處理中的一個或更多個。
29.根據(jù)權(quán)利要求16所述的設(shè)備，其中所述多個支付處理子模塊進(jìn)一步包括支付途徑 子模塊、未來支付管理子模塊、借方和貸方子模塊、驗證子模塊、批量支付子模塊、支付數(shù)據(jù) 庫、合法性子模塊、外匯兌換子模塊、金融風(fēng)險評估子模塊、以及異常處理子模塊中的兩個 或更多個。
30.一種計算機(jī)程序產(chǎn)品，包括計算機(jī)可讀介質(zhì)，所述計算機(jī)可讀介質(zhì)包括第一組代碼，用于使計算機(jī)接收金融支付請求；第二組代碼，用于使計算機(jī)確定與所述金融支付請求關(guān)聯(lián)的多個支付處理；以及第三組代碼，用于使計算機(jī)確定對與所述金融支付請求關(guān)聯(lián)的多個支付處理的排列；第四組代碼，用于使計算機(jī)根據(jù)所確定的排列執(zhí)行多個支付處理；以及第五組代碼，用于使計算機(jī)提供與所述金融支付請求關(guān)聯(lián)的金融支付。
31.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中所述第一組代碼進(jìn)一步用于使計算 機(jī)從多個支付輸入通道中的一個接收金融支付請求。
32.根據(jù)權(quán)利要求31所述的計算機(jī)程序產(chǎn)品，其中第四組代碼進(jìn)一步用于使計算機(jī)執(zhí) 行多個支付處理而不受支付輸入通道類型的影響。
33.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中所述第三組代碼進(jìn)一步用于使計算 機(jī)基于支付輸入通道、支付類型或支付屬性中的至少一個確定對多個支付處理的排列。
34.根據(jù)權(quán)利要求33所述的計算機(jī)程序產(chǎn)品，其中所述第四組代碼進(jìn)一步用于使計 算機(jī)基于一個或更多個途徑規(guī)則確定對于支付請求的支付途徑，其中支付途徑定義支付類 型。
35.根據(jù)權(quán)利要求33所述的計算機(jī)程序產(chǎn)品，其中第三組代碼進(jìn)一步用于使計算機(jī)基 于支付者定義的支付屬性、收款人定義的支付屬性或者金融機(jī)構(gòu)定義的支付屬性中的至少 一個確定對多個支付處理的排列。
36.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中第三組代碼進(jìn)一步用于使計算機(jī)動 態(tài)確定對與金融支付請求關(guān)聯(lián)的多個支付處理的排列。
37.根據(jù)權(quán)利要求36所述的計算機(jī)程序產(chǎn)品，其中第三組代碼進(jìn)一步用于使計算機(jī)基 于多個支付處理中的一個或更多個的結(jié)果確定對多個支付處理的排列。
38.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中所述第三組代碼進(jìn)一步用于使計算 機(jī)確定兩個或更多個支付處理的順序排序或者兩個或更多個支付處理的并行處理中的一 個或更多個。
39.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中第二組代碼進(jìn)一步用于使計算機(jī)基 于支付輸入通道、支付類型或支付屬性中的至少一個確定與金融支付請求關(guān)聯(lián)的多個支付處理。
40.根據(jù)權(quán)利要求39所述的計算機(jī)程序產(chǎn)品，其中第四組代碼進(jìn)一步用于使計算機(jī)基 于一個或更多個途徑規(guī)則確定對支付請求的支付途徑，其中支付途徑定義支付類型。
41.根據(jù)權(quán)利要求39所述的計算機(jī)程序產(chǎn)品，其中第二組代碼進(jìn)一步用于使計算機(jī)基 于支付者定義的支付屬性、收款人定義的支付屬性或者金融機(jī)構(gòu)定義的支付屬性中的至少 一個確定與金融支付請求關(guān)聯(lián)的多個支付處理。
42.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中第二組代碼進(jìn)一步用于使計算機(jī)動 態(tài)確定與金融支付請求關(guān)聯(lián)的多個支付處理。
43.根據(jù)權(quán)利要求42所述的計算機(jī)程序產(chǎn)品，其中第二組代碼進(jìn)一步用于使計算機(jī)基 于多個支付處理中的一個或更多個的結(jié)果確定所述多個支付處理中的一個或更多個。
44.根據(jù)權(quán)利要求30所述的計算機(jī)程序產(chǎn)品，其中第二組代碼進(jìn)一步用于使計算機(jī)確 定多個支付處理，其中所述支付處理包括支付途徑，管理將來日期的和循環(huán)的支付的啟動， 借方和貸方相關(guān)，認(rèn)證支付，處理批量金融支付請求，存儲支付歷史、將來日期的支付或循環(huán)的支付中的至少一個，確保支付合法性，提供外匯兌換處理，提供金融風(fēng)險評估以及提供金融支付異常應(yīng)對處理中的兩個或更多個。
全文摘要
本發(fā)明涉及一種系統(tǒng)、方法和計算機(jī)程序產(chǎn)品，用于管理對金融支付的處理，尤其是管理在提供支付處理的綜合支付集中器環(huán)境中對金融支付的處理，包括在不受支付輸入通道影響的情況下確定支付途徑。根據(jù)文中公開的實施例，管理支付處理包括自動確定支付處理以及自動確定對支付處理的排列。如此，文中描述的方法、系統(tǒng)和計算機(jī)程序產(chǎn)品提供了高效和成本節(jié)約的處理支付的方法。
文檔編號G06Q20/00GK101826186SQ201010151539
公開日2010年9月8日 申請日期2010年2月11日 優(yōu)先權(quán)日2009年2月13日
發(fā)明者A·B·卡爾代羅尼, D·T·弗魯, E·多耶爾, G·C·博瑞格斯, K·坎特利, M·D·贊佐特, P·托賓, W·E·托馬斯二世 申請人:美國銀行公司