综合支付集中器系统中管理支付处理的系统、方法和程序的制作方法

专利名称：综合支付集中器系统中管理支付处理的系统、方法和程序的制作方法
技术领域：
文中公开的实施例一般地涉及用于管理金融支付处理的系统、方法和计算机程序 产品，更具体地涉及在综合支付集中器环境中动态选择和安排支付处理。
背景技术：
目前，在美国市场，基于途径的传统产品之后是金融支付处理。这意味着在金融机 构收到特定产品库之前指定支付。库支付处理发生在图像捕获之前并且包括一系列线性处 理步骤，其中接收的支付输入形式在很多种情况下与支付汇款/结算相同。例如，如果支付 是电子输入，那么产品库在多种情况下电子输出支付。因此，每种支付类型例如票据、图像、 电子、电报、自动交换所(ACH)等都有其自己的产品库和通道，因此在交易提交之前就选择 库。这些单独的产品库没有被完全地集成，这样它们就可以作为独立的系统自治地操作。在 这方面，特定的产品库需要特定的逻辑处理和处理硬件，基于该支付类型/产品设置库以 适应。国际支付系统稍微有些不同，因为这些支付被指定用于低价通道或者高价通道， 但是类似于美国支付处理，这些支付都是在传送之前预处理的。在成本效率、支付时间性或者其它支付因素方面，国内支付和国际支付都没有考 虑客户/支付者以及在一些情况中的支付处理金融机构。例如，当客户不关心用什么途径 进行支付时，它们通常关心收款人收到支付的速度。在大部分情况中，客户/支付者都希望 收款人能尽快收到支付，然而，在一些情况中，支付者希望延迟支付接受以确保在指定的支 付账户中有充足的资金。除了时间性方面，客户/支付者可能关心支付交易的质量或风险， 即，确保支付在指定时间和目的地和/或以客户/支付者支付花费的成本进行。从金融机 构的立场看，金融机构关心以最节省成本的方式进行支付，从而可以最大化它们的利益，同 时在时间和支付风险方面考虑客户的需求。因此，需要开发系统、方法和计算机程序产品等来更有效和低成本地处理金融支 付。期望的系统、方法和计算机程序产品等应当允许在综合支付处理系统中处理所有类型 的支付请求。另外，期望的系统、方法和计算机程序产品应当以高效方式处理支付请求，使 得对金融机构和客户(即，支付者和/或收款人)都节约成本。另外，期望的系统、方法和 计算机程序产品等应当允许客户/支付者基于每个支付或每个支付文件或者预先定义的 支付排列(arrangement)或者动态定义支付排列，从而在支付时间性、支付成本、支付质量 等方面满足客户/支付者的需求。另外，期望的系统、方法和计算机程序产品等应当允许金 融机构作出支付途径决定，其不但考虑了客户的/支付者的需求和关切，还考虑了金融机构对最小化与每个交易相关的成本的关切。而且，通过提供方法、系统和计算机程序产品等允许基于每个支付在预定的支付排列和/或动态排列支付中客户/支付者有更多的选项， 金融机构可以在支付处理中实现不同的价格点。

发明内容
为了提供对本发明实施例的基本理解，下文中提供了一个或更多个实施例的简要 概述。概述不是所有预期实施例的扩展性综述，其目的不是为了标识所有实施例的关键或 重要元件也不是为了描述任意或所有实施例的范围。唯一目的就是以简化形式提供一个或 更多个实施例的概念作为后面将要详述的序言。文中描述的方法、设备、系统和计算机程序产品用于管理支付处理，尤其是在综合 支付集中器环境中管理支付处理，其提供了不受支付输入通道影响的支付处理。根据本发 明公开的实施例，管理支付处理包括自动确定支付处理和自动确定支付处理的排列。文中 描述的排列另外可以作为支付处理的排列、流程或顺序。这样，支付处理可以被安排成顺序 处理、并行处理或者顺序和并行的组合处理。支付处理的确定和处理的排列可以在支付输 入通道、支付/结算类型和/或支付属性的基础上基于每个支付请求被动态地确定，支付属 性例如支付者定义的属性、收款人定义的属性和/或金融机构定义的属性。确定支付处理 和排列的动态特性允许基于之前处理的输出或者在进行支付处理时所定义的属性在处理 支付期间通过增加或删除支付处理或改变排列来改变支付处理。这样，文中描述的方法、系 统和计算机程序产品提供了对处理支付的高效和成本节约的方法。根据本发明的一个实施例，定义了一种用于处理金融支付的方法。该方法包括接 收金融支付请求以及确定对于与金融支付请求关联的支付处理和多个与金融支付请求关 联的支付处理的排列。文中使用的“排列，，可以是执行支付处理的顺序，可以是顺序、并行 或者顺序和并行的组合顺序。该方法进一步包括根据确定的排列执行多个支付处理并且提 供与金融支付请求关联的金融支付。支付处理可以包括但不限于支付途径，管理将来日期支付和重复支付的启动，贷 方和借方相关，验证支付，处理大量金融支付请求，存储至少一个支付历史，将来日期的支 付或者重复支付，确保支付合法性(compliance)，提供外汇兑换处理，提供金融风险评估， 提供金融支付异常应对处理等。根据方法的特定实施例，接收金融支付请求可以另外包括从多个不同支付输入通 道中的一个接收金融支付请求。在该实施例中，执行多个支付处理进一步包括执行多个支 付处理而不用管支付输入通道类型。根据方法的另一实施例，确定支付处理的排列可以进一步包括基于至少一个支付 输入通道、支付类型或支付属性确定支付处理的排列，在该实施例中，该方法进一步包括基 于一个或更多个途径规则确定对于支付请求的支付途径，其中支付途径定义了支付类型。 另外，基于支付属性确定支付处理的排列进一步包括基于支付者定义的支付属性、收款人 定义的支付属性或金融机构定义的支付属性确定支付处理的排列。根据方法的特定实施例，可以在支付处理的开始或者现行支付处理期间基于每个 支付请求动态确定支付处理的排列。例如，可以基于多个支付处理中的一个或更多个的结 果确定排列(即，重新排列)。
类似地，根据方法的其它实施例，确定支付处理进一步包括基于至少一个支付输 入通道、支付类型或支付属性确定与金融支付请求关联的支付处理。在该实施例中，方法可 以进一步包括基于一个或更多个途径规则确定支付请求的支付途径，其中支付途径定义了 支付类型。另外，基于支付属性确定支付处理进一步包括基于支付者定义的支付属性、收款 人定义的支付属性或金融机构定义的支付属性确定支付处理。根据方法的特定实施例，支付处理可以在支付处理开始或现行支付处理期间基于 每个支付请求动态确定。例如，可以基于多个支付处理中的一个或更多个的结果确定支付
处理。处理金融支付的设备定义了本发明的另一实施例。该设备包括一包含至少一个处 理器和存储器的计算平台。该设备还包括存储在存储器中的支付处理模块，其可由处理器 执行并且包括多个支付处理子模块，每个支付处理子模块都可用来执行一个或更多个支付 处理。支付处理模块进一步包括处理管理逻辑，用于确定与支付请求关联的多个支付处理 并且确定对于多个支付处理的排列。文中描述的排列可以是执行支付处理的顺序，可以是 顺序的、并行的或者二者的组合。根据设备的特定实施例，支付处理子模块可以包括但不限于支付途径子模块，将 来支付管理子模块，借方和贷方子模块，验证子模块，批量支付子模块，支付数据库，合法性 子模块，外汇兑换子模块，金融风险评估子模块，以及异常处理子模块。根据设备的另外实施例，支付处理模块用于从多个支付输入通道中接收支付请 求，多个支付处理子模块用于执行一个或更多个支付处理而不受支付输入通道的影响的类 型。在这方面，支付处理模块能够处理从不同的输入通道发起的支付请求。根据设备的其它可选实施例，处理管理逻辑进一步用于基于支付输入通道、支付 类型或支付属性中的至少一个确定对于多个支付处理的排列。在该实施例中，多个支付处 理子模块可以包括基于一个或更多个途径规则确定对于支付请求的支付途径的支付途径 子模块，其中支付途径定义了支付类型。另外，处理管理逻辑进一步用于基于一个或更多个 支付者定义的支付属性，收款人定义的支付属性或金融机构定义的支付属性确定对于多个 支付处理的排列。根据设备的另一实施例，处理管理逻辑在支付处理器开始时或者现行支付处理期 间基于每个支付请求动态确定对于多个支付处理的排列。例如，基于多个支付处理中的一 个或更多个的结果确定排列(即，重新排列)。在设备的另一实施例中，处理管理逻辑用于基于支付输入通道、支付类型或者支 付属性中的至少一个确定与金融支付请求关联的多个支付处理。在该实施例中，多个支付 处理子模块可以包括支付途径子模块，用于基于一个或更多个途径规则确定对于支付请求 的支付途径，其中支付途径定义了支付类型。根据设备的另一实施例，处理管理逻辑用于在支付处理开始或者在现行支付处理 期间基于每个支付请求动态确定支付处理。例如，可以基于一个或更多个支付处理的结果 确定支付处理。本发明的另一实施例提供了一种计算机程序产品，其包括计算机可读介质。该介 质包括第一组代码，用于使计算机接收金融支付请求，第二组代码，用于使计算机确定与金 融支付请求关联的多个支付处理，以及第三组代码，用于使计算机确定对与金融支付请求关联的多个支付处理的排列。该介质另外还包括第四组代码，用于使计算机根据确定的排 列执行多个支付处理，以及第五组代码，用于使计算机提供与金融支付请求关联的金融支 付。因此，文中提供的设备、系统和计算机程序产品用于管理金融支付处理，尤其是管 理综合支付集中器环境中的金融支付处理，其提供了支付处理以及支付途径的确定而不受 支付输入通道的影响。根据文中公开的实施例，管理支付处理包括自动确定支付处理和自 动确定支付处理的排列。如此，文中描述的方法、系统和计算机程序产品提供了处理支付的 高效和成本节约的方法。为了实现上文和相关的目的，一个或更多个实施例包括后文中完整描述的特征尤 其是在权利要求中提出的特征。下面的描述和附图详细列出了一个或更多个实施例的一些 示意性特征。然而这些特征是可采用各种实施例的原理的各种方式中的少量几种的示例， 并且该描述目的在于包含所有这些实施例以及它们的等同物。


