CN108140187A - 用于支付处理系统的分析规则引擎 - Google Patents

Abstract

根据一些实施例，支付系统授权平台可以从收单方平台接收授权消息。支付系统授权平台可以确定授权请求满足预定条件并且例如通过发送授权消息而向分析规则引擎发送关于授权消息的信息。分析规则引擎可以根据至少一个规则分析关于授权消息的信息以生成结果并且例如通过发送补充授权消息或授权批准决定而将关于授权消息的信息发送到支付系统授权平台，包括授权消息被分配到细分维度类别的指示。

Description

用于支付处理系统的分析规则引擎

相关申请的交叉引用

本申请要求于2015年7月14日提交的美国专利申请第14/798,792号的优先权，其内容通过引用整体并入本文。

技术领域

这里公开的实施例涉及包括便于处理支付卡交易的分析规则引擎的方法、装置和系统。

背景技术

支付卡系统被广泛使用。由本发明的受让人万事达国际公司和其成员金融机构运营著名的支付卡系统。图1示意性地示出了通过使用传统支付系统100执行的典型交易。为了启动交易，客户可以访问由商家操作的零售商店，选择他/她希望购买的商品，并且将他/她的支付卡呈现给商家的销售点(“POS”)终端。POS终端从支付卡中读取客户的支付卡账号，然后将授权请求发送到与商家有关系的金融机构相关联的收单方平台110。授权请求通常包括支付卡账号、交易金额和其他信息，例如商家标识和位置。授权请求消息经由支付系统授权平台120(其可以是例如由万事达国际公司运营的众所周知的Banknet^TM系统)路由到发行该客户的支付卡的发行方金融机构的发行方平台130。

假设全部都正常，发行方平台130通过支付系统授权平台120向收单方平台110发送有利的授权响应。然后完成POS处的交易，并且客户携带商品离开商店。由商家发起的后续清算交易导致交易金额从客户的支付卡账户转移到属于商家的账户。客户的支付卡账户可以是例如借记卡账户或信用卡账户。在前一种情况下，清算交易导致资金直接从账户中扣除。在后一种情况下，清算交易导致针对该账户发生的费用，并且该费用随后出现在客户的每月信用卡账单中。

典型交易的上述描述在某些方面可以被认为是有点简化的。例如，商家处理系统(未示出)可以介于POS终端和收单方平台110之间。如本领域技术人员所熟悉的，商家处理系统可以由商家或代表商家操作以形成收单方平台110和由商家操作的大量POS终端之间的通信路径的一部分。通常情况下，第三方交易处理服务(例如支付服务提供商(“PSP”))可以操作以代表收单方以及代表大量其他类似的金融机构来处理支付卡交易。

除了POS交易之外，收单方平台110可以以类似的方式处理与自动柜员机(“ATM”)提款和无卡交易(“CNP”)在线交易相关联的交易。

支付卡持有人、收单方和发行方金融机构以及支付系统授权平台都有意减少欺诈性交易。此外，希望减少欺诈性交易，而不会降低事实上并不是欺骗性的交易。

虽然获得批准的授权可为发卡机构带来收入机会，但请注意，会存在由于授权拒绝不当导致的收入负面影响。例如，听到持卡人在他们一直在做某件事时被拒绝的讲述或抱怨低价值交易被拒绝的情况并不少见。虽然这对所有持卡人都是一个挑战，但对于消费额极高的卡可能尤其重要。因此，发卡机构可能会努力确保最佳的持卡人拥有持续使用他们的卡的经验，既有实时使用，也有持续的客户服务机会(例如激励，卡重发政策等)。这样做可能有助于实现与接收着重于重要持卡人的最新洞察和正在执行的当前交易相关的收入机会、成本收益和运营效率。

本发明人已经认识到，需要提供分析规则引擎以促进支付卡交易处理的方法和/或系统。

附图说明

图1显示了典型的支付卡系统。

图2是根据一些实施例的系统的框图示意图。

图3是根据一些实施例可以执行的支付系统授权方法。

图4是根据一些实施例可以执行的分析规则引擎方法。

图5、图6A和图6B示出根据一些实施例的交易流程。

图7表示根据一些实施例的分析规则引擎。

图8是根据一些实施例可以提供的支付系统授权平台。

图9是根据一些实施例可以提供的支付系统授权数据库。

图10是根据一些实施例可以提供的分析规则引擎。

图11是根据一些实施例可以提供的分析规则引擎数据库。

图12是根据一些实施例的决策管理简档系统的高级框图。

图13是根据一些实施例可以执行的细分方法。

图14示出与一些实施例相关联的几个持卡人维度。

图15示出了根据一些实施例的关于有卡借记卡交易的详细信息。

图16是根据一些实施例的如何可以将信息添加为授权消息中的新数据元素的示例。

具体实施方式

通常，并且为了引入本发明的实施例的概念的目的，可以使用“支付卡”来处理交易。如本文所使用的，短语“支付卡”可以指例如信用卡、借记卡、忠诚计划卡、徽章、许可证、护照卡、射频装置、智能电话和/或非接触式卡。

