用于优化金融支付途径的系统、方法和计算机产品的制作方法

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

发明内容
为了提供对这种实施例的基本理解，下面提供一个或多个实施例的简要概述。此发明内容不是所有预期实施例的扩展性综述，其目的不是为了标识所有实施例的关键或重 要元件也不是为了描述任何或所有实施例的范围。其唯一目的就是以简化形式提供一个或 多个实施例的概念作为后面将要给出的更详细的描述的序言。这里描述被提供用于优化金融支付交易的途径的方法、设备、系统和计算机程序 产品。通过基于每个支付或者每个支付组(在这里被称作支付文件)确定支付通道来实现 支付途径的优化。根据所提供的实施例从多于一种备选支付类型之中基于一个或多个途径 规则来确定支付途径或者支付类型。途径规则与支付属性(例如，但不限于，支付时间要 求、支付成本、支付风险/支付质量、支付目的地、和任何其它客户/支付者/收款人需求或 要求)关联。支付属性可以是支付者定义的属性或者收款人定义的属性，它们是预先确定 的并且被存储在支付者/收款人简档中，或者，可以在支付交易开始时动态地定义支付者 定义的或收款人定义的属性。在其它实施例中，支付属性可以是金融机构定义的支付属性 或者支付产品定义的支付属性。 这样，根据目前描述的实施例，可基于将哪个途径规则应用于该交易和/或将哪 个支付属性应用于途径规则，独立于其它支付交易的途径为所处理的每个支付确定途径。 在这方面，就客户和金融机构效率而言，整个支付交易过程被优化了 可充分地优化支付时 间、支付成本/价格和支付风险/质量。根据本发明的一个具体的实施例，定义了用于处理金融支付的方法。该方法包括 从支付者接收金融支付交易，从多于一种备选支付类型中基于一个或多个途径规则确定交 易的支付途径，以及通过所确定的支付类型向收款人提供金融支付。备选的支付类型另外可以被定义为已知的或将来知道的支付产品的任何两组，例 如(但不限于)支票支付、电子/自动化票据交换所(ACH)支付、电报支付、卡支付、商人支 付、转帐支付、全世界国际金融电信学会(SWIFT)支付等。根据确定支付类型的方法的可选实施例，另外包括基于一个或多个途径规则确定 支付途径，其中至少一个途径规则与支付处理时间、支付处理成本/价格、支付处理风险/ 质量、支付汇款要求或支付目的地关联。在一个具体可选实施例中，一个或多个途径规则用 于确定满足所有定义的时间要求和/或风险/质量需求的最低成本支付类型。在另外的可选实施例中，该方法包括接收一个或多个支付者定义或收款人定义的 支付属性。在方法的这些实施例中，确定支付途径另外可以包括将支付者定义的和/或收 款人定义的支付属性应用于一个或多个途径规则以确定支付途径。支付者定义的支付属性 或收款人定义的支付属性可以与支付时间、支付成本、支付风险、支付目的地或其它支付规 则例如汇款要求中的至少一个关联。在方法的一个可选实施例中，接收一个或多个支付者 定义的支付属性或收款人定义的属性可以包括访问支付者和/或收款人简档数据库以从 与支付者/收款人相关的支付者/收款人简档获取一个或多个预先定义的支付者定义的支 付属性和/或一个或多个收款人定义的支付属性。在其它可选实施例中，支付者定义的支 付属性和/或收款人定义的支付属性可以由支付者和/或收款人在请求金融支付的时间点 附近进行动态定义。在其它可选实施例中，该方法包括接收一个或多个交易处理金融机构定义的支付 属性或者支付产品属性。在这些实施例中，确定支付途径可以进一步包括将金融机构定义 的支付属性或者支付产品属性应用于一个或多个途径规则以确定支付途径。
在另外的可选实施例中，该方法可以包括接收一个或多个交易处理金融机构定义 的支付属性和一个或多个支付者定义的支付属性或一个或多个收款人定义的支付属性中 的至少一个。在这些实施例中，确定支付途径可以进一步包括将金融机构定义的支付属性 和支付者定义的支付属性和/或收款人定义的支付属性应用于一个或多个途径规则以确 定支付途径。在另外的可选实施例中，该方法可以包括在确定支付途径之前将金融支付交易转 换到标准格式然后在通过所确定的支付类型向收款人提供金融支付之前将金融支付交易 转换到与所确定的支付途径相关的格式。本发明的另外的实施例提供了处理金融支付的设备。该设备包括具有至少一个处 理器和存储器的计算机平台。该设备另外还包括存储在存储器中的途径规则数据库并且其 用于存储一个或多个途径规则。该设备还包括由处理器执行的支付途径确定逻辑并且用于 从多于一种备选支付类型中基于对一个或多个途径规则的应用来确定对于支付交易的支 付途径。在设备的可选实施例中，至少一个途径可以与支付处理时间/限制、支付处理成 本需求/限制、支付处理风险/质量需求/限制、和/或支付目的地关联。在设备的具体 实施例中，一个或多个途径规则可以用于确定满足时间要求和风险要求的最低成本支付类型。在设备的另一可选实施例中，支付途径确定逻辑进一步用于将一个或多个支付者 定义的支付属性和/或一个或多个收款人定义的支付属性应用于一个或多个途径规则以 确定支付途径。支付者定义的支付属性或收款人定义的支付属性可以与支付时间、支付成 本、支付风险或支付目的地中的至少一个关联。根据一个实施例，支付途径确定逻辑可以进 一步访问支付者简档数据库和/或收款人简档数据以从与支付者或收款人相关的支付者/ 收款人简档中获取一个或多个支付者定义的支付属性和/或收款人定义的支付属性。在其 它可选实施例中，一个或多个支付者定义的支付属性或一个或多个收款人定义的支付属性 可以由支付者或收款人在与提出金融支付请求相同的时间点定义。在这方面，支付者定义 的属性或收款人定义的支付属性可以是预先定义的属性或者在支付请求点上定义的动态 属性。在设备的另一可选实施例中，支付途径确定逻辑可以进一步将一个或多个金融机 构定义的支付属性或支付产品属性应用于一个或多个途径规则以确定支付途径。在设备的 另一可选实施例中，支付途径确定逻辑可进一步将一个或多个金融机构定义的支付属性和 一个或多个支付者定义的支付属性或一个或多个收款人定义的支付属性中的至少一个应 用于一个或多个途径规则以确定支付途径。设备的另一可选实施例包括由处理器执行的支付交易转换逻辑和在确定支付途 径之前将金融支付交易转换到标准格式。支付交易转换逻辑进一步在通过所确定的支付类 型向收款人提供支付之前将金融支付交易转换到与确定的金融支付途径相关的格式。包括计算机可读介质的计算机程序产品提供了本发明的另一可选实施例。介质包 括第一组代码，用于使计算机从支付者接收金融支付交易。介质还包括第二组代码，用于使 计算机从多于一种备选支付类型中基于一个或多个途径规则确定交易的支付途径。另外， 介质包括第三组状码，用于使计算机通过所确定的支付类型向收款人提供金融支付。
在计算机程序产品的可选实施例中，第二组代码进一步使计算机基于一个或多个 途径规则确定支付途径，其中至少一个途径规则与支付处理时间限制/需求、支付处理成 本限制/需求、支付处理风险/质量需求、限制和/或支付目的地关联。在计算机程序产 品的其它可选实施例中，第二组代码进一步使计算机基于一个或多个途径规则确定支付途 径，其中一个或多个途径规则用于确定满足时间要求和风险要求的最少成本支付类型。根据计算机程序产品的其它可选实施例，可以包括第四组代码，用于使计算机接 收一个或多个支付者定义的支付属性和/或一个或多个收款人定义的支付属性。在这些实 施例中，第二组代码进一步使计算机将支付者定义的支付属性和/或收款人定义的支付属 性应用于一个或多个途径规则以确定支付途径。在另外的相关实施例中，第四组代码使计 算机接收一个或多个支付者定义的支付属性或收款人定义的支付属性，其中每个属性进一 步被定义为与支付时间、支付成本、支付风险或支付目的地中的至少一个关联。在其它相关 实施例中，第四组代码使计算机访问支付者简档数据库或者收款人简档数据库、从与支付 者/收款人相关的支付者简档或收款人简档中获取一个或多个支付者定义的支付属性或 收款人定义的支付属性，或者属性可以由支付者或收款人在提出金融支付请求的时间点定 义。 根据计算机程序产品的另一实施例可以包括可选的第四组代码，使计算机接收一 个或多个交易处理金融机构定义的支付属性。在这些实施例中，第二组代码进一步使计算 机将金融机构定义的支付属性应用于一个或多个途径规则以确定支付途径。另外，计算机 程序产品的其它可选实施例可以包括第四组代码，使计算机接收一个或多个交易处理金融 机构定义的支付属性以及一个或多个支付者定义的支付属性或一个或多个收款人定义的 支付属性中的至少一个。在这些实施例中，第二组代码进一步可以使计算机将金融机构定 义的支付属性和至少一个支付者定义的支付属性或收款人定义的支付属性应用于一个或 多个途径规则以确定支付途径。在其它可选实施例中，计算机程序产品可以包括第五组代码，用于使计算机在确 定支付途径之前将金融支付交易转换到标准格式。在这些实施例中，第五组代码可以进一 步使计算机在通过确定支付类型向收款人提供金融支付之前将金融支付交易转换到与确 定的支付途径相关的格式。这样，这里公开的实施例提供了金融支付优化途径，通过基于一个或多个途径规 则确定每个支付交易的途径。途径规则考虑了支付因素，例如(但不限于)支付处理成本、 支付处理时间、支付处理风险/质量(即，确保进行了支付)和/或支付目的地。从支付者 /收款人角度看，与这些或其它支付因素相关的支付者定义的支付属性和/或收款人定义 的支付属性可以在支付者/收款人简档中预先定义或者在发起支付请求的时间点上定义。 在这方面，本发明用于生成对支付者、收款人和处理支付的金融机构在成本、时间、质量等 方面有益的支付处理。为了实现这里所描述的，一个或多个实施例包括这里完整描述的特征和权利要求 中特别指出的特征。下面的描述和附加的图提出了一个或多个实施例的某些示例性特征。 这些特征都是示意性的，然而可以使用多种方法实现各个实施例的原理，描述的目的用于 包含所有的实施例和等效物。