以通用术语描述了本发明的实施例，现在将参照附图，附图并不必然是按比例绘 制的，在附图中图1是根据本发明的一个实施例的被配置为在支付集中器环境中提供支付处理 管理的设备的框图；图2是根据本发明的一个实施例的被配置为在支付集中器环境中提供支付处理 管理的设备的详细框图；图3是根据本发明的一个实施例的被配置为提供基于规则的金融支付途径的设 备的详细框图；图4是根据本发明的一个实施例的用于处理金融支付请求的方法的流程图；图5是根据本发明的一个实施例的金融支付输入通道的框图；图6是根据本发明的另一实施例的支付排列属性/规则资源的框图；图7是根据本发明的实施例的包含可选处理的特定支付处理的框图；图8是根据本发明的实施例的支付验证处理的框图；图9是根据本发明的实施例的途径规则的实例的框图；图10是根据本发明的另一实施例的汇款和结算通道的框图；图11是根据本发明的另一实施例的在支付集中器环境中提供支付处理管理的方 法的流程图的框图。
具体实施例方式下文中本发明的实施例将结合附图进行完整地描述，其中示出了本发明的一部分 但不是所有的实施例。实际上，本发明可以以多种不同形式体现，并且不应当限于文中提出 的实施例；相反，提供这些实施例使得本发明可以满足可应用的法律需求。在下面的描述 中，为了解释清楚，提出了大量的特定细节从而提供对一个或更多个实施例的透彻理解。然 而，明显的是，可以在没有这些特定细节的情况下实施这些实施例。全文中相同的附图标记 表示相同的元件。
根据包括大量设备、组件、模块等的系统或者设备提供了各种实施例或者特征。可以理解和明白的是，各种系统或者设备可以包括额外的设备、组件、模块等和/或可以不包 括在附图中所讨论的所有的设备、组件、模块等。也可以使用这些手段的组合。结合文中公开的实施例描述的方法或者算法的步骤和/或动作可以直接在硬件、 由处理器执行的软件，或者二者的结合中实现。软件模块可以驻存在RAM存储器、闪存、ROM 存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM或者现有技术中已 知的任意其它形式的存储器介质。示例性的存储器介质可以耦接到处理器，以便处理器可 以从存储器介质读取信息以及向其中写入信息。可替代的，存储器介质可以集成到处理器 中。另外，在某些实施例中，处理器和存储器介质可以驻存在专用集成电路(ASIC)中。可 替代的，处理器和存储器介质可以在计算设备中作为分立的组件驻存。另外，在某些实施例 中，方法或算法的时间和/或动作可以在机器可读介质和/或计算机可读介质上作为一个 编码和/或指令或者其任意组合或集合驻存，其可以并入到计算机程序产品中。在一个或更多个实施例中，可以在硬件、软件、固件或其任意组合中实现文中描述 的功能。如果在软件中实现的话，这些功能可以作为计算机可读介质上的一个或更多个指 令或者编码存储或者传送。计算机可读介质包括计算机存储介质和通信介质，其包括便于 计算机程序从一个地方传输到另一个地方的任意介质。存储器介质可以是能够由计算机访 问的任意可用介质。举例而言(并非限制)，这种计算机可读介质包括RAM、ROM、EEPROM、 CD-ROM或者其它光盘存储器、磁盘存储器或者其它磁存储器设备、或者任意其它能够以指 令或者数据结构形式传送或者存储需要的程序编码以及可由计算机访问的介质。而且，任 意连接都可以叫做计算机可读介质。例如，如果软件是从网站、服务器或者其它使用同轴缆 线、光纤缆线、双扭线、数字用户线(DSL)或者例如红外线、无线电和微波的无线技术的远 程资源传送的，那么同轴缆线、光盘缆线、双扭线、DSL或者例如红外线、无线电或微波的无 线技术都包含在介质的定义中。这里使用的“磁盘(disk)”和“光盘(disc)”包括高密度 光盘(⑶)、激光盘、光盘、数字通用光盘(DVD)、软盘和蓝光盘，其中磁盘通常以磁的方式再 现数据，而光盘通常利用激光以光的方式再现数据。上述内容的组合也应当包含在计算机 可读介质的范围内这样，这里描述的方法、设备、系统和计算机程序产品用于管理金融支付处理，尤 其用于在综合支付集中器环境中管理金融支付处理，其中提供了支付处理，在某些实施例 中，确定支付途径而不受支付输入通道的影响。根据文中描述的实施例，管理支付处理包括 自动确定支付处理和自动确定支付处理的排列。文中描述的排列可以是支付处理的排列、 流程或顺序。这样，支付处理可以排列成顺序发生、并行发生或者以顺序处理和并行处理的 任何组合发生。确定支付处理和排列处理可以基于支付输入通道、支付/结算类型和/或 支付属性(例如支付者定义的属性、收款人定义的属性和/或金融机构定义的属性)在每 个支付请求的基础上动态地确定。支付处理的动态确定特性和排列允许支付处理基于之前 处理的结果或者正在进行支付处理时所定义的属性，通过在支付处理期间增加或删减支付 处理或者改变排列来改变支付处理。这样，文中描述的方法、系统和计算机程序产品使得支 付处理高效和成本节约。参考图1，描述了根据本发明的实施例提供的用于金融支付处理的设备100的框 图。如前所述，设备100可以包括一个或更多个设备。在多个设备实施例中，设备可以是在相互联网的环境中。设备100包括计算平台110，其具有至少一个处理器120和存储器130。设备100的存储器130包括支付处理模块150，文中也称作支付集中器，其包括多 个支付处理子模块152。根据文中描述的实施例，支付处理模块150是能够进行处理支付而 不受支付输入通道的影响的综合支付处理系统。在本发明的一个实施例中，不受支付输入 通道影响的处理支付请求的能力是通过将支付请求的最初格式转换为标准化或正规化格 式而提供的。支付处理子模块152可以包括但不限于能够进行支付途径确定、计划将来的和/ 或重复的支付、借方和贷方相关、支付验证、批量支付处理、支付数据存储器、支付合法性检 查、外汇兑换处理、支付风险评估、支付异常处理等的模块。每个支付子模块152可以包括 一个或更多个支付处理154，它们可以作为支付请求的一部分被请求或者被执行。支付处理模块150还包括处理管理逻辑140，用于基于每个支付请求确定可应用 到支付请求上的支付处理154和支付处理排列142。如文中描述的处理排列142可以是进 行处理的流程、排列和/或顺序。这些处理可以被排列为顺序发生、并行发生、或者以顺序 处理和并行处理的组合发生。在本发明的一个实施例中，支付处理和排列可以在支付处理 开始时确定并在整个处理期间保持静态不变。在本发明的其它实施例中，支付处理和排列 可以在整个支付处理期间被确定或者重新评估。例如，一个处理的结果可以造成支付处理 的增加或删减和/或处理的结果可以规定支付处理的重新排列。在这方面，处理的确定和 /或处理的排列可以在整个支付处理期间保持为动态。在本发明的特定实施例中，支付处理154的确定和/或支付处理的排列142可以 基于支付输入通道、支付类型或支付属性。支付属性可以由支付者、收款人或执行支付处理 的金融机构定义。支付属性可以是存储在支付者、收款人和/或金融机构数据库中的预先 定义的属性，或者支付属性可以是在支付请求处理期间定义的动态属性。图2提供了根据本发明的另一实施例的设备100的更详细描述。除了提供更为详 细的描述，图2突出了各种可选实施例。设备100可以包括一个或更多个计算设备的任意 类型和/或组合，例如个人计算机、膝上/便携计算机、无线或手持计算设备、服务器等。计 算平台110用于接收和执行模块、例程和应用，例如支付处理模块150、处理管理逻辑140 等。计算平台110包括存储器130，其可以包括易失性和非易失性存储器，例如只读和/或 随机存取存储器(RAM和R0M)、EPR0M、EEPR0M、闪存卡或者任意计算平台通用的存储器。另 夕卜，存储器130可以包括一个或更多个闪存单元，或者可以是任意二级或三级存储器设备， 例如磁介质、光介质、磁带、或者软盘或硬盘。另外，计算平台110还包括处理器120，其可以是专用集成电路(”ASIC”)，或者其 它芯片集、处理器、逻辑电路、或者其它数据处理设备。处理器120或其它例如ASIC的处理 器可以执行应用程序接口( “API”)层200，其与存储在设备100的存储器130中的任何驻 存的程序(例如支付处理模块150、处理管理逻辑140等)接口。处理器120包括在硬件、固件、软件及其组合中实现的各种处理子系统220，其使能操作设备100的功能以及网络上设备的可操作性。例如，处理子系统220允许启动并且 保持与其它网络设备之间的通信和数据交换。设备130的存储器130包括支付处理模块150，其包括多个支付处理子模块152。 如前所述，支付处理模块150是能够在不顾支付输入通道的情况下处理支付的综合支付处理系统。在本发明的一个实施例中，通过将支付请求的启动格式转化为标准化或正规化格 式，提供不管支付输入通道的处理支付请求的能力。另外，结合图3进行详细讨论的支付途 径确定子模块170提供确定支付途径(即，支付类型或结算/汇款输出)而不受支付输入 通道的影响。这样，支付输入通道可以不同于支付输出通道。应当注意描述的支付处理模块150是一个单独的模块，但是根据本实施例，该模 块可以包括多个模块，并且多个模块可以包含在各种不同的设备中。这样，在支付处理模块 150中描述的例程、应用、数据库和逻辑可以包含在多个模块中。同样，关于支付处理模块 150所讨论的规则和逻辑可以被包含或者实现在多个应用或例程中。如图2所示，支付处理子模块152可以包括但不限于支付途径确定子模块170、计 划和循环支付子模块710、关系(correlation)子模块720、支付验证子模块730、批量支付 处理子模块740、支付数据库/仓库750、支付合法性子模块810、外汇兑换子模块820、支付 风险评估子模块830、和/或支付异常处理子模块840等。每个支付子模块152可以包括一 个或更多个支付处理154，其作为支付请求的一部分被要求和执行。结合图4描述了支付途径确定子模块170。计划和循环支付子模块710管理将来 日期的和循环支付的启动，包括对于计划/循环支付使用预先定义的定制模板设置。借方/ 贷方关系子模块720包括定时和顺序处理以确保原始支付关联的关系。在这方面，当在支 付项级处理时单独的信用被关联和平衡(balance)到原始的借方。验证子模块730用于验证支付和相关的账户属性以确保支付的正结算。批量支付 子模块740用于对于大的支付文件聚集和优化到外部系统的通信，所述大的支付文件具有 多个单独支付项，而多个单独支付项具有相同的记入账户。合法性处理子模块810用于确保支付的反洗钱。合法性处理可以包括已知的与违 法支付处理关联的个人、公司等的海外资金控制办公室(OFAC)名单的安全检查。外汇兑换 /单一欧元支付区(SEPA)子模块820，用于最大化外币汇率，提供多货币支持并确保符合 SEPA规则和规章。金融风险评估子模块830用于提供对于整个支付处理的信用和风险管理。在这方 面，金融风险评估处理可以提供债务风险评估分数等，其接下来由基于规则的途径确定用 于限制或规定(mandate)可以实现的汇款/结算途径类型。例如，如果确定金融风险为高， 途径确定可以将电报支付排除作为汇款/结算支付选项。异常处理子模块840用于提供对所有支付类型的集中式异常处理和管理。异常处 理考虑了支付处理中的错误，例如格式化错误，并且可以实现对于普通异常/错误的自动 修正。对异常的自动修正需要较少的人工干预并提高了直通支付处理率。在前面结合图1描述的，支付处理模块150还包括处理管理逻辑140，用于基于每 个支付请求确定可应用于支付请求的支付处理154以及支付处理排列142。处理可以安排 成顺序发生、并行发生、或者以顺序处理和并行处理的组合发生。在本发明的一个实施例 中，支付处理和排列可以在支付处理的开始时确定并且在整个处理期间保持静态不变。在 本发明的其它实施例中，支付处理和排列可以在整个支付的处理期间被确定或者被重新评 估。例如，一个处理的结果会造成支付处理的增加或删减，和/或处理的结果会指示支付处 理的重新排列。在这方面，处理的确定和/或处理的排列可以在整个支付的处理期间保持 动态变化。
在本发明的特定实施例中，支付处理154的确定和/或支付处理的排列142可以 基于支付输入通道、支付类型或支付属性。支付输入通道可以包括但不限于开放式金融交换(OFX)/移动、网页、交互语音响 应(IVR)/电话、银行中心、自动柜员机(ATM)、借记卡/信用卡、商人、支票、图像、电报、自动 交换所(ACH)等。支付属性可以由支付者、收款人或者执行支付处理的金融机构定义。支付属性250 可以是支付者定义的/收款人定义的属性260和/或金融机构/银行定义的支付属性270。 支付者定义的/收款人定义的支付属性260可以包括 但不限于价格262、时间264、风险/ 质量266、汇款要求267、目的地268或者任意其它可以应用于处理管理的适当属性269。金 融机构/银行定义的支付属性270可以包括但不限于成本272、时间274、风险/质量276、 汇款要求277、目的地278或者任意其它可应用于处理管理的其它适当属性279。支付属性260和270可以是存储在支付者、收款人和/或金融机构数据库中的预 先定义的属性，或者支付属性可以是在支付请求处理期间定义的动态属性。这样，存储器 130可以包括用于存储支付属性的支付者简档数据库280、收款人简档数据库290和/或金 融机构/银行数据库294。这样，支付者简档数据库280可以包括多个支付者/客户特征 282，并且每个特征282包括与支付者关联的支付属性260。收款人简档数据库290可以包 括多个收款人简档292，并且每个特征292包括与收款人关联的支付属性260。金融机构/ 银行数据库294可以包括与输入支付请求类型关联的支付属性270或者任意其它关联。图3提供了根据本发明的其它可选实施例的设备100的更详细的描述。设备100 的存储器130可选地包括支付转换模块210，支付转换模块210与处理器120通信并用于标 准化支付请求然后将所处理的支付请求转换为所确定的支付途径/类型的格式。支付类型 的标准化允许支付模块140使用类似的处理和技术在支付仓库类型环境中处理所有类型 的支付请求。这样，支付转换模块210包括由处理器120执行的标准化逻辑230并且用于 将进入的支付请求转换/标准化为经标准化的格式，例如国际标准化组织(ISO) 20022通用 金融工业信息方案等等。支付转换模块210另外还包括支付格式化逻辑240，支付格式化逻 辑240可由处理器120执行并且用于将后支付处理器、经标准化的格式转换为所确定的支 付途径/结算类型的格式。支付处理模块150用于接收支付指令，验证支付并且确定用于支付的途径。根据 本发明的当前可选实施例，支付处理模块140用于基于每个支付确定支付途径，以便基于 与支付和/或支付者和/或收款人和/或处理支付的金融机构相关的特征确定汇款和结算 支付的方式。在这方面，可以通过支付者、收款人和/或金融机构在支付处理的成本、支付 处理的时间性和支付处理的质量/风险方面实现支付优化。对于支付转换模块210和支付处理模块150描述了单独的模块，但是根据本实施 例，这些模块可以包括多个模块并且多个模块可包含在各种不同的设备中。这样，关于支付 转换模块210和支付处理模块150所描述的例程、应用、数据库和逻辑可被包含在多个模块 中。同样，关于支付转换模块210和支付处理模块150所讨论的规则和逻辑可以被包含在 多个应用或例程中或者在多个应用或例程中实现。支付处理模块150包括途径规则数据库158，途径规则数据库158包括一个或更多 个途径规则160。途径规则160可以与支付途径因素(例如，但不限于，处理支付的价格/成本、处理支付的时间要求、质量/风险要求或者处理支付的容差(即，保证汇款和结算，中 止支付的能力等)、支付目的地等相关。这样，途径规则160可以包括一个或更多个成本/ 价格相关途径规则162、一个或更多个时间相关途径规则164、一个或更多个风险/质量相 关途径规则166、一个或更多个目的地相关途径规则168或其它途径规则169。成本/价格相关途径规则162可以定义基于支付者和/收款人愿意承担的对于正 进行的支付的价格、或者金融机构愿意承担的或向支付者收取的对于处理支付的成本选择 汇款结算类型180。在这方面，不同的汇款结算类型可以与不同的支付价格关联以便一种汇 款/结算类型的支付在支付价格上比其它汇款/结算类型高或低。时间相关途径规则164可以定义为了完成支付交易，基于支付者的、收款人的和 /或金融机构的可接受的时间，选择哪种汇款/结算类型180。在大多数情况中，支付者和/ 或收款人期望尽量及时地完成支付，而处理支付的金融机构期望将汇款/结算延迟尽量长 的时间段。然而，应当明白，在大多数情况中，支付者关心尽量及时地进行支付，而在其它情 况中，支付者可能期望延迟支付时间(例如，如果要从其进行支付的账户中当前没有足够 的资金)。与风险/质量相关的途径规则166可以定义基于确保或保证将会进行支付的能 力(换句话说，提供给支付的服务等级或者与不同支付汇款/结算类型关联的失败几率数) 选择哪种汇款/结算类型180。其它风险/质量途径规则166可以定义支付处理期间的返 回或中止支付的能力、数据核对能力，例如如何平衡资金或者任意与质量或风险属性关联 的其它途径规则，所述质量或风险属性由支付者、收款人和/或进行支付处理的金融机构 定义。
与目的地相关的途径规则168可以定义基于支付目的地选择哪种汇款/结算类 型180。例如，国内支付可以规定汇款/结算的某些类型，同时国际支付可以规定其它类型
的汇款/结算。其它途径规则169可以另外定义其它用于选择汇款/结算类型180的规则。可以 根据进行支付处理的金融机构、支付者和/或收款人的需求规定其它途径规则。支付模块150另外包括支付途径确定子模块170，支付途径确定子模块170由处理 器120执行并且用于从多于一个可选支付类型中基于一个或更多个途径规则的应用确定 对于支付交易的支付途径(即，支付类型180，文中也称做支付途径)。在应用多于一个途 径规则来确定汇款结算类型180的情况中，支付途径确定子模块170可以用于确定途径规 则的优先级和/或作出适当的途径确定，其确保满足支付者/收款人和/或进行支付处理 的金融机构的需求。支付途径确定子模块170用于将一个或更多个支付属性/支付规则250应用于一 个或更多个途径规则160上以确定支付途径/类型180。支付属性可以是支付者定义的/ 收款人定义的支付属性260和/或金融机构/银行定义的支付属性270。支付者定义的/ 收款人定义的支付属性260可以包括但不限于价格262、时间264、风险/质量266、汇款要 求267、目的地268或任意其它可应用到途径规则上的适当属性269。金融机构/银行定义 的支付属性270可以包括但不限于成本272、时间274、风险/质量276、汇款要求277、目的 地278或者任意可应用到途径规则上的其它适当属性279。支付属性/规则250可以由支付者、收款人或金融机构在支付请求时动态定义或者支付属性/规则250可以是与支付者、收款人和/或金融机构关联的预先定义的属性。另 夕卜，在某些实施例中，支付属性/规则可以由支付者、收款人和/或金融机构在支付处理期 间动态定义。这样，存储器130可以包括支付者简档数据库280、收款人简档数据库290和 /或金融机构/银行数据库294用于存储支付属性/规则，或者支付模块可以与另一辅助设 备的存储器(图3未示出)通信，所述存储器包括支付者简档数据库280、收款人简档数据 库290和/或金融机构/银行数据库294用于存储支付属性/规则。这样，支付者简档数 据库280包括多个支付者/客户简档282并且每一个简档282包括与支付者关联的支付属 性/规则260。收款人简档数据库290可以包括多个收款人简档292，每个简档292包括与 收款人关联的支付属性/规则260。金融机构/银行数据库294可以包括与输入支付请求 类型或任意其它相关类型关联的支付属性/规则270。如前所述，支付途径确定子模块170可以从多于一种备选中确定任何适当的支付 途径180类型。支付途径/类型可以包括支票/票据300、信用卡/借记卡302、电子/ACH 304、电报306、SffIFT 308、商人310、转帐312或任意其它汇款结算支付途径/类型314。 一种备选支付途径包括两个或更多个支付途径类型。例如，支票/票据300或借方/贷方 302包括一种备选支付途径、SWIFT 308或者转帐312包括其它备选支付途径和电报306或 SffIFT 308或商人310包括另一备选支付途径。图4提供了根据本发明的一个实施例的用于包括支付处理的确定和支付处理的 排列的支付处理组合方法400的流程图。在事件410，通过指定的输入通道输入支付请求。 图5提供了支付输入通道500的各种实例的框图。应当注意图5示出的支付输入通道500 仅仅是示例，并不意欲构成限制。支付输入通道500可以包括客户(即，个人、接合点等) 支付输入通道510和商人/前端支付输入通道530。客户支付输入通道510提供了客户到 商人支付输入和/或客户到消费者(即，消费者到消费者)支付输入。商人/前端支付输 入通道530提供了商人到商人支付输入和/或商人到消费者支付输入。客户支付输入通道是用户接口，可以包括但不限于开放式金融交换(OFX)/移动 支付输入通道512(通常可以在手持设备等上操作)；基于网页支付输入通道514，例如因特 网或者公司网站，其通常用于接收自动交换所(ACH)请求、电报支付请求、帐单支付等；电 话/交互式语音响应(IVR)支付输入通道516 ；银行中心支付输入通道(个人)518 ；以及自 动柜员机(ATM)支付输入通道520。商人/前端输入通道530包括但不限于销售点支付输入通道532，例如信用卡/ 借计卡刷卡等；图像交换支付输入通道534 ；远程储蓄支付输入通道536 ；批量文件消息支 付输入通道538 ；以及直回(straight back)办公室集成输入通道540，其中商业应用直接 调用/访问金融机构支付引擎以发起交易。再参考图4的方法400，在事件420处，建立了支付排列属性/规则。支付排列属 性/规则是可配置的数据，其与消费者支付者/收款人或者公司支付者/收款人关联并随 后被支付处理集中器用于处理支付请求的各个方面。图6提供了支付排列规则/属性资源 600的各个实例的框图。资源600可以包括但不限于收款人简档/设置610。收款人简档 /设置610可以是收款人要接收的特定支付的动态设置。例如，收款人接收支付即将到来的 通知，并且通过适当的指定通道(例如通过网站等)收款人配置支付属性/规则，例如对于 支付的时间要求等。可替代的，收款人可以具有预先定义的支付简档，其可以被存储在预先定义支付属性/规则的可访问的收款人简档数据库中。支付排列规则/属性资源600可以另外包括货品计价和由支付者和/或收款人发 出的支付报告620，其定义了用于特定支付或一系列支付的支付排列属性/规则，例如支付 风险/质量、支付目的地等。资源600另外还包括支付警告和/或支付通知630，其通常与 特定支付或一系列支付相关，并且定义由支付者、收款人或处理支付交易的金融机构具体 指定的支付排列规则。支付排列规则/属性资源600可以包括支付者简档/设置640。支付者简档/设 置640可以是支付者请求的对于特定支付的动态设置。可替代的，支付者可以具有预先定 义的支付简档，其可被存储在预先定义支付属性/规则的可访问的支付者简档数据库中。再次参考图4的方法400，在事件430处，支付请求被转换(也称作标准化)为标 准格式以允许处理所有不同支付而不用考虑输入通道。如前所述，根据特定实施例，标准化 格式可以根据ISO 20022通用金融工业信息方案格式。传统的已知的支付处理中每个支付 输入通道都需要用于处理支付的指定库。根据本实施例，转换到标准格式允许综合支付处 理一般地发生而不用考虑支付输入通道的类型。在事件440处，支付处理发生在文中称作支付处理模块或支付集中器的位置。基 于支付请求的转换/标准化，支付集中器能够处理所有类型的支付输入请求。应当注意，虽 然在支付处理块中示出的事件(事件442，444，446)以顺序方式发生，根据本实施例，这些 事件可以以支付集中器所确定的任何相继或连续的顺序发生，从而优化支付处理。应当注意关于事件440所示出并且在文中被描述为在支付引擎中发生的例程、模 块、应用和函数可以被其它应用访问或者通过其它应用实现，所述其它应用例如为没有实 现支付引擎等的其它支付处理应用。在这方面，其它应用可以根据需要访问特定例程、模 块、应用和函数。例如，如果另外的支付处理应用要求符合反洗钱法形式的支付验证，应用 可以访问和实现支付集中器的特定部分，而不是实现支付集中器中的多个应用或支付集中 器全部。支付处理可以包括在事件442处接收支付指令，例如支付属性/规则、货品计价/ 报告书、警告、通知等，它们被用于作出支付处理决定。在事件443处，确定支付处理和排列。如前所述，支付处理和排列可以基于支付输 入通道、支付类型和/或支付属性。支付属性可以是收款人定义的属性、支付者定义的属性 和/或金融机构定义的属性。属性可以是与收款人或支付者简档关联的预先定义的属性， 或者属性可以是在支付处理期间或者其附近定义的动态属性。应当注意在支付处理和排列 至少部分基于支付类型的情况中，支付途径(事件448)的确定可以先于随后的支付处理的 确定和随后的支付处理的排列。在这方面以及前面所述，支付处理的确定和支付处理的排 列不限于在支付集中器内的支付处理开始处发生，相反，可以在处理中的任何阶段或者时 间点发生。在事件444处，特定支付处理基于当前支付类型在一个或子模块中发生。图7是 详细示出根据本发明的实施例可在支付集中器处实现的的各种示例性具体支付处理子模 块700的框图。应当注意，图7中突出的具体支付处理子模块700仅仅是示例而不意欲构 成限制。另外，在一些实施例中，可以基于每个支付在支付集中器处确定支付处理的顺序， 以增加支付处理模型的整体效率和有效性。
具体支付处理子模块700可以包括计划和重复支付子模块710。计划和重复子模 块710管理将来日期和重复支付的启动，包括使用用于计划/重复支付的预先定义的定制 模板设置。另外，具体支付处理子模块700可以包括贷方/借方关系子模块720，其包括定 时和顺序处理以确保最初支付关联的关系。在这方面，当在支付项级处理时个人借方与最 初的贷方关联和平衡。具体支付处理子模块700可以包括验证子模块730用于验证支付和关联的账户 属性以确保支付正结清。另外，具体支付处理子模块700可以包括批量支付子模块740，用 于对于大的支付文件聚集和优化与外部系统的通信，所述大的支付文件具有多个单独支付 项，而多个支付项具有相同的过帐(postingaccounts)。而且，具体支付处理子模块700可 以包括支付仓库/数 据库750，用于存储将来日期的支付、支付历史、重复支付模块等。再次参考图4的方法400，在可选事件445处，基于事件444处进行的支付处理的 结果，可以进行支付处理调整，其可以包括增加或删减支付处理或修改/重新排列支付处 理的顺序或流程。支付处理(事件440)还包括支付的验证处理446。图8是示出根据本发明的实施 例可以在支付集中器处实现的各种示例性验证处理子模块800的框图。应当注意，图8突 出的具体验证处理子模块800仅仅是例子而不意欲构成限制。另外，在一些实施例中，可以 基于每个支付在支付集中器中确定验证处理的顺序，用于提高支付处理模型的整体效率和 有效性。验证处理子模块800可以包括合法性处理子模块810用于确保符合反洗钱法。合 法性处理可以包括与违法支付处理关联的个人、公司等的海外资金控制(OFAC)名单的安 全检查。另外，验证处理子模块800包括外汇/单一欧元支付区(SEPA)子模块820，用于最 大化外币汇率，提供多货币支持并确保符合SEPA规则和规章。另外，验证处理子模块800可以包括金融风险评估子模块830，用于提供整个支付 处理的信用和风险管理。在这方面，金融风险评估处理可以提供债务风险评估分数等，其接 下来由基于规则的途径确定用于定义或批准(mandate)可以实现的汇款/结算途径类型。 例如，如果确定金融风险为高，途径确定可以将电报支付排除作为汇款/结算支付选项。而且，验证处理子模块800可以包括异常处理子模块840，用于提供所有支付类型 的集中异常处理和管理。异常处理考虑了支付处理中的错误，例如格式化错误等，并且可以 实现对于常见异常/错误的自动修正。对异常的自动修正使得较少需要人工干预并且改善 直通支付处理率。再次参考图4的方法，在可选事件447处，基于事件446上进行的支付处理的结 果，可以作出支付处理调节，可以包括增加或删减支付处理或者修改/重新排列支付处理 的顺序或流程。支付处理(事件440)可以包括基于规则的途径确定处理448。根据本发明的实 施例，图9提供可以在支付途径确定处理中实现的示例性途径规则900的框图。仅仅通过 实例示出途径规则。应当注意对于任一个途径确定处理来说可以应用一个或更多个途径规 贝U。给予一个或更多个规则的优先权可以基于支付者简档数据、收款人简档数据、通知、警 告、金融机构规则等等。途径规则900可以与支付途径因素相关，例如但不限于处理支付 的价格/成本、处理支付的时间要求、处理支付的质量/风险或者容差(即，确保汇款和结算、中止支付的能力等)、支付目的地等。因此，途径规则900可以包括一个或更多个时间相 关的规则910、成本/价格相关的途径规则920、一个或更多个风险/质量相关的途径规则 930、一个或更多个目的地相关的途径规则940或其它支付者/收款人定义的途径规则950。如前所述，时间相关途径规则910可以定义基于支付者、收款人和/或金融机构 对于完成支付交易的可接受的时间选择哪种汇款/结算类型180。在多数情况中，支付者 和/或收款人期望尽量及时地完成支付，而处理支付的金融机构期望将汇款/结算延迟尽 量长的时间段。成本/价格相关途径规则920可以定义基于支付者和/或收款人愿意承 担的对于支付的价格、或者金融机构愿意承担或向支付者收取的对于处理支付的成本选择 哪种汇款/结算类型180。风险/质量相关途径规则930可以定义基于确保或保证将进行支付的能力(换 句话说，提供给支付的服务等级或者与不同支付汇款/结算类型关联的可接受的失败几率 数)选择哪种汇款/结算类型180。其它风险/质量途径规则166可以定义在支付处理期 间返回或中止支付的能力、数据核对能力，例如如何平衡资金，或者任意其它与由支付者、 收款人和/或进行支付处理的金融机构定义的质量或风险属性相关的途径规则。目的地相 关途径规则940可以定义基于支付目的地选择哪种汇款/结算类型180。例如，国内支付 可以规定某种汇款/结算类型，同时国际支付可以规定其它的汇款/结算类型。
支付者/收款人定义的规则950可以另外规定其它的用于选择汇款/结算类型的 规则。可以在临近支付请求时动态定义支付者/收款人定义的途径规则950或者在支付者 或收款人简档中预先定义支付者/收款人定义的途径规则950。在多数情况中，支付者或收 款人定义的途径规则将优先于(override)其它任意途径规则。再次参考图4的方法400，支付处理可以包括其它处理(图4中未示出)，例如 汇款报告、业务处理管理(BPM)编排、交易跟踪/可见性等。汇款报告向相关服务提供 汇款的电子报告；汇款报告的实例包括但不限于活期存款帐号(DDA)报告、帐号核对 (reconciliation)报告、平衡和交易报告等。BPM编排用于确定在支付集中器中进行处理 的顺序、确定和管理向支付仓库传递信息等。基于支付输入通道、支付属性/规则或所确定 的支付途径确定进行支付的顺序。这样，BPM编排提供了一组工具用于高效排列支付处理。 交易/跟踪可见性允许支付者、收款人或者任意其它具有指定访问权的个人或公司看到支 付在整个处理支付流程中目前所在的位置。交易/跟踪可见性通常通过在线用户界面(例 如网页界面等)实现。在事件450处，根据本实施例，经标准化和经处理的支付被转换为汇款/结算目标 结清格式。通过将支付请求最初标准化为标准格式，规定到目标结清格式的转化。另外，到 目标结清格式的转换提供通过在支付途径确定处理时确定的支付通道的支付汇款。在事件460处，根据所确定的支付途径对支付进行汇款和结算。图10提供了根据 本发明的实施例的示例性汇款/结算支付通道1000的框图。汇款支付通道1000包括但不 限于支票支付1010、自动交换所(即，电子)支付1020、电报支付1030、世界国际金融电 讯学会(SWIFT)支付1040、借记卡/信用卡支付1050、商人支付1060、转帐支付1070，并且 结算通道可以包括收集1070等。另外，可以实施其它汇款/结算支付通道选项1090，例如 考虑未来知道的结算和汇款选项。参考图11，示出了根据本发明的实施例的、包括支付处理的确定和排列的金融支付处理的方法1100的流程图。在事件1110处，从支付者那里收到金融支付交易请求。支 付者可以使用任意已知或将来知道的支付输入通道输入金融交易请求。支付输入通道实例 包括但不限于开放式金融交换(OFX)/移动、基于网页的、交互语音响应(IVR)/电话、银行 中心、自动柜员机(ATM)、借记卡/信用卡、商人、支票、图像、电报、自动交换所(ACH)等。在事件1120处，确定多个与支付请求关联的支付处理。可以基于支付输入通道、 支付途径或支付类型和支付属性确定支付处理。如前所述，支付属性可以是支付者定义的 属性、收款人定义的属性或金融机构定义的属性。另外，属性可以是存储在数据库中的预先 定义的属性，或者属性可以是在支付请求的开始或支付处理期间动态定义的。在事件1130处，确定支付处理的排列和顺序。类似于确定支付处理，确定对处理 的排列可以基于支付输入通道、支付途径或者支付类型、和支付属性。如前所述，支付属性 可以是支付者定义的属性、收款人定义的属性或金融机构定义的属性。另外，属性可以是存 储在数据库中的预先定义的属性，或者属性可以是在支付请求的开始或支付处理期间动态 定义的。在事件1140处，根据所确定的排列来执行所确定的支付处理。在一个实施例中，处理发生在支付集中器中，支付集中器使得大量的支付处理基于支付类型发生。例如，支 付处理可以包括但不限于支付途径确定处理、计划的和/或重复的支付处理、借方和贷方 关系处理、支付验证处理、批量支付处理、支付合法性处理、外汇兑换处理、金融风险平估处 理、和/或支付异常处理。如前所述，对于支付处理的修改和/或排列可以基于一个或更多 个支付处理的结果发生在支付处理执行期间。在事件1150处，通过所确定的支付类型向收款人提供金融支付。这里所描述的方法、设备、系统和计算机程序产品用于管理对金融支付的处理，尤 其是管理在提供支付处理的综合支付集中器环境中管理对金融支付的处理，包括在不受支 付输入通道影响的情况下确定支付途径。根据文中公开的实施例，管理支付处理包括自动 确定支付处理以及自动确定对支付处理的排列。如此，文中描述的方法、系统和计算机程序 产品提供了高效和成本节约的支付处理的方法。虽然前面的内容讨论了示意性实施例，应该知道，在不偏离由随附权利要求限定 的所描述的方面和/或实施例的范围的情况下可以对本发明进行各种改变和修改。另外， 虽然描述的方面和/或实施例的元件可以以单数的形式进行描述或者在权利要求中限定， 但是也可以使用复数形式，除非文中明确声明。另外，任意实施例的所有或者一部分都可以 使用任意其它实施例的所有或者一部分，除非文中另有说明。虽然描述和以附图形式示出了某些示例性实施例，但是应当明白这些实施例只是 示意性的而不是用于限定本发明的范围，本发明并未限定到所描述和示出的具体结构和排 列，因为除了上面提到的这些内容之外可以对其进行各种其它的改变、组合、省略、修改和 替代。本领域技术人员明白在不偏离本发明的精神和范围的情况下可以对描述的实施例进 行各种适应性修改。因此，应明白，在随附权利要求限定的范围内(而不限于这里所具体描 述的)可以实现本发明。
权利要求
一种用于处理金融支付的方法，该方法包括接收金融支付请求；确定与所述金融支付请求关联的多个支付处理；确定对与所述金融支付请求关联的多个支付处理的排列；根据所确定的排列执行所述多个支付处理；以及提供与所述金融支付请求关联的金融支付。
2.根据权利要求1所述的方法，其中接收金融支付请求进一步包括从多个支付输入通 道中的一个接收所述金融支付请求。
3.根据权利要求2所述的方法，其中执行所述多个支付处理进一步包括执行所述多个 支付处理而不考虑支付输入通道类型。
4.根据权利要求1所述方法，其中确定对多个支付处理的排列进一步包括基于支付输 入通道、支付类型或支付属性中的至少一个确定对多个支付处理的排列。
5.根据权利要求4所述的方法，进一步包括基于一个或更多个途径规则确定对于支付 请求的支付途径，其中支付途径定义支付类型。
6.根据权利要求4所述的方法，其中基于支付属性确定对多个支付处理的排列进一步 将支付属性定义为与支付者、收款人或金融机构中的至少一个关联。
7.根据权利要求1所述的方法，其中确定对多个支付处理的排列进一步包括动态地确 定对与所述金融支付请求关联的多个支付处理的排列。
8.根据权利要求7所述的方法，其中动态确定对多个支付处理的排列进一步包括基于 多个支付处理中的一个或更多个的结果确定对多个支付处理的排列。
9.根据权利要求1所述的方法，其中确定对多个支付处理的排列进一步包括确定两个 或更多个支付处理的顺序排序或者两个或更多个支付处理的并行处理中的一个或更多个。
10.根据权利要求1所述的方法，其中确定多个支付处理进一步包括基于支付输入通 道、支付类型或支付属性中的至少一个确定与所述金融支付请求关联的多个支付处理。
11.根据权利要求10所述的方法，进一步包括基于一个或更多个途径规则确定对于支 付请求的支付途径，其中支付途径定义支付类型。
12.根据权利要求10所述的方法，其中基于支付属性确定与所述金融支付请求关联的 多个支付处理进一步将支付属性定义为与支付者、收款人或金融机构中的至少一个关联。
13.根据权利要求1所述的方法，其中确定多个支付处理进一步包括动态确定与所述 金融支付请求关联的多个支付处理。
14.根据权利要求13所述的方法，其中动态确定多个支付处理进一步包括基于多个支 付处理中的一个或更多个的结果确定多个支付处理中的一个或更多个。
15.根据权利要求1所述的方法，其中确定多个支付处理进一步包括确定多个支付处 理，其中所述支付处理包括支付途径，管理将来日期的和循环的支付的启动，借方和贷方相 关，认证支付，处理批量金融支付请求，存储支付历史、将来日期的支付或循环的支付中的 至少一个，确保支付合法性，提供外汇兑换处理，提供金融风险评估以及提供金融支付异常 应对处理中的两个或更多个。
16.一种用于处理金融支付的设备，该设备包括计算平台，包括至少一个处理器和存储器；以及支付处理模块，被存储在所述存储器中，可由所述处理器执行，并且包括多个支付处理子模块，每个都用于执行一个或更多个支付处理，和处理管理逻辑，用于确定多个与支付请求关联的支付处理并且确定对于多个支付处理 的排列。
17.根据权利要求16所述的设备，其中所述支付处理模块用于从多个支付输入通道接 收支付请求，并且其中多个支付处理子模块用于执行一个或更多个支付处理而不考虑支付 输入通道类型。
18.根据权利要求16所述的设备，其中所述处理管理逻辑进一步用于基于支付输入通 道、支付类型或支付属性中的至少一个确定对于多个支付处理的排列。
19.根据权利要求18所述的设备，其中所述多个支付处理子模块进一步包括支付途径 子模块，所述支付途径子模块用于基于一个或更多个途径规则确定对于支付请求的支付途 径，其中支付途径定义支付类型。
20.根据权利要求18所述的设备，其中所述处理管理逻辑进一步用于基于支付者定义 的支付属性、收款人定义的支付属性或者金融机构定义的支付属性中的一个或更多个确定 对多个支付处理的排列。
21.根据权利要求16所述的设备，其中所述处理管理逻辑进一步用于动态确定对多个 支付处理的排列。
22.根据权利要求21所述的设备，其中所述处理管理逻辑进一步用于基于多个支付处 理中的一个或更多个的结果确定对多个支付处理的排列。
23.根据权利要求16所述的设备，其中所述处理管理逻辑进一步用于确定两个或更多 个支付处理的顺序排序或者两个或更多个支付处理的并行处理中的一个或更多个。
24.根据权利要求16所述的设备，其中所述处理管理逻辑进一步用于基于支付输入通 道、支付类型或支付属性中的至少一个确定与所述金融支付请求关联的多个支付处理。
25.根据权利要求24所述的设备，其中所述多个支付处理子模块进一步包括支付途径 子模块，所述支付途径子模块用于基于一个或更多个途径规则确定对于支付请求的支付途 径，其中支付途径定义支付类型。
26.根据权利要求24所述的设备，其中所述处理管理逻辑进一步用于基于支付者定义 的支付属性、收款人定义的支付属性或者金融机构定义的支付属性中的一个或更多个确定 多个支付处理。
27.根据权利要求16所述的设备，其中所述处理管理逻辑进一步用于动态确定与所述 金融支付请求关联的多个支付处理。
28.根据权利要求27所述的设备，其中所述处理管理逻辑进一步用于基于多个支付处 理中的一个或更多个的结果确定多个支付处理中的一个或更多个。
29.根据权利要求16所述的设备，其中所述多个支付处理子模块进一步包括支付途径 子模块、未来支付管理子模块、借方和贷方子模块、验证子模块、批量支付子模块、支付数据 库、合法性子模块、外汇兑换子模块、金融风险评估子模块、以及异常处理子模块中的两个 或更多个。
30.一种计算机程序产品，包括计算机可读介质，所述计算机可读介质包括第一组代码，用于使计算机接收金融支付请求；第二组代码，用于使计算机确定与所述金融支付请求关联的多个支付处理；以及第三组代码，用于使计算机确定对与所述金融支付请求关联的多个支付处理的排列；第四组代码，用于使计算机根据所确定的排列执行多个支付处理；以及第五组代码，用于使计算机提供与所述金融支付请求关联的金融支付。
31.根据权利要求30所述的计算机程序产品，其中所述第一组代码进一步用于使计算 机从多个支付输入通道中的一个接收金融支付请求。
32.根据权利要求31所述的计算机程序产品，其中第四组代码进一步用于使计算机执 行多个支付处理而不受支付输入通道类型的影响。
33.根据权利要求30所述的计算机程序产品，其中所述第三组代码进一步用于使计算 机基于支付输入通道、支付类型或支付属性中的至少一个确定对多个支付处理的排列。
34.根据权利要求33所述的计算机程序产品，其中所述第四组代码进一步用于使计 算机基于一个或更多个途径规则确定对于支付请求的支付途径，其中支付途径定义支付类 型。
35.根据权利要求33所述的计算机程序产品，其中第三组代码进一步用于使计算机基 于支付者定义的支付属性、收款人定义的支付属性或者金融机构定义的支付属性中的至少 一个确定对多个支付处理的排列。
36.根据权利要求30所述的计算机程序产品，其中第三组代码进一步用于使计算机动 态确定对与金融支付请求关联的多个支付处理的排列。
37.根据权利要求36所述的计算机程序产品，其中第三组代码进一步用于使计算机基 于多个支付处理中的一个或更多个的结果确定对多个支付处理的排列。
38.根据权利要求30所述的计算机程序产品，其中所述第三组代码进一步用于使计算 机确定两个或更多个支付处理的顺序排序或者两个或更多个支付处理的并行处理中的一 个或更多个。
39.根据权利要求30所述的计算机程序产品，其中第二组代码进一步用于使计算机基 于支付输入通道、支付类型或支付属性中的至少一个确定与金融支付请求关联的多个支付处理。
40.根据权利要求39所述的计算机程序产品，其中第四组代码进一步用于使计算机基 于一个或更多个途径规则确定对支付请求的支付途径，其中支付途径定义支付类型。
41.根据权利要求39所述的计算机程序产品，其中第二组代码进一步用于使计算机基 于支付者定义的支付属性、收款人定义的支付属性或者金融机构定义的支付属性中的至少 一个确定与金融支付请求关联的多个支付处理。
42.根据权利要求30所述的计算机程序产品，其中第二组代码进一步用于使计算机动 态确定与金融支付请求关联的多个支付处理。
43.根据权利要求42所述的计算机程序产品，其中第二组代码进一步用于使计算机基 于多个支付处理中的一个或更多个的结果确定所述多个支付处理中的一个或更多个。
44.根据权利要求30所述的计算机程序产品，其中第二组代码进一步用于使计算机确 定多个支付处理，其中所述支付处理包括支付途径，管理将来日期的和循环的支付的启动， 借方和贷方相关，认证支付，处理批量金融支付请求，存储支付历史、将来日期的支付或循环的支付中的至少一个，确保支付合法性，提供外汇兑换处理，提供金融风险评估以及提供金融支付异常应对处理中的两个或更多个。
全文摘要
本发明涉及一种系统、方法和计算机程序产品，用于管理对金融支付的处理，尤其是管理在提供支付处理的综合支付集中器环境中对金融支付的处理，包括在不受支付输入通道影响的情况下确定支付途径。根据文中公开的实施例，管理支付处理包括自动确定支付处理以及自动确定对支付处理的排列。如此，文中描述的方法、系统和计算机程序产品提供了高效和成本节约的处理支付的方法。
文档编号G06Q20/00GK101826186SQ201010151539
公开日2010年9月8日 申请日期2010年2月11日 优先权日2009年2月13日
发明者A·B·卡尔代罗尼, D·T·弗鲁, E·多耶尔, G·C·博瑞格斯, K·坎特利, M·D·赞佐特, P·托宾, W·E·托马斯二世 申请人:美国银行公司