图2是包括被配置为根据本文描述的过程的各方面操作的组件的交易处理系统200的框图。应该理解的是，图2中所示的各种组件可以是用于向消费者提供支付卡推荐以及用于促进消费者和商家之间的通过信用卡账户、借记卡账户、奖励卡账户、其他类型的财务账户等的购买交易和/或用于促进一个或多个金融机构(例如收单方和发行银行)之间的支付交易的较大系统的子集。

如前所述，收单平台210可以经由支付授权平台220请求来自发行方平台230的支付卡交易的授权。为了减少欺诈交易，支付系统授权平台220可以根据这里描述的任何实施例与分析规则引擎250交换信息。根据一些实施例，分析规则引擎250进一步包括关于图13到图16更详细描述的细分引擎252。

例如，图3示出了根据本发明的一些实施例可以由关于图2描述的系统200的支付系统授权平台220执行的方法300。这里描述的流程图并不意味着步骤的固定顺序，并且本发明的实施例可以以可行的任何顺序实施。注意，这里描述的任何方法可以通过硬件、软件或这些方法的任何组合来执行。例如，计算机可读存储介质可以在其上存储当由机器执行时导致根据本文描述的任何实施例的执行的指令。进一步注意，一些或全部步骤可以是“自动化的”。如本文所使用的，术语“自动化的”可以指例如可以在有很少人为干预或没有人为干预的情况下执行的动作。

在S310，支付系统授权平台可以从收单方平台接收授权消息。在S320处，支付系统授权平台可以确定授权请求满足预定条件。该确定可以基于例如与授权请求相关联的银行识别号码(“BIN”)和/或16位主账号。

响应于该确定，可以在S330将关于授权消息的信息传送到分析规则引擎。传送可以包括例如将授权消息转发到分析规则引擎。

在S340，支付系统授权平台可以从分析规则引擎接收信息。从分析规则引擎接收的信息可以包括例如补充的授权消息。根据一些实施例，补充的授权消息包括以下中的至少一个：(i)风险标志，(ii)风险评分，(iii)持卡人类别，(iv)终端类别，以及(v)增强型专家监控服务评分数据。请注意，增强型专家监控服务评分数据在本文中仅用作示例，并且实施例可以以许多不同方式中的任何一种来提供信息。根据一些实施例，系统可以用理由代码(例如字母数字“A1”)来补充授权消息，该理由代码然后可以以某种预定义方式由客户(例如，发行方，商家)进行解释(例如，“A1”是经常旅行者(Frequent Traveler)的持卡人类别)。风险标志、风险评分和评分数据可以全部补充到授权消息中。例如，这些项目可能会被其他服务所添加，这些服务可能会消耗/引用理由代码来帮助生成风险评分。根据一些实施例，评分数据可以与应用程序相关联以监视支出合规性(例如，对政府规则和法规的符合性)和/或防止欺诈和滥用。

然后可以将补充的授权消息转发给以下中的至少一个：(i)收单方平台，以及(ii)发行方平台。例如，发行方平台可能使用补充数据来进一步评估风险，以帮助决定是否应该批准交易。

图4示出了根据一些实施例可以由图2的系统200的分析规则引擎250执行的分析规则引擎方法400。在S410处，分析规则引擎可以从支付系统授权平台接收关于授权消息的信息。所接收的信息可以包括例如授权消息。在S420，分析规则引擎可以根据至少一个规则分析关于授权消息的信息以生成结果。规则可以基于例如关于以下中的至少一个的信息：(i)与授权消息相关联的持卡人，(ii)与授权消息相关联的账户，(iii)与授权消息相关联的支付卡，(iv)与授权消息相关联的商家，以及(v)与授权消息相关联的商家终端。

根据一些实施例，该规则基于旅行类别。例如，持卡人可能被归类为国际旅行者、州际旅行者或从不旅行的人。然后可以使用该信息来标记不寻常的活动(例如，与在远处的州或国家使用从未旅行的人相关联的卡)。

除了扩展的持卡人视图之外，实施例可以提供扩展的终端视图(例如，用于ATM)。例如，一条规则可能会询问当前的ATM活动是否正常，当前的ATM交易是否适合该持卡人的历史ATM模式，他或她通常会取款多少，通常在该终端出现多少次提款(例如，每天、每周或每月)，该持卡人通常发生多少次取款(例如，每天、每周或每月)，持卡人的单次最大取款额和/或持卡人是否在旅行。在某些情况下，规则可能是基于持卡人是否与旅行商家进行了近期交易，其将指示他或她将来可能旅行，这是假卡的可能性有多大，交易是否是典型的(对于这个ATM终端或持有人)，在该位置是否使用了特定的发行方的卡，过去没有这样经常使用卡，通常提取多少现金(每小时、每天、每周或每月)，和/或取款的最大金额。请注意，实施例可以让一个人查看多个发行方的终端活动。

根据一些实施例，规则基于在线消费类别，持卡人是季节性购物者、已确认的购物者还是从不在线购物的人。请注意，实施例可以在足够长的时间段内审查持卡人活动以考虑季节性消费(例如，圣诞节，情人节，“网络星期一(Cyber Monday)”)，为每个细分以及在每个细分内建立自定义支出水平，允许持续地以相互期望的频率刷新此细分，和/或管理授权策略以优化审批，同时平衡欺诈风险。