参考附图描述的本发明的实施例使用了通用术语，这些附图并不是按比例绘制， 其中图1是设备的框图，设备被配置用于根据本发明的一个实施例提供基于金融支付 途径的规则；图2是设备更详细的框图，设备被配置用于根据本发明的一个实施例提供基于金 融支付途径的规则；图3是根据本发明的一个实施例处理金融支付请求的方法的流程图；图4是根据本发明的一个实施例金融支付输入通道的框
图5是根据本发明的另一实施例支付配置属性/规则资源的框图；图6是根据本发明的一个实施例包含可选处理的具体支付处理的框图；图7是根据本发明的一个实施例支付认证处理的框图；图8是根据本发明的一个实施例途径规则示例的框图；图9是根据本发明的另一个实施例汇款和结算通道的框图；图10是根据本发明的另一实施例，基于每个支付请求确定支付途径的处理金融 支付的方法的流程图。
具体实施例方式下文中将参考附图更完整地描述序发明的实施例，在附图中示出了本发明部分而 并不是所有的实施例。实际上，本发明可以以多种不同形式被实施，并且不应当被理解为限 于这里阐述的实施例；相反，提供这些实施例使得本公开满足适用的法律需求。在下面的描 述中，为了解释的目的，提出了大量的具体细节从而提供对一个或多个实施例的透彻理解。 然而，明显的是，可以在没有这些具体细节的情况下实施这些实施例。全文中相同的附图标 记表示相同的元件。对于可包括大量设备、组件、模块等的系统或者设备将提供各种实施例或者特征。 要理解和明白的是，各种系统成者设备可以包括额外的设备、组件、模块等，以及/或者，可 以不包括关于附图所讨论的所有的设备、组件、模块等。也可以使用这些方案的组合。可以直接在硬件中、在由处理器执行的软件中，或者在二者的结合中实施结合这 里公开的实施例描述的方法或者算法的步骤和/或动作。软件模块可以驻留在RAM存储器、 闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM或者业界 已知的任何其它形式的存储器介质。示例性存储器介质可以耦接到处理器，以便处理器可 以从存储器介质读取信息以及向存储器介质写入信息。可替代的，存储器介质可以被集成 到处理器。另外，在某些实施例中，处理器和存储器介质可以驻留在专用集成电路(ASIC) 中。可替代的，处理器和存储器介质可以在计算设备中作为分立的组件驻留。另外，在某些 实施例中，方法或算法的事件和/或动作可以在机器可读介质和/或计算机可读介质上作 为一个代码和/或指令、或者代码和/或指令的任何组合或集合，其可以被并入到计算机程 序产品中。在一个或多个实施例中，可以在硬件、软件、固件或其任何组合中实现所描述的功 能。如果在软件中实施的话，这些功能可以作为计算机可读介质上的一个或多个指令或者代码被存储或者传送。计算机可读介质包括计算机存储介质和通信介质，包括便于计算机 程序从一个地方传输到另一个地方的任何介质。存储器介质可以是可由计算机访问的任何 可用介质。这种计算机可读介质例如包括(但不限于)RAM、ROM、EEPROM、CD-ROM或者其它 光盘存储器，磁盘存储器或者其它磁存储器设备，或者可被用于以指令或者数据结构的形 式承载或者存储期望的程序代码并且可通过计算机访问的任何其它介质。而且，任何连接 都可以叫做计算机可读介质。例如，如果软件是通过使用同轴电缆、光纤缆线、双扭线、数字 用户线(DSL)或者例如红外线、无线电和微波的无线技术从网站、服务器或者其它远程资 源传送的，那么同轴电缆、光纤缆线、双扭线、DSL或者例如红外线、无线电或微波的无线技 术都包含在介质的定义中。这里使用的“磁盘(disk)”和“光盘(disc)”包括高密度光盘 (CD)、激光盘、光盘、数字通用光盘(DVD)、软盘和蓝光盘，其中磁盘通常以磁的方式再现数 据，而光盘通常利用激光以光的方式再现数据。上述内容的组合也应当包含在计算机可读 介质的范围内。 这样，所提供的实施例提供了通过基于一个或多个途径规则、确定基于每个支付 交易的途径以优化金融支付的途径的方法、系统、计算机程序产品。途径规则考虑到了支付 因素，例如(但不限于)支付处理的成本、用于支付处理的时间、支付处理的风险/质量、和 /或支付的目的地。从支付者/收款人的角度看，与这些或其它支付因素相关的支付者定义 的支付属性和/或收款人定义的支付属性都可以在支付者/收款人简档中被预先定义或者 在临近发起支付请求的时间动态地定义。这样，所提供的实施例用于创建对于支付者、收款 人和进行支付处理的金融机构来说在成本、时间性、质量等方面有益的支付处理。参考图1，示出了设备100的框图，根据本发明的实施例，该设备100用于提供金 融支付处理。如前所述，设备100可以包括一个或多个设备。在多个设备的实施例中，这些 设备可以彼此联网通信。设备100包括具有至少一个处理器120和存储器130的计算平台 110。设备100的存储器130包括支付模块140，另外这里也可叫做支付集中器(hub)模 块，用于接收支付请求、相应地处理请求以及清除用于汇款和结算的请求。应当明白，根据 本发明的实施例，图1描述了单个模块，但是支付模块140可以包括多个模块并且多个模块 可以被包括在各种不同的设备中。因此，关于支付模块140所描述的例程、应用、数据库和 逻辑都可以被包括在多个不同的模块中。支付模块140包括途径规则数据库150，该数据库包括一个或多个途径规则160。 途径规则160可以与支付途径因素相关，例如(但不限于)处理支付的价格/成本、用于处 理支付的时间要求、用于处理支付的质量/风险要求或者容差(即，保证汇款和结算、中止 支付的能力等)，支付的目的地等。支付模块140另外包括支付途径确定逻辑170。逻辑170通过处理器120执行并 基于对一个或多个途径规则的应用从多于一种备选支付类型之中确定支付交易的支付途 径(即，支付类型180、或者这里也可叫做支付途径)。例如，逻辑170可以从多于一种备选 支付类型之中确定支付途径，例如(但不限于)票据/支票支付、电子支付、自动化票据交 换所(ACH)支付、电报支付、全世界银行间金融电信学会(SWIFT)支付、卡型支付、商人支 付、转帐支付、收集支付等等。多于一种的备选支付类型表示前述列表中多于一种的备选支 付类型。例如，一种选择可以是票据/支票支付或者电子/ACH支付，然而多于一种的选择(尤其是两种选择)可以是票据/支票支付或者电子/ACH支付(例如第一种选择)、以及 票据/支票支付或者电报支付(例如第二种选择)。多于一种选择(尤其是三种选择)的 另一示例是票据/支票支付或者SWIFT支付(例如第一种选择)、票据/支票支付或者卡支 付(例如第二种选择)、以及票据/支票支付或者电子/ACH支付(例如第三种支付)。图2提供了根据本发明的进一步的实施例的设备100的详细描述。除了提供更详 细的细节外，图2突出了各种可选的实施例。设备100可以包括任何类型的计算设备、和/ 或一个或多个计算设备的组合，所述计算设备例如为个人计算机、膝上型/便携计算机、无 线或者手持计算设备、服务器等。计算机平台110用于接收和执行模块、例程和应用，例如 支付模块140等等。计算机平台110包括存储器130，其可以包括易失性和非易失性存储 器，例如只读和/或随机访问存储器(RAM和ROM)、EPROM、EEPR0M、闪存卡或者计算机平台 通用的任何存储器。另外，存储器130可以包括一个或多个闪存单元，或者可以是任何二级 或三级存储器设备，例如磁介质，光介质，磁带、或者软盘或硬盘。 另外，计算机平台110还包括处理器120，其可以是专用集成电路(“ASIC”)，或者 其它芯片组、处理器、逻辑电路或者其它数据处理设备。处理器120或者其它例如ASIC的 处理器可以执行与任何驻留程序(例如存储在设备100的存储器130中的支付模块140、支 付转换模块210等)接口的应用程序接口( “API”)层200。处理器120包括包含在硬件、固件、软件及其组合中的各种处理子系统220，其使 能设备100的功能和网络上设备的可操作性。例如，处理子系统220允许发起、以及与其它 网络设备维持通信和交换数据。设备100的存储器130可选择地包括与处理器120通信的支付转换模块210，该 模块可以将支付请求标准化并且将处理后的支付请求转换为确定的支付途径/类型的格 式。对支付类型的标准化使得支付模块140能够在支付仓库型环境中使用相似的处理和技 术处理所有类型的支付请求。这样，支付转换模块210包括由处理器120执行的标准化逻 辑230，并且其可以将所有进入的支付请求转换/标准化为标准的格式，例如国际标准化组 织(ISO) 20022通用金融产业信息方案等。支付转换模块210另外包括由处理器120执行 的支付格式化逻辑240，并且其用于将后付费处理、标准化格式转换为所确定的支付途径/ 结算类型的格式。支付模块140用于接收支付指令、确认支付以及确定用于支付的途径。根据本发 明提供的实施例，支付模块140用于基于每个付费确定支付途径，以便可以基于与支付和/ 或支付者、和/或收款人和/或处理支付的金融机构相关的特性来确定汇款和结算支付的 方式。这方面，在处理支付的成本、支付处理的时间性和支付处理的质量/风险方面支付 者、收款人和/或金融机构实现了支付优化。类似于图1，对于支付转换模块210和支付模块140描述了单独的模块，但是，根据 本发明的实施例，模块可以包括多个模块，并且所述多个模块可以被包括在各种不同的设 备内。因此，关于支付转换模块210和支付模块140所描述的例程、应用、数据库和逻辑可 以被包括在多个模块中。同样，关于支付转换模块210和支付模块140所讨论的规则和逻 辑可以被包含在多个应用或例程中或者在其中实现。支付模块140包括途径规则数据库150，途径规则数据库150包括一个或多个途 径规则160。途径规则160可以与支付途径因素相关，例如(但不限于)处理支付的价格/成本、对于处理支付的时间要求、对于处理支付的质量/风险要求或者容差(即，保证汇款 和结算，中止支付的能力等)、支付的目的地等。这样，途径规则160可以包括一个或多个 与成本价格相关的途径规则162、一个或多个与时间相关的途径规则164、一个或多个与风 险/质量相关的途径规则166、一个或多个与目的地相关的途径规则168或者其它途径规则 169。与成本/价格相关的途径规则162可以定义基于支付者和/或收款人愿意为正 进行的支付所承受的价格、或者对于处理支付金融机构愿意承受的或者可能向付款者收取 的成本，选择哪个汇款/结算类型180。在这方面，不同的汇款结算类型可以与不同的支付 价格关联，以便通过一种汇款/结算类型的支付可以比另一种汇款/结算类型在支付价格 上更高或者更低。 与时间相关的途径规则164可以定义基于支付者的、收款人的和/或金融机构 的可接受的用于完成支付交易的时间选择哪个汇款/结算类型180。在大多数情况中，支 付者和/或收款人期望尽量及时地完成支付，然而处理支付的金融机构期望将汇款/结算 延迟尽可能长的时间段。然而，应当明白，在大多数情况中，支付者关心尽量及时地进行支 付，在另外的情况中，支付者可能期望延迟支付时间(例如，当正从其进行支付的帐号中现 在没有足够的资金时)。与风险/质量相关的途径规则166可以定义基于保险或保证将要进行付费的能 力(换句话说，提供给支付的服务水平或者与不同支付汇款/结算类型关联的失败几率数) 选择哪种汇款/结算类型180。其它风险/质量途径规则166可以定义支付处理期间的返 回或停止支付的能力，数据核对(reconciliation)能力，例如如何平衡资金或者任何与质 量或风险属性关联的其它途径规则，质量或风险属性由支付者、收款人和/或进行支付处 理的金融机构定义。与目的地相关的途径规则168可以定义基于支付的目的地选择哪种汇款/结算 类型180。例如，境内支付可以规定汇款/结算的某些类型，而国际支付可以规定其它类型
的汇款/结算。其它途径规则169可以另外定义其它用于选择汇款/结算类型180的规则。依据 进行支付处理的金融机构、支付者和/或收款人的需求规定其它途径规则。支付模块140另外还包括可由处理器120执行的支付途径确定逻辑170，并且基于 对一个或多个途径规则的应用，从多于一种备选支付类型之中确定用于支付交易的支付途 径(即，支付类型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可以包括，或者支付模块可以与另一辅助设备的 存储器(图2中未示出)通信，所述另一辅助设备的存储器包括支付者简档数据库280、收 款人简档数据库290和/或金融机构/银行数据库294用于存储支付属性/规则。因此， 支付者简档数据库280可以包括多个支付者/客户简档282，并且每个简档282包括与支付 者关联的支付属性/规则260。收款人简档数据库290可以包括多个收款人简档292，并且 每个简档292包括与收款人关联的支付属性/规则260。金融机构/银行数据库294可以 包括与输入支付请求类型关联的支付属性/规则270或者任何其它相关的关联。如前所述，支付途径确定逻辑170可以从多于一种选择中确定任何适当的支付途 径180类型。支付途径/类型可以包括支票/票据300、信用/银行卡302、电子/ACH 304、 电线306、SWIFT 308、贸易商310、转帐312或者任何其他汇款/结算支付途径/类型314。 一种可选择的支付途径包括两种或更多种支付途径类型。例如，支票/票据300或者信用 /银行302包括一种备选的支付途径，SWIFT308或者转帐312包括另一备选的支付途径，而 电报306或SWIFT 308或贸易商310包括另一种备选的支付途径。

图3提供了用于支付处理的复合方法400的流程图，包括根据本发明的实施例基 于规则确定支付途径。在事件410处，通过指定的输入通道输入支付请求。图4提供了支付 输入通道500的各种示例的框图。应当明白，图4示出的支付输入通道500仅仅是作为例 子而不意欲进行限制。支付输入通道500可以包括客户支付输入通道510和企业/前端支 付输入通道530。客户支付输入通道510提供客户到企业支付输入和/或客户到客户(即， 消费者到消费者)支付输入。企业/前端支付输入通道530提供企业到企业支付输入和/ 或企业到消费者支付输入。客户支付输入通道是用户接口的并且可以包括但不限于通常在手持设备等上 操作的开放式金融交换(OFX)/移动支付输入通道512 ；基于网页的支付输入通道514， 例如因特网或通常用于接收自动交换所(ACH)请求、电报支付请求、帐单支付等的法人 (corporate)网站；电报/交互语音响应(IVR)支付输入通道516 ；银行中心支付输入通道 (亲自)518 ；以及自动柜员机(ATM)支付输入通道520。企业/前端输入通道530包括但不限于销售点支付输入通道532，例如刷(swipe) 信用卡/借记卡等；图像交换支付输入通道534 ；远程储蓄支付输入通道536 ；大量文件通 信支付输入通道538 ；以及直回(straight back)办公室集成输入通道540，其中企业应用 直接调用/访问金融机构支付引擎来发起交易。再次参考图3中的方法400，在事件420处，建立了支付配置属性/规则。支付配 置属性/规则都是与消费者支付者/收款人或者公司支付者/收款人关联的可配置数据， 并且基于规则的途径确定逻辑随后使用所述可配置数据(事件546)来确定适当的汇款/ 结算途径。图5提供了支付配置规则/属性资源600的各种示例的框图。资源600可以包 括(但不限于)收款人简档/设置(set-Up)610。收款人简档/设置610可以是对于收款 人接收的具体支付的动态的设置。例如，收款人接收已准备好支付并且通过适当的指定通 道(例如网站等)进行支付的通知、收款人配置支付属性/规则(例如对于支付的时间要求等)。可替代的，收款人可以具有预先定义的支付简档，其可以存储在预先定义了支付属 性/规则的可访问的收款人简档数据库中。支付配置规则/属性资源600另外还可以包括货品计价(invoicing)和由支付者 和/或收款人发出的支付声明620，支付者和/或收款人定义了对于具体支付或者一系列支 付的支付配置属性/规则，例如支付风险/质量、支付目的地等。资源600可以另外包括支 付警告和/或支付通知630，其通常与具体支付或者一系列支付关联并且定义了由支付者、 收款人或者处理支付交易的金融机构具体指定的支付配置规则。支付配置规则/属性资源600可以包括支付者简档/设置640。支付者简档/设 置640可以是对于支付者请求的具体支付的动态设置。可替代的，支付者可以具有预先确 定的支付简档，其可以存储在预先定义支付属性/规则的可访问的支付者简档数据库中。 再次参考图3的方法400，在事件430处，支付请求可被变换为，也可称作标准化为 标准格式从而允许处理所有不同的支付而不必考虑输入通道。在传统的支付处理中，每个 支付输入通道都需要用于处理支付的指定库。根据本发明的实施例，变换/标准化到标准 格式，例如ISO 20022通用金融产业信息方案等，一般允许发生支付处理而不必考虑支付 输入通道。在事件440处，支付处理发生在这里称作支付集中器的位置。基于支付请求的变 换/标准化，支付集中器能够处理所有类型的支付输入请求。应当明白，虽然根据本发明的 实施例支付处理框中示出的事件(事件442，444和446)依次顺序发生，但是这些事件可以 按支付集中器所确定的那样以任何顺序发生以优化支付处理。应当注意，关于事件440所示出的以及在这里被描述为发生在支付引擎中的例 程、模块、应用和函数可以被其他应用访问或者通过其他应用实现，例如其它没有实现支付 引擎等的支付处理应用。关于这一点，其它应用可在需要时访问具体的例程、模块、应用和 函数。例如，如果另一支付处理应用需要遵守反洗钱法形式的支付验证，应用可以访问和实 现支付集中器的具体部分而不是实现支付集中器的全部。在事件442处，支付处理可以包括，接收支付指令，例如用于作出支付处理决定的 支付属性/规则、计价/声明、报警、通知等。在事件446处，基于正进行的支付类型发生具 体支付处理。图6是根据本发明的实施例详细描述可在支付集中器处实现的各种示例性具 体支付处理700的框图。应当注意，图6中突出的具体支付处理700仅仅是示例而并非限 制性的。另外，在基于每个处理的一些实施例中，可以在支付集中器处确定支付处理的顺序 从而提高整体效率以及支付处理模型的有效性。具体支付处理700可以包括计划的和循环的支付处理710。这种处理管理未来日 期的和循环的支付的启动，包括对于计划的/循环的支付使用预先定义的定制模板设置。 另外，具体支付处理700可以包括借方/贷方关联处理720，其包括定时和顺序处理以确保 最初支付关联关系。在这个方面，当在支付项目层处理时个人贷方与最初借方关联并平衡 (balance) 0具体支付处理700还包括验证处理730用于验证支付和相关账户属性以确保支付 的清算。另外，具体支付处理700可以包括批量支付处理740，对于具有多个单独支付项的 大的支付文件批量支付处理聚集并优化与外部系统的通信，其中多个支付项具有相同的过 限(posting accounts) 0而且，具体支付处理700可以包括支付库处理750，其用于存储未来日期的支付，支付历史，循环支付模型等。再次参考图3中的方法400，支付处理(事件440)还可以包括支付的验证处理 446。图7是根据本发明的实施例，可以在支付集中器处实现的各种示例性验证处理800的 详细框图。应当注意，图7中示出的具体验证处理800是示例性的而不限制性的。另外，在 基于每个支付的某些实施例中可以在支付集中器处确定验证处理的顺序以提高整体效率 以及支付处理模型的有效性。验证处理800可以包括用于确保支付遵守反洗钱法规的遵守处理810。遵守处理 可以包括已知的与违法支付处理关联的个人、公司等的海外资金控制(OFAC)的名单的安 全检查。另外，验证处理800可以包括外汇/单一欧元支付区(SEPA)处理820，用于最大化 外币汇率，提供多货币支持并确保遵守SEPA规则和规章。另外，验证处理800可以包括金融风险评估处理830，用于提供对于整个支付处理 的信用和风险管理。在这方面，金融风险评估处理可以提供债务风险评估分数等，其接下来 由基于规则的途径确定用于定义或批准(mandate)可以实现的汇款/结算途径类型。例如， 如果确定金融风险为高，途径确定可以将电报支付排除作为汇款/结算支付选项。

而且，验证处理800可以包括异常处理840，用于提供对所有支付类型的集中异常 处理和管理。异常处理考虑了支付处理中的错误，例如格式化错误等，并且可以实现对于普 通异常/错误的自动修正。对异常的自动修正需要较少的人工干预并且改善了直接通过的 支付处理比率。再次参考图3的方法400，支付处理(事件440)还包括基于规则的途径确定处理 448，如在前面结合图1和2所讨论的那样。图8提供了根据本发明的实施例可以在支付途 径确定处理中实现的示例性途径规则900的框图。示出的途径规则仅仅是示例。应当注意， 对于任何一个途径确定处理来说，可以使用一个或多个途径规则。提供给一个或多个规则 的优先级可以基于支付者简档数据，收执人简档数据，通知，警告，金融机构规则等。途径规 则900可以与支付途径因素相关，例如(但不限于)处理支付的价格/成本、处理支付的时 间要求、处理支付的质量/风险要求或容限(即，确保汇款和结算、中止支付的能力等)，支 付目的地等。因此，途径规则900可以包括一个或多个与时间相关的规则910、成本/价格 相关的途径规则920、一个或多个风险/质量相关的途径规则930、一个或多个目的地相关 的途径规则940或者其它支付者/收款人定义的途径规则950。如前面提到的那样，时间相关的途径规则910可以定义为了完成支付交易，基于 支付者的、收款人的和/或金融机构的可接受的时间选择哪个汇款/结算类型180。在大多 数情况中，支付者和/或收款人期望尽可能及时地完成支付，而处理支付的金融机构期望 将汇款/结算延迟尽可能长的时间段。成本/价格相关的途径规则920可以定义基于支 付者和/或收款人愿意为支付承担的价格、或者金融机构愿意承担的或向支付者收取的用 于处理支付的成本，选择哪个汇款/结算类型180。风险/质量相关途径规则930可以定义基于确保或保证将要进行的支付选择哪 个汇款/结算类型180，换句话说，提供给支付的服务水平或者与不同支付汇款/结算类型 关联的失败几率数。其它风险/质量途径规则166可以定义在支付处理期间返回或中止支 付的能力、数据核对能力，例如如何平衡资金或者任何与质量或风险属性关联的任何其它 途径规则，质量或风险属性由支付者、收款人和/或进行支付处理的金融机构定义。目的地相关的途径规则940可以定义基于支付的目的地选择哪个汇款/结算类型180。例如，境 内支付可以规定某些汇款/结算类型，而国际支付可以规定其它汇款/结算类型。支付者/收款人定义的950可另外定义其它的用于选择汇款/结算类型的规则。 支付者/收款人定义的途径规则950可以在接近支付请求的时间动态地被定义或者可以在 支付者或收款人简档中预先被定义。在大多数情况中，支付者或收款人定义的途径规则将 覆盖任何其它途径规则。再次参考图3中的方法400，支付处理可以包括其它处理(图3中未示出)例如汇 款报告，业务流程管理(BPM)编排(orchestration)，交易跟踪/可见性等。汇款报告向相 关服务提供汇款的电子报告；汇款报告的示例包括但不限于活期存款记帐(DDA)报告书， 账户核对报告，平衡和交易报告等。BPM编排用于确定支付集中器中发生处理的顺序，确定 和管理到支付库的信息传递等。基于支付输入通道、支付属性/规则或所确定的支付途径 来确定处理发生的顺序。这样，BPM编排提供了一组用于高效安排(align)支付处理的工 具。交易/跟踪可见性允许具有指定的访问权(access)的支付者、收款人或任何其它个人 或公司实体查看支付当前存在于整个处理支付流程中的位置。交易/跟踪可见性通常通过 在线用户接口(例如基于接口的网页等)实现。在事件450处，经标准化和处理的支付被转换到汇款/结算目标清算格式。通过 支付请求到标准化格式的最初标准化规定到目标清算格式的转换。

在事件460处，根据所确定的支付途径对支付进行汇款和结算。图9提供了根据 本发明的实施例的示例性汇款/结算支付通道1000的框图。汇款支付通道1000可以包括 支票支付1010、自动交换所(即，电子的)支付1020、电报支付1030、全世界银行间金融电 信学会(SWIFT)支付1040、借记卡/信用卡支付1050、商人支付1060和转帐支付1070，并 且结算通道可以包括收集1070等。另外，可以实现其它汇款/结算支付通道选项1090，例 如考虑将来知道的结算和汇款选项。图10的流程图示出了根据本发明的实施例的基于规则的支付途径确定方法 1100。在事件1110处，从支付者收到金融支付交易请求。支付者可以使用任何已知的或 将来知道的支付输入通道输入金融交易请求。支付输入通道的示例包括但不限于开放性 财务交换(OFX)/移动、基于网页的、交互式语音响应(IVR)/电话、银行中心、自动柜员机 (ATM)、借记卡/信用卡、商人、支票、图像、电报、自动交换所(ACH)等。在可选事件1120处，金融交易请求可以转换到规范化或标准格式，例如国际标准 化组织(ISO) 20022通用金融产业信息方案等。根据本发明的实施例，最初来自任何已知或 将来知道的输入通道的金融交易请求可被规范/标准化以允许未来的支付交易请求的普 通处理。在这方面，金融支付交易请求的标准格式化提供没有传统库型处理的支付处理，所 述传统库型处理要求支付输入通道与支付汇款通道相同。在事件1130处，基于一个或多个途径规则从多于一种备选支付类型之中为交易 请求确定支付途径。备选支付类型包括任何已知或将来知道的两种或更多种支付类型的组 合。支付类型的示例(即，汇款或结算通道)包括票据/支票、自动交换所(ACH)、电报、世 界银行间金融电信学会(SWIFT)、借记-信用卡、商人、转帐和收集。途径规则可以与任何相关的支付参数关联。例如，途径规则可以与支付处理时间、 支付处理成本/价格、支付处理质量/风险、支付目的地等关联。在一个具体实施例中，途径规则可以用于确定满足时间要求和风险要求的最少成本支付类型。在本发明的某些可选实施例中，确定支付途径可以另外包括将支付者定义的支付 属性/规则应用于一个或多个途径规则以确定支付途径。在某些实施例中，支付者定义的 支付属性，支付属性可以是成本限制、时间限制、风险限制等，支付属性可以在支付者简档 中预先定义，从而金融支付交易输入请求的输入促使对支付者简档的访问从而重新获得可 以应用的支付属性。在本发明的其它实施例中，可以在输入金融支付请求时或者在临近输 入金融支付请求时动态地定义支付者定义的支付属性。在本发明的某些其它可选实施例中，确定支付途径进一步包括将收款人定义的支 付属性/规则应用于一个或多个途径规则以确定支付途径。在某些实施例中，收款人定义 的支付属性(所述支付属性可以是成本限制、时间限制、风险限制、支付目的地等)可在收 款人简档中被预先定义，从而金融支付交易输入请求的输入促使对收款人简档的访问从而 重新获得可以应用的支付属性。在本发明的其它实施例中，可以在金融支付请求输入附近 动态地定义收款人定义的支付属性。在这样的例子中，收款人可以由处理支付的金融机构 通知支付即将到来并且要求收款人定义与交易关联的适当的支付属性/规则。在本发明的其它可选实施例中，确定支付途径可另外包括对一个或多个途径规则 应用金融机构定义的支付属性/规则以确定支付途径。在某些实施例中，处理支付交易的 金融机构可以具有能应用于某些支付的某些支付属性/规则。金融机构定义的支付属性/ 规则可以是从金融机构数据库中可获取的预先定义的属性，或者可以在输入金融支付请求 时或在临近输入金融支付请求时动态地定义金融机构定义的支付属性/规则。 应当注意，可以依赖支付者定义的支付属性/规则、收款人定义的支付属性/规 贝U、和/或金融机构定义的支付属性/规则的任何组合来确定对于任何一种金融支付交易 的支付途径。如果支付交易输入请求在前面已经被标准化到标准格式，在可选事件1140处，支 付交易被重新格式化或者被转化到与所确定的支付途径关联的一种格式。在事件1150处， 金融支付通过所确定的支付途径被提供给收款人。这样，这里描述了方法、设备、系统和计算机程序产品，提供了通过基于一或多个 途径规则在每个支付交易的基础上确定途径来优化金融支付途径。途径规则考虑了支付因 素，例如(但不限于)支付处理的成本、用于支付处理的时间、支付处理的风险/质量、和/ 或支付目的地。从支付者或收款人的角度，与这些或其它支付因素关联的支付者定义的或 收款人定义的支付属性可以在支付者/收款人简档中被预先定义或者在临近发起支付请 求时被动态地定义。在这方面，本发明用于创建在成本、时间性、质量等方面对支付者、收款 人和进行支付处理的金融机构有益的支付处理。虽然前面的内容讨论了示意性实施例，应该知道，在不偏离由权利要求限定的描 述的范围和/或实施例的情况下可以对本发明进行各种改变和修改。另外，虽然描述的内 容和/或实施例的元件可以以单数的形式进行描述或者要求保护，但是也可以使用复数形 式，除非这里明确的指定。另外，任何实施例的所有或者一部分都可以使用任何其它实施例 的所有或者一部分，除非这里另有说明。虽然描述了某些示例性实施例并且以附图形式示出，应当明白这些实施例只是示 意性的而不是用于限定本发明的范围，本发明并不限于具体的结构和示出的配置，由于除了上面提到的这些内容之外可以对其进行各种其它的改变、组合、省略、修改和替代。本领 域技术人员明白在不偏离本发明的精神和范围的情况下可以对描述的实施例进行各种适 应性修改。因此，应明白，在附加权利要求限定的范围内都可以实现本发明而不是仅在这里描述的具体情况中可实现。
权利要求
一种用于处理金融支付的方法，所述方法包括从支付者接收金融支付交易；基于一个或多个途径规则从多于一种备选支付类型之中确定用于该交易的支付途径；以及通过所确定的支付类型向收款人提供金融支付。
2.根据权利要求1所述的方法，其中确定支付途径进一步包括基于一个或多个途径规 则确定支付途径，其中所述途径规则中的至少一个与支付处理时间关联。
3.根据权利要求1所述的方法，其中确定支付途径进一步包括基于一个或多个途径规 则确定支付途径，其中所述途径规则中的至少一个与支付处理成本关联。
4.根据权利要求1所述的方法，其中确定支付途径进一步包括基于一个或多个途径规 则确定支付途径，其中所述途径规则中的至少一个与支付处理风险关联。
5.根据权利要求1所述的方法，其中确定支付途径进一步包括基于一个或多个途径规 则确定支付途径，其中所述途径规则中的至少一个与支付目的地关联。
6.根据权利要求1所述的方法，其中确定支付途径进一步包括基于一个或多个途径规 则确定支付途径，其中所述途径规则中的至少一个与汇款要求关联。
7.根据权利要求1所述的方法，其中确定支付途径进一步包括基于一个或多个途径规 则确定支付途径，其中所述一个或多个途径规则用于确定满足时间要求和风险要求的最少 成本支付类型。
8.根据权利要求1所述的方法，进一步包括接收一个或多个支付者定义的支付属性， 并且其中确定支付途径进一步包括对于所述一个或多个途径规则应用支付者定义的支付 属性以确定支付途径。
9.根据权利要求8所述的方法，其中接收一个或多个支付者定义的支付属性进一步 包括接收所述一个或多个支付者定义的支付属性，其中每个属性进一步被定义为与支付时 间、支付成本、支付风险、汇款要求或者支付目的地中的至少一个相关。
10.根据权利要求8所述的方法，其中接收所述一个或多个支付者定义的支付属性进 一步包括访问支付者简档数据库以从与支付者关联的支付者简档中获得一个或多个支付 者定义的支付属性。
11.根据权利要求8所述的方法，其中接收所述一个或多个支付者定义的支付属性进 一步包括接收所述一个或多个支付者定义的支付属性，其中所述属性是由支付者在与金融 支付请求基本相同的时间点定义的。
12.根据权利要求1所述的方法，进一步包括接收一个或多个收款人定义的支付属性， 并且其中确定支付途径进一步包括对于所述一个或多个途径规则应用收款人定义的支付 属性以确定支付途径。
13.根据权利要求12所述的方法，其中接收一个或多个支付者定义的支付属性进一步 包括接收所述一个或多个支付者定义的支付属性，其中每个属性进一步被定义为与支付时 间、支付成本、支付风险、汇款要求或支付目的地中的至少一个相关。
14.根据权利要求12所述的方法，其中接收所述一个或多个收款人定义的支付属性进 一步包括访问收款人简档数据库以从与收款人关联的收款人简档中获取所述一个或多个 收款人定义的支付属性。
15.根据权利要求12所述的方法，其中接收一个或多个收款人定义的支付属性进一步 包括接收所述一个或多个收款人定义的支付属性，其中所述属性是由收款人在临近金融支 付请求的时间定义的。
16.根据权利要求1所述的方法，进一步包括接收一个或多个交易处理金融机构定义 的支付属性，并且其中确定支付途径进一步包括对于所述一个或多个途径规则应用金融机 构定义的支付属性以确定支付途径。
17.根据权利要求1所述的方法，进一步包括接收一个或多个交易处理金融机构定义 的支付属性、一个或多个支付者定义的支付属性或者一个或多个收款人定义的支付属性中 的至少一个，并且其中确定支付途径进一步包括对于一个或多个途径规则应用金融机构定 义的支付属性、以及支付者定义的支付属性或收款人定义的支付属性中的至少一个来确定 支付途径。
18.根据权利要求1所述的方法，进一步包括在确定支付途径之前将金融支付交易转 换到标准格式。
19.根据权利要求18所述的方法，进一步包括在通过所确定的支付类型向收款人提供 金融支付之前将金融支付交易转换到与所确定的支付途径关联的格式。
20.根据权利要求1所述的方法，其中从多于一种备选支付类型之中确定用于该交易 的支付途径进一步将备选支付类型定义为支票支付、自动化交换所(ACH)支付、电报支付、 卡支付、商人支付、转帐支付或全世界国际金融电信学会(SWIFT)支付的组中的任何两种。
21.一种用于处理金融支付的设备，所述设备包括 计算机平台，包括至少一个处理器和存储器；途径规则数据库，存储在存储器中并用于存储一个或多个途径规则；以及 支付途径确定逻辑，可由所述处理器执行，并且用于基于对一个或多个途径规则的应 用从多于一种备选支付类型之中确定对于支付交易的支付途径。
22.根据权利要求21所述的设备，其中所述途径规则中的至少一个与支付处理时间关联。
23.根据权利要求21所述的设备，其中所述途径规则中的至少一个与支付处理成本关联。
24.根据权利要求21所述的设备，其中所述途径规则中的至少一个与支付处理风险关联。
25.根据权利要求21所述的设备，其中所述途径规则中的至少一个与支付目的地关联。
26.根据权利要求21所述的设备，其中所述途径规则中的至少一个与汇款要求关联。
27.根据权利要求21所述的设备，其中一个或多个途径规则用于确定满足时间要求和 风险要求的最少成本支付类型。
28.根据权利要求21所述的设备，其中所述支付途径确定逻辑进一步用于将一个或多 个支付者定义的支付属性应用于一个或多个途径规则以确定支付途径。
29.根据权利要求28所述的设备，其中支付者定义的支付属性进一步被定义为每个属 性与支付时间、支付成本、支付风险、汇款要求或者支付目的地中的至少一个相关。
30.根据权利要求28所述的设备，其中所述支付途径确定逻辑进一步用于访问支付者简档数据库以从与支付者关联的支付者简档获取一个或多个支付者定义的支付属性。
31.根据权利要求28所述的设备，其中所述支付途径确定逻辑进一步用于接收所述一 个或多个支付者定义的支付属性，其中所述属性是由支付者在与金融支付请求基本相同的 时间点定义的。
32.根据权利要求21所述的设备，其中所述支付途径确定逻辑进一步用于将一个或多 个收款人定义的支付属性应用于一个或多个途径规则以确定支付途径。
33.根据权利要求32所述的设备，其中所述收款人定义的支付属性进一步被定义为每 个属性与支付时间、支付成本、支付风险、汇款要求或者支付目的地中的至少一个相关。
34.根据权利要求32所述的设备，其中所述支付途径确定逻辑进一步用于访问收款人 简档数据库以从与收款人关联的收款人简档获取一个或多个收款人定义的支付属性。
35.根据权利要求32所述的设备，其中所述支付途径确定逻辑进一步用于接收一个或 多个收款人定义的支付属性，其中所述属性是由收款人在临近金融支付请求的时间点定义 的。
36.根据权利要求21所述的设备，其中所述支付途径确定逻辑进一步用于将一个或多 个金融机构定义的支付属性应用于一个或多个途径规则以确定支付途径。
37.根据权利要求21所述的设备，其中所述支付途径确定逻辑进一步用于将一个或多 个金融机构定义的支付属性、以及一个或多个支付者定义的支付属性或者一个或多个收款 人定义的属性中的至少一个应用于一个或多个途径规则以确定支付途径。
38.根据权利要求21所述的设备，进一步包括支付交易转换逻辑，其可由处理器执行 并且用于在确定支付途径之前将金融支付交易转换为标准格式。
39.根据权利要求38所述的设备，其中所述支付交易转换逻辑进一步用于在通过所确 定的支付类型向收款人提供支付之前将金融支付交易转换为与所确定的支付途径关联的 格式。
40.根据权利要求21所述的设备，其中所述支付途径确定逻辑进一步用于从多于一种 备选支付类型之中确定对于支付交易的支付途径，其中备选的支付类型是从支票支付、自 动化票据交换所(ACH)支付、电报支付、卡支付、商人支付、转帐支付、或者全世界国际金融 电信学会(SWIFT)支付的组中的两个中选择的。
41.一种计算机程序产品，包括计算机可读介质，所述计算机可读介质包括第一组代码，用于使计算机从支付者接收金融支付交易；第二组代码，用于使计算机基于一个或多个途径规则从多于一种备选支付类型之中确 定对于该交易的支付途径；以及第三组代码，用于使计算机通过所确定的支付类型向收款人提供金融支付。
42.根据权利要求41所述的计算机程序产品，其中所述第二组代码进一步包括用于使 计算机基于一个或多个途径规则确定支付途径的第二组代码，其中所述途径规则中的至少 一个与支付处理时间关联。
43.根据权利要求41所述的计算机程序产品，其中所述第二组代码进一步包括用于使 计算机基于一个或多个途径规则确定支付途径的第二组代码，其中所述途径规则中的至少 一个与支付处理成本关联。
44.根据权利要求41所述的计算机程序产品，其中所述第二组代码进一步包括用于使 计算机基于一个或多个途径规则确定支付途径的第二组代码，其中所述途径规则中的至少 一个与支付处理风险关联。
45.根据权利要求41所述的计算机程序产品，其中所述第二组代码进一步包括用于使 计算机基于一个或多个途径规则确定支付途径的第二组代码，其中所述途径规则中的至少 一个与支付目的地关联。
46.根据权利要求41所述的计算机程序产品，其中所述第二组代码进一步包括用于使 计算机基于一个或多个途径规则确定支付途径的第二组代码，其中所述途径规则中的至少 一个与汇款要求关联。
47.根据权利要求41所述的计算机程序产品，其中所述第二组代码进一步包括用于使 计算机基于一个或多个途径规则确定支付途径的第二组代码，其中所述一个或多个途径规 则用于确定满足时间要求和风险要求的最低成本支付类型。
48.根据权利要求41所述的计算机程序产品，进一步包括用于使计算机接收一个或多 个支付者定义的支付属性的第四组代码，并且其中第二组代码进一步包括用于使计算机将 支付者定义的支付属性应用于一个或多个途径规则以确定支付途径的第二组代码。
49.根据权利要求48所述的计算机程序产品，其中第四组代码进一步包括用于使计算 机接收一个或多个支付者定义的支付属性的第四组代码，其中每个属性进一步被定义为与 支付时间、支付成本、支付风险、汇款要求或支付目的地中的至少一个相关。
50.根据权利要求48所述的计算机程序产品，其中所述第四组代码进一步包括用于使 计算机访问支付者简档数据库以从与支付者关联的支付者简档获取一个或多个支付者定 义的支付属性的第四组代码。
51.根据权利要求48所述的计算机程序产品，其中所述第四组代码进一步包括用于使 计算机接收一个或多个支付者定义的支付属性的第四组代码，其中所述属性是由支付者在 与金融支付请求基本相同的时间点定义的。
52.根据权利要求41所述的计算机程序产品，进一步包括第四组代码，用于使计算机 接收一个或多个收款人定义的支付属性，并且其中第二组代码进一步包括用于使计算机将 收款人定义的支付属性应用于一个或多个途径规则以确定支付途径的第二组代码。
53.根据权利要求52所述的计算机程序产品，其中所述第四组代码进一步包括用于使 计算机接收一个或多个收款人定义的支付属性的第四组代码，其中每个属性进一步被定义 为与支付时间、支付成本、支付风险、汇款要求或支付目的地中的至少一个相关。
54.根据权利要求52所述的计算机程序产品，其中所述第四组代码进一步包括用于使 计算机访问收款人简档数据库以从与收款人关联的收款人简档接收一个或多个收款人定 义的支付属性的第四组代码。
55.根据权利要求52所述的计算机程序产品，其中所述第四组代码进一步包括用于使 计算机接收一个或多个收款人定义的支付属性的第四组代码，其中所述属性是由收款人在 与金融支付请求基本相同的时间点定义的。
56.根据权利要求41所述的计算机程序产品，进一步包括第四组代码，用于使计算机 接收一个或多个交易处理金融机构定义的支付属性，并且其中第二组代码进一步包括用于 使计算机将金融机构定义的支付属性应用于一个或多个途径规则以确定支付途径的第二组代码。
57.根据权利要求41所述的计算机程序产品，进一步包括第四组代码，用于使计算机 接收一个或多个交易处理金融机构定义的支付属性、以及一个或多个支付者定义的支付属 性或一个或多个收款人定义的属性中的至少一个，并且其中第二组代码进一步包括用于使 计算机将金融机构定义的支付属性、以及一个或多个支付者定义的支付属性或一个或多个 收款人定义的支付属性中的至少一个应用于一个或多个途径规则以确定支付途径的第二 组代码。
58.根据权利要求41所述的计算机程序产品，进一步包括第五组代码，用于使计算机 在确定支付途径之前将金融支付交易转换为标准格式。
59.根据权利要求58所述的计算机程序产品，其中第五组代码进一步包括用于在通过 所确定的支付类型向收款人提供金融支付之前使计算机将金融支付交易转换为与所确定 的支付途径关联的格式的第五组代码。
60.根据权利要求41所述的计算机程序产品，其中第二组代码进一步包括用于使计算 机从多于一种备选支付类型之中确定对于该交易的支付途径的第二组代码，其中备选支付 类型进一步被定义为支票支付、自动化票据交换所(ACH)支付、电报支付、卡支付、商人支 付、转帐支付或者全世界国际金融电信学会(SWIFT)支付的组中的任何两个。
全文摘要
本发明涉及一种系统、方法和计算机程序产品。提供一种通过基于一个或多个途径规则在每个支付交易的基础上确定途径来优化金融支付途径的系统、方法和计算机程序产品。途径规则考虑进了支付因素，例如(但不限于)支付处理成本、支付处理时间、支付处理风险/质量、汇款要求和/或支付目的地。从支付者或收款人角度，与这些或其它支付因素关联的支付者定义的或收款人定义的支付属性可以在支付者/收款人简档中预先定义或者在与发起支付请求的时间附近动态地定义。这方面，本实施例用于创建在成本、时间、质量等方面对支付者、收款人和进行支付处理的金融机构都有益的支付处理。
文档编号G06Q20/00GK101847235SQ201010148999
公开日2010年9月29日 申请日期2010年2月11日 优先权日2009年2月13日
发明者A·B·卡尔代罗尼, D·T·弗瑞维, E·多耶尔, G·C·博瑞格斯, K·坎特利, M·D·赞佐特, P·托宾, W·E·托马斯二世 申请人:美国银行公司