请注意，规则可以基于关于与授权消息相关联的终端的信息，诸如(i)交易频率，(ii)交易金额，和/或(iii)交易位置。进一步注意，规则可以基于与授权消息相关联的发行方之外的发行方，除了与授权消息相关联的持卡人之外的持卡人，和/或除了与授权消息相关联的终端之外的终端。请注意，除了与授权消息相关联的发行方之外，规则可以包含来自其他发行方的信息。在一些实施例中，(一个或多个)规则不仅基于与授权消息相关联的发行方、持卡人、商家和终端，而且还包括来自与授权消息不相关的其他发行方、持卡人、商家和终端的信息。

响应于结果，可以在S430将关于授权消息的信息传送到支付系统授权平台。传送到支付系统授权平台的信息可能包括补充授权消息。根据一些实施例，补充授权消息包括以下中的至少一个：(i)风险标志，(ii)风险评分，(iii)持卡人类别，(iv)终端类别，以及(v)增强评分数据。根据一些实施例，评分数据可以与应用程序相关联以监视支出合规性(例如，对政府规则和法规的符合性)和/或防止欺诈和滥用。

举例来说，考虑图5，图5图示了根据一些实施例的信息流500。最初，收单方平台510向支付系统授权平台520发送授权消息(例如，ISO0100/0200消息)。支付系统授权平台520将授权消息转发给分析规则引擎550，该分析规则引擎550可以按照一个或多个规则来分析该消息。例如，分析规则引擎550可以确定交易与不寻常的持卡人或终端活动相关联。该信息可以被丢弃到授权消息中，并且补充授权消息可以被发送到支付系统授权平台520。支付系统授权平台520将补充授权消息转发到发行方平台530，发行方平台530可以使用增广的和增强的数据来确定是否接受或拒绝交易(例如，通过ISO 0110/0210消息)。根据一些实施例，分析规则引擎550进一步包括关于图13到图16更详细描述的细分引擎552。

代替发送由发行方平台530使用的补充认证消息，分析规则引擎550可以替代地做出初始批准(或拒绝)决定。举例来说，考虑图6A，图6A示出了根据这样的实施例的信息流600。如前所述，收单方平台610将授权消息(例如，ISO 0100/0200消息)发送到支付系统授权平台620。支付系统授权平台620将授权消息转发给分析规则引擎650，分析规则引擎650可以按照一个或多个规则分析消息。例如，分析规则引擎650可以确定特定交易与不寻常的持卡人或终端活动相关联。分析引擎650可以使用该信息来拒绝交易(在涉及发行方平台630之前)。如果分析规则引擎650反而批准交易，则支付系统授权平台620将(标准或补充)授权消息转发给发行方平台630，发行方平台630可以确定是接受还是拒绝交易(例如，通过ISO 0110/0210信息)。

考虑通过收单方平台610从电子商家接收的相对高金额的跨境电子商务授权。支付系统授权平台620可以将授权消息路由到分析规则引擎650。分析规则引擎650可以在账户上进行实时查询以了解关于持卡人的其他特征。特别是，确定持卡人从不在线购物。因此，分析规则引擎会拒绝交易。根据一些实施例，进一步的在线授权被阻止预定的时间窗口(例如，两个小时)。根据一些实施例，分析规则引擎650进一步包括关于图13到图16更详细描述的细分引擎652。

作为另一个示例，考虑图6B，图6B示出了根据另一个实施例的信息流602。在这种情况下，发行方平台632调用分析规则共享服务入口652，其可以根据一个或多个规则分析交易请求。例如，分析规则共享服务入口652可以确定交易与不寻常的商家活动相关联。分析规则共享服务入口652可以使用该信息拒绝交易(不涉及支付系统授权平台)。如果分析规则共享服务入口652反而提供风险谱评分，则发行方平台632然后可以使用评分来确定是接受还是拒绝交易(例如，通过ISO 0110/0210消息)。根据一些实施例，分析规则共享服务入口652可以考虑从特定授权消息之外的源构建的风险数据。此外，分析规则共享服务入口652可以与访问各个终端的欺诈数据速率和/或基于从其他发行方报告的信息确定的风险数据的欺诈数据市场相关联。

请注意，此处描述的任何分析规则都可以与各种各样风险参数相关联。例如，持卡人和/或网络级别分析可将数据洞察整合到实时授权和欺诈策略中。此外，行为洞察可能集中在商家级别的数据上，以查看多种支付卡类型的活动。商家级分析考虑的示例包括零售/花费类别(例如，汽车燃料，书店购买，订购服务等)和花费类别分类(例如百货商店，电器商店，加油站，邮购订单等)。分析规则还可以评估花费速度参数以查找在一天的特定时间异常量的交易、异常交易量和/或批准和/或拒绝交易量中的可疑变化。根据一些实施例，可以使用历史配额来允许商家口号或特定位置的差异。

图7示出了根据一些实施例的分析规则引擎750，其可以接收和利用第三方数据、发行方交易数据、发行方报告数据、收单方交易数据、数据仓库数据和/或批处理或实时数据(其可能与任何品牌、单一消息和双重消息相关联)以根据一些实施例生成应用于行为细分、投资组合诊断、市场和竞争洞察、和/或忠诚和奖励计划的结果。

这里描述的实施例可以使用任何数量的不同硬件配置来实现。例如，图8示出了可以例如与图2的系统200相关联的支付系统授权平台800。支付系统授权平台800包括处理器810，诸如单芯片微处理器形式的一个或多个商业上可用的中央处理单元(CPU)，其耦接到通信设备820，该通信设备820被配置为经由通信网络(图8中没有示出)进行通信。支付系统授权平台800还包括输入设备840(例如，鼠标和/或键盘)和输出设备850(例如计算机监视器)。

处理器810还与存储设备830进行通信。存储设备830可以包括任何适当的信息存储设备，包括磁存储设备(例如，硬盘驱动器)、光存储设备、移动电话和/或半导体存储器设备的组合。存储设备830存储用于控制处理器810的程序88和/或通信引擎814(例如，与通信引擎插件相关联)。处理器810执行程序812,814的指令，从而按照与这里描述的任何实施例进行操作。例如，处理器810可以从收单方平台接收授权消息。处理器810可以确定授权请求满足预定条件并且诸如通过发送授权消息来向分析规则引擎发送关于授权消息的信息。

程序812,814可以以压缩的、未编译的和/或加密的格式存储。程序812,814还可以包括其他程序元件，诸如操作系统、数据库管理系统和/或由处理器810使用以与外围设备接口连接的设备驱动程序。

如这里所使用的，信息可以由例如以下“接收”或“发送”到例如以下：(i)来自另一个设备的支付系统授权平台800；或(ii)来自另一软件应用程序、模块或任何其他来源的支付系统授权平台800内的软件应用程序或模块。

在一些实施例中(诸如图8所示)，存储设备830还存储交易数据库900、收单方数据860和发行方数据870。现在将关于图9详细描述可以结合支付系统授权平台800使用的数据库的示例。注意，这里描述的数据库仅是一个示例，并且附加和/或不同的信息可以被存储在其中。此外，各种数据库可以根据本文描述的任何实施例被拆分或组合。

参考图9，示出了根据一些实施例的表格，表格表示可以存储在支付系统授权平台800处的交易数据库900。该表格可以包括例如识别支付卡交易的条目。该表格还可以为每个条目定义字段902,904,906。根据一些实施例，字段902,904,906可以指定：交易标识符902、授权消息904和补充授权消息906。可以例如基于从收单方平台和分析规则引擎接收到的信息来创建和更新交易数据库900。

图10示出了分析规则引擎1000，其可以例如与图2的系统200相关联。分析规则引擎1000包括耦接到通信设备1020的处理器1010，诸如单芯片微处理器形式的一个或多个商业可用的中央处理单元(CPU)，通信设备1020被配置为经由通信网络(未在图10中示出)进行通信。分析规则引擎1000还包括输入设备1040(例如，鼠标和/或键盘)和输出设备1050(例如，计算机监视器)。

处理器1010还与存储设备1030通信。存储设备1030可以包括任何适当的信息存储设备，包括磁存储设备(例如，硬盘驱动器)、光存储设备、移动电话和/或半导体存储器设备的组合。存储设备1030存储用于控制处理器1010的程序1012和/或通信引擎1014(例如，与通信引擎插件相关联)。处理器1010执行程序1012,1014的指令，从而按照与这里描述的任何实施例进行操作。例如，处理器1010可以根据至少一个规则分析关于授权消息的信息以生成结果，并且将关于授权消息的信息发送到支付系统授权平台，诸如通过发送补充授权消息或授权批准决定。

程序1010,1014可以以压缩的、未编译的和/或加密的格式存储。程序1010,1014还可以包括其他程序元件，诸如操作系统、数据库管理系统和/或由处理器1010使用以与外围设备接口连接的设备驱动程序。

如本文所使用的，信息可以被例如以下“接收”或“发送”到例如以下：(i)来自另一个设备的分析规则引擎1000；或(ii)来自另一软件应用程序、模块或任何其他源的分析规则引擎1000内的软件应用程序或模块。

在一些实施例中(诸如图10所示)，存储设备1030还存储交易数据库1100、第三方数据1060和历史数据1070。现在将参照图11详细描述可以结合分析规则引擎1000使用的数据库的示例。请注意，这里描述的数据库仅是一个示例，并且附加和/或不同的信息可以被存储在其中。此外，各种数据库可以根据本文描述的任何实施例被拆分或组合。

参考图11，示出了根据一些实施例的表格，表格表示可以存储在支付系统授权平台800处的交易数据库1100。该表格可以包括例如识别支付卡交易的条目。该表格还可以为每个条目定义字段1102,1104,1106。根据一些实施例，字段1102,1104,1106可以指定：交易标识符1102，授权消息1104和补充授权消息1106。交易数据库1100可以例如基于自收单方平台和分析规则引擎接收的信息被创建和更新。

本文描述的任何数据库和/或分析规则可以用于将数据洞察整合到实时授权和/或欺诈策略中。例如，图12是根据一些实施例的决策管理简档系统1200的高级框图。分析规则引擎1250可以访问持卡人细分简档1212，其可包括旅行者信息1212、富裕持卡人信息1214、商家信息1216和/或其他数据。类似地，分析规则引擎1250可以访问诸如商家信息1232、终端信息1234和/或其它信息1236的客户变量1220和网络简档1230。以这种方式，欺诈规则管理器平台可以利用信息在在线授权内为参与的发行方提供实时补充数据，其可通过接收决策或规则平台进行消费和解读，以做出更有信心的批准或拒绝决定。

通过使用卡级数据和POI终端级数据为发行方提供实时比较数据智能，发行方可以拥有更广泛的上下文信息集合，以更好地识别何时可以安全地批准可能由于信息不足而在之前被拒绝的交易。

与分析规则引擎1250相关联的数据智能可以包括支付卡系统收集和分析的卡级别数据，例如对发行方的投资组合的短期和长期卡花费活动，包括例如；地理位置、交易类型、消费类别和金额等级模式以及持卡人验证方法(即，EMV对PIN或磁条)。根据一些实施例，可以在在线授权消息中提供这些比较数据中的一些或全部。

与分析规则引擎1250相关联的数据智能还可以包括网络级数据。例如，支付卡系统可以分析全球网络信息以在授权消息中提供实时评分，包括花费水平和模式以及POI终端处的最近欺诈率。

对于参与分析规则服务的发行方账户范围，分析规则引擎1250可以评估交易内的关键数据元素值，并将这些数据与该特定持卡人PAN和其中交易正在发生的特定终端的短期和长期历史数据点进行比较。这些比较的结果可能会在被转发给发行方或关联方之前在在线消息中提供。

根据一些实施例，分析规则引擎1250可以将上下文数据点实时填充到在线消息中以供由服务处理交易。消息中填充的每个数据值可以被编码以向接收决策系统指示例如与该特定授权请求有关的有价值的信息，并且可以向发行方提供改进的置信水平以适当地批准或拒绝交易。

来自分析规则引擎的值可能以多种不同的方式提供。根据一些实施例，可以将数据片段值本身(例如，持卡人类别、商家类别、终端类别等)呈现给允许它们以它们选择的任何方式使用数据的一方。根据其他实施例，数据片段值可以与其他可用数据输入一起使用以生成置信度评分。该置信度评分可以例如表示在000和999之间的范围，其中最高评分值表示交易是欺诈性的更大可能性并且最低分值表示交易是真实的(即，非欺诈性)的更大可能性。

请注意，这两种数据类型(数据片段值和置信度评分值)的递送也可能以多种不同的方式发生。根据一些实施例，通过专用于系统的指定数据元素在授权请求本身内提供数据。根据其他实施例，可以对共享服务入口(其可以用适当的数据进行响应)进行web应用程序编程接口调用。例如，这种共享服务入口方法可以改善与从授权消息处理新数据字段相关联的软件开发费用和/或递送时间表。

请注意，获得批准的授权对发卡机构而言可能非常重要。虽然获得批准的授权为发卡机构带来了收入机会，但授权拒绝不当也会对收入产生负面影响。本文描述的一些实施例可以在基本上实时的授权过程中以历史卡花费洞察的形式促进细分能力。这种方法可以帮助各方为其投资组合中最优秀的持卡人提供更具针对性和一致性的批准流程。

听到持卡人关于在他们做经常做的某事时遭到拒绝的讲述或关于低价值交易被拒的投诉并不罕见。虽然这对所有持卡人都是一个挑战，但对于花费额最高的卡可能尤其重要。与典型投资组合中的下一个最接近的花费组相比，这些最高花费者可能：交易量是通常的两倍；每笔交易花费50-100％以上；在分析的时间段内，总账户花费水平高数倍；占批准花费总额的多达30-40％；以及占受拒绝影响的账户和金额的多达50％。

发卡机构认识到正确识别这些高消费持卡人的重要性。但是，创建和维护这种类型的实时洞察的能力对于发卡机构来说可能是非常耗费资源和昂贵的。这里描述的一些实施例可以提供基本的细分能力，其可以帮助将授权策略集中在其可以产生最大影响的位置。

标准拒绝和欺诈率指标可能会让一个管理良好的投资组合更加亲密，但他们并没有说清楚。许多投资组合可能拥有绝大多数批准的账户/总美元价值(“GDV”)和高度集中在一小部分卡上的拒绝账户/GDV。因此，即使很低的拒绝和欺诈率也足以掩盖重大的投资组合收入机会。

这里描述的一些实施例可以提供简单且可管理的解决方案来在这些卡被使用时识别这些卡。并非简单地关注如何使用卡(例如，磁条，Europay，万事达卡和Visa(“EMV”)，非接触式支付或数字安全远程支付(“DSRP”))，实施例可以提供关注持卡人，并且对其他交互点(“POI”)努力是补充性的能力。

请注意，通过信用卡平台最有利可图的渠道运行的交易(例如跨境交易)通常可以由投资组合中的最佳花费卡执行。此外，就商家空间尤其是大型在线数字零售商而言，大型在线零售商的授权拒绝与最佳花费持卡人之间也可能存在相关性。提供有关这些持卡人的实时洞察的能力可能会提供具有竞争力的差异。保持和发展积极的持卡人基础对于发卡机构来说非常重要，因为收单可能是非常耗时且费用昂贵的事情。由于大部分GDV机会存在于少数总体账户中，因此这种洞察更为重要。

本文描述的一些实施例可以提供对于通过我们的网络处理的每个授权以持续方式与客户进行交互的能力。此外，实施例可提供可帮助促进持续对话、重复收入流机会和/或持续综合咨询机会的“粘性”参与模型。

风险较高的交易并不总是等同于风险较高的持卡人。这里描述的实施例可以向发行方提供管理的、实时的花费洞察，以帮助他们在卡使用时用最佳的GDV机会识别他们的投资组合中的卡。例如，实施例可以帮助对于每个交易回答以下问题：

·“与该国其他类似卡(例如美国/消费者借记卡，英国/消费者信用卡)相比，此卡的支出多大？”

·“与同一发行方的其他卡相比，此卡执行当前交易类型的频率如何？”以及

·“与其自身的历史花费率相比，这张卡交易的频率是多少？”

图13是可根据一些实施例执行的细分方法1300。在S1310，支付系统授权平台的计算机处理器可以从收单方平台接收授权消息。在S1320，支付系统授权平台的计算机处理器可以确定授权请求满足预定条件。在S1330，响应于该确定，可以将关于授权消息的信息传送给分析规则引擎。

在S1340，支付系统授权平台的处理器可以从分析规则引擎接收信息，包括每个授权消息被分配到“细分维度类别”的指示。细分维度类别可以与例如高类别、中等类别、低类别和/或无类别相关联。此外，细分维度类别可以是与跨境交易、国内交易、零售购物者交易、国内自动取款机(“ATM”)交易、跨境ATM交易、旅行消费交易、个人识别码(“PIN”)终端处的签名交易、汽车加油机交易、在线交易、游戏交易和/或博彩交易相关的有卡交易和/或无卡交易。

根据一些实施例，来自分析规则引擎的信息还包括每个授权消息被分配到花费维度类别的指示。例如，花费维度类别可能与高类别、中等类别、低类别和/或无类别相关联。对于每个细分维度类别和花费维度类别，实施例可以计算：(i)账户百分比，(ii)总美元金额，(iii)拒绝率，以及(iv)欺诈率。

根据一些实施例，来自分析规则引擎的信息还包括每个授权消息被分配到趋势维度类别的指示。趋势类别可能与例如较高类别(增加)、恒定类别和/或较低类别(降低)相关联。

一些实施例可以提供整合的强大的欺诈分析能力与整合的决策管理平台，以提供集中于识别投资组合中最好的持卡人的实时和管理服务。例如，在每周和滚动的12个月期间内，系统可以总体地创建、维护和评估持卡人的花费行为，并且跨越多个目标花费细分。这种评估可能导致在每笔交易的授权中提供以下分析：“与同一国家的其他类似卡(例如美国/消费者借记卡，英国/消费者信用卡)相比，此卡的支出有多大？”。例如，整体卡花费金额的排名可以被分类为发行方国家和产品(例如，美国/信用卡，澳大利亚/借记卡)的高/中/低类别。这可能有助于不仅识别发行方中最佳的持卡人花费者，而且识别总体来说是最佳的花费者。

评估还可能导致以下分析：“与同一发行方的其他卡相比，此卡执行当前交易类型的频率如何？”。例如，卡花费交易排名可以在同一细分中所有发行方花费数额的合格细分中被分为高/中/低类别，如表I所示。

评估也可能导致以下分析：“此卡与其自身的历史花费率相比交易的频率如何？”。例如，平台可能会确定花费趋势指示符，以突出显示与特定卡相关的最近支出与历史花费模式相比是否趋向于更高、一致或更低。

尽管这里描述的一些实施例可以被实现为数据服务，但是请注意，授权策略可能由多个不同的分层决策点驱动，这可以帮助进一步增强提供洞察。例如，特定交易与最佳持卡人之一相关联的指示符，执行他或她经常进行的交易可以与表示欺诈概率低的交易等级欺诈评分一起提供。这可以帮助降低高消费持卡人在低价购买时他或她的卡被拒绝的可能性(例如，当持卡人在不同的城市或州内旅行并且出租车费交易被拒绝时)。类似地，实施例可以避免高花费持卡人针对他或她经常做的事情被拒绝。注意，实施例可以被实现以支持所有卡产品-消费者借记卡/信用卡、商业信用卡/借记卡、预付费卡等。

卡组合管理是一种不断平衡的行为，旨在提供最佳的消费者体验，同时试图阻止越来越复杂和有动机的欺诈者。诸如批准和欺诈率等关键指标对于围绕投资组合的健康的描述很重要，但他们并不总是讲述整个描述。

许多投资组合有大量的卡花费机会，这些机会主要集中在少数账户上。与投资组合中最接近的一批花费者相比，这些高花费者可能：

·交易频率高达两倍，

·每笔交易额外花费50-100％

·在所分析的时间段内，总账户花费水平高数倍，

·占总批准花费的多达30-40％，以及

·占受拒绝影响的账户和金额的多达50％。

这里描述的实施例可以通过在多个关键维度上提供实时“积极洞察”来增加决策管理过程的重要维度，这可以帮助将授权策略和离线投资组合分析努力集中在那些对当前或未来GDV对投资组合的影响最有意义的账户上。

发卡机构可能会发现，这种细分功能的创建和维护是资源密集型的，并且难以维护(如果全部可用的话)。这种服务的管理性质可以为发行方提供运营和投资组合管理的好处。例如，发行方可能会将注意力集中在将这些洞察力用于它们的授权和投资组合管理策略的整合和微调中，从而导致支付平台出现重要而“粘性”的合作机会。此外，实施例可以提供由于批准交易的增加而导致的增加的收入机会、更大的持卡人品牌忠诚度以及客户服务成本的降低。请注意，在3个月期间内GDV减少多达11％可以跟随由于与潜在欺诈相关而被不当地拒绝的卡。

这里描述的一些实施例可以被设计为跨越多个特定细分提供卡活动的分区视图以帮助量化机会。这可以提供经由用于每个服务细分的机会矩阵以被跟踪的机会评估能力。例如，图14示出了与一些实施例相关联的数个持卡人维度1400。特别地，细分维度可以包括高1412、中等1414、低1416和无1418类别。类似地，花费维度可以包括高1422，中等1424，低1426和无1428类别。更进一步，趋势维度1430可以指示活动是趋向于更高，恒定还是更低。这些信息可能提供实时和离线的机会，例如：高花费者可能在所有细分排名中都占优；高细分账户可能会在花费排名中上升；中等花费者可能会在花费或细分排名上走高，账户可能会因较高的花费活动而激励；以及/或者趋势较低的账户花费活动可能会保留下来。

这些关键性能指标(“KPI”)是可以被跟踪和监控以确保持续的服务性能的指标。例如，可以跟踪矩阵内的每个单元格，例如与以下数据点有关：

·账户的百分比，

·批准的总GDV的百分比，

·仅基于“05”(不批准交易)拒绝的总拒绝GDV的百分比，

·拒绝率，以及

·欺诈率。

图15示出了根据一些实施例的关于有卡借记卡交易的详细信息1500。该信息可以包括例如“机会矩阵”。如前所述，细分维度可以包括高1512、中等1514、低1516和无1518类别。同样，花费维度可能包括高1522、中等1454和低1526。这种方法可能提供一个“安全网”，以帮助集中于灾难性的欺诈监控和检测。此外，实施例可以提供集中于交易特定的欺诈监控和检测以及积极洞察的欺诈洞察(例如，可以作为欺诈洞察配置包的一部分或作为独立产品提供的数据驱动的洞察)。

图16是根据一些实施例的如何将信息作为新数据元素添加到授权消息中的示例1600。特别地，附加数据私用1610可以使用日期元素(“DE”)48 1620和安全服务1630来提供新的子元素56 1640。安全服务指示符1650和安全服务结果1652可以包括子字段1 1660和子字段2 1662，每个子字段包含3个字节1670,1672。AQD 1680可以提供花费维度洞察，诸如花费排名1682(从1到9，9是最低级别)，细分排名1684(从1到9，9为最低级别)和趋势指示符1686(其中1指示向上趋势，5指示稳定并且9指示向下趋势)。AQS 1690可以提供合格细分标识符1692。

因此，实施例可以构建实时数据聚焦产品，其在授权时提供有影响的洞察。而且，这些功能可以建成具有与全球客户接触的能力的规模。此外，实施例可以用作集中于欺诈检测的分层供应的一部分。此外，由于发明对当前欺诈损失的影响，可以促进费用管理和侧重于投资回报(“ROI”)。

实施例还可以提供实时信息分析平台，以帮助卡提供者将传统的面向参与导向的洞察驱动供应(忠诚点、益处、奖励等)操作化到授权过程中，持续地长期扩展这些基于分析的服务的价值。此外，实施例可以利用建立的规则引擎平台知识来捕捉来自多个内部和外部源(客户批处理文件，数据仓库等)的数据并根据客户定义的业务规则实时分析它。此外，客户可以将他们的批准、防欺诈、市场营销、保留等策略整合到实时授权流程中，根据他们为其业务定义的定制规则采取更明智的行动。

虽然已经结合具体的示例性实施例描述了本发明，但应该理解的是，在不脱离如所附权利要求中所阐述的本发明的精神和范围的情况下，可以对所公开的实施例进行本领域技术人员显而易见的各种改变、替换和变更。

Claims (24)

1.一种方法，包括：

在支付系统授权平台的计算机处理器处接收来自收单方平台的授权消息；

由所述支付系统授权平台的所述计算机处理器确定授权请求满足预定条件；

响应于所述确定，将关于所述授权消息的信息传送到分析规则引擎；以及

在所述支付系统授权平台的所述处理器处接收来自所述分析规则引擎的信息，所述信息包括每个授权消息被分配到细分维度类别的指示。

2.如权利要求1所述的方法，其中，所述细分维度类别与以下中的至少一个相关联：(i)高类别，(ii)中等类别，(iii)低类别，以及(iv)无类别。

3.如权利要求2所述的方法，其中，所述细分维度类别与以下中至少一个相关联：(i)有卡交易，以及(ii)无卡交易。

4.如权利要求3所述的方法，其中，所述细分维度类别与以下各项中的至少一个相关联：(i)跨境交易，(ii)国内交易，(iii)零售购物者交易，(iv)国内自动柜员机交易，(v)跨境自动柜员机交易，(vi)旅行花费交易，(vii)个人识别号码终端处的签名交易，(viii)汽车加油机交易，(ix)在线交易，(x)游戏交易，以及(xi)博彩交易。

5.如权利要求1所述的方法，其中，来自所述分析规则引擎的信息还包括每个授权消息被分配到花费维度类别的指示。

6.如权利要求5所述的方法，其中，所述花费维度类别与以下中的至少一个相关联：(i)高类别，(ii)中等类别，(iii)低类别，以及(iv)无类别。

7.如权利要求6所述的方法，还包括：

对于每个细分维度类别和花费维度类别，计算：(i)账户百分比，(ii)总美元金额，(iii)拒绝率，以及(iv)欺诈率。

8.如权利要求1所述的方法，其中，来自所述分析规则引擎的所述信息进一步包括每个授权消息被分配到趋势维度类别的指示。

9.如权利要求8所述的方法，其中，所述细分维度类别与以下中的至少一个相关联：(i)较高类别，(ii)恒定类别，以及(iii)较低类别。

10.如权利要求1所述的方法，其中所述传送包括将所述授权消息转发到所述分析规则引擎。

11.如权利要求10所述的方法，其中，从所述分析规则引擎接收的所述信息是补充授权消息。

12.如权利要求11所述的方法，其中，所述补充授权消息包括以下中的至少一个：(i)风险标志，(ii)风险评分，(iii)持卡人类别，(iv)终端类别，(v)增强型专家监控服务评分数据，(vi)花费排名字段，(vii)细分排名字段，(viii)趋势指示符，以及(ix)合格细分标识符。

13.如权利要求11所述的方法，还包括：

将所述补充授权消息转发到以下中的至少一个：(i)收单方平台，以及(ii)发行方平台。

14.如权利要求1所述的方法，其中，从所述分析规则引擎接收的信息是授权批准决定。

15.如权利要求14所述的方法，还包括：

响应于所述授权批准决定，向发行方平台传送(i)授权消息和(ii)从所述分析规则引擎接收的补充授权消息中的至少一个。

16.一种支付系统授权平台，包括：

从收单方平台接收授权消息的第一输入；

确定组件，用于确定授权请求满足预定条件；

输出，其响应于所述确定以将关于授权消息的信息传送到分析规则引擎；以及

第二输入，用于接收来自所述分析规则引擎的信息，所述信息包括每个授权消息被分配到细分维度类别的指示。

17.一种其中存储有指令的非暂时性计算机可读介质，所述指令在执行时使计算机执行方法，所述方法包括：

在支付系统授权平台处接收来自收单方平台的授权消息；

由所述支付系统授权平台确定所述授权请求满足预定条件；

响应于所述确定，将关于所述授权消息的信息传送到分析规则引擎；以及

在所述支付系统授权平台处接收来自所述分析规则引擎的信息，所述信息包括每个授权消息被分配到细分维度类别的指示。

18.一种方法，包括：

在分析规则引擎处接收来自支付系统授权平台的关于授权消息的信息；

由所述分析规则引擎根据至少一个规则分析关于所述授权消息的信息，以生成结果；

自动分配所述授权消息到细分维度类别；以及

响应于所述结果，向所述支付系统授权平台传送关于所述授权消息的信息，所述信息包括所述授权消息被分配到细分维度类别的指示。

19.如权利要求18所述的方法，其中：

所述细分维度类别与以下中的至少一个相关联：(i)高类别，(ii)中等类别，(iii)低类别，以及(iv)无类别，

所述细分维度类别进一步与以下中的至少一个相关联：(i)有卡交易，以及(ii)无卡交易，并且

所述细分维度类别进一步与以下中的至少一个相关联：(i)跨境交易，(ii)国内交易，(iii)零售购物者交易，(iv)国内自动柜员机交易，(v)跨境自动柜员机交易，(vi)旅行花费交易，(vii)个人识别号码终端处的签名交易，(viii)汽车加油机交易，(ix)在线交易，(x)游戏交易，以及(xi)博彩交易。

20.如权利要求19所述的方法，还包括：

自动分配所述授权消息到与以下中的至少一个相关联的花费维度类别：(i)高类别，(ii)中等类别，(iii)低类别，以及(iv)无类别。

21.如权利要求20所述的方法，还包括：

自动分配所述授权消息到与以下中的至少一个相关联的趋势维度类别：(i)较高类别，(ii)恒定类别，以及(iii)较低类别。

22.如权利要求21所述的方法，还包括：

对于每个细分维度类别和花费维度类别，自动计算：(i)账户百分比，(ii)总美元金额，(iii)拒绝率，以及(iv)欺诈率。

23.一种分析规则引擎，包括：

输入，其用于从支付系统授权平台接收关于授权消息的信息；

分析器，其用于：(i)根据至少一个规则分析关于所述授权消息的信息以生成结果，以及(ii)自动分配所述授权消息到细分维度类别；以及

输出，其响应于所述结果将关于所述授权消息的信息传送到所述支付系统授权平台，所述信息包括所述授权消息被分配到所述细分维度类别的指示。

24.一种其中存储有指令的非暂时性计算机可读介质，所述指令在执行时使计算机执行方法，所述方法包括：

在分析规则引擎处接收来自支付系统授权平台的关于授权消息的信息；

由所述分析规则引擎根据至少一个规则分析关于所述授权消息的信息，以生成结果；

由所述分析规则引擎自动分配所述授权消息到细分维度类别；以及

响应于所述结果，将关于所述授权消息的信息传送到所述支付系统授权平台，所述信息包括所述细分维度类别的指示。