用于访问基于订户的源的系统和方法与流程
本申请要求于2016年12月21日提交的美国专利申请no.15/386,426的权益和优先权。上述申请的全部公开内容通过引用并入本文。
本公开的领域一般而言涉及访问基于订户的数据源，并且更具体而言，涉及用于基于某些订阅规则来管理对存储在数据源内的数据的访问的基于网络的系统和方法。
背景技术：
电子数据通常存储在数据库内。数据库可以在计算机网络内的多个位置，并且由不同的人使用与数据库通信耦合的计算设备来访问。例如，数据可以存储在网络内的第一位置处的数据库中，同时相同的数据也存储在第二位置处的另一个数据库中。在一些情况下，当在第二位置处更新相同的数据时，存储在第一位置中的数据可能变得过期或陈旧。在这些情况中的至少一些情况下，利用存储在第二位置处的更新后的数据来更新存储在第一位置处的数据是重要的。但是，存在与更新这种过期或陈旧数据相关联的许多挑战，尤其是当这种数据可以存储在多个位置并且必须保持安全时，使得仅被批准访问数据的那些方才实际上能够访问数据。
支付卡行业是一个示例，其中存储在某些数据库内的数据必须保持安全。例如，至少一些支付交易是在账户持有者进行购买但是当进行该购买时不存在实际支付卡以供商家检查被执行的。这些交易被称为“卡不存在”(cnp)交易。在这种交易中，关于支付卡的信息，包括账号以及在许多情况下支付卡的到期日期，连同交易是cnp交易的指示符一起被从商家传送。“账户存档”交易是这样一种类型的交易，其中商家将关于账户持有者的支付卡的信息存储在数据库中，然后当处理交易时检索所存储的支付卡信息并将其包括在提交的授权请求消息中。一种具体类型的账户存档交易是“经常性(recurring)支付交易”，商家经常性地为特定账户持有者发起该交易。在这种经常性支付交易中，商家将关于账户持有者的支付卡的信息存储在数据库中，然后检索所存储的支付卡信息并将其包括在每个经常性授权请求消息中。
经常性卡存档支付交易的示例是健身房会员资格。账户持有者可以选择向健身房注册支付卡，诸如信用卡、借记卡或预付卡，而不是向健身房邮寄月度支票用于会员资格。向健身房注册支付卡使得健身房能够在每个月的特定日期为每月到期自动从支付卡收费。在一些此类系统中，商家存储账号、到期日期和/或与支付卡和/或账户持有者相关联的其它信息。考虑到这种支付模式对于商家和账户持有者两者的便利性，它可以用于其中账户持有者是俱乐部的成员或者产品或服务的订户的许多其它场景。因而，多个商家可能已经存储了同一账户持有者的支付卡信息。同样，任何给定的商家可能已存储多个账户持有者的支付卡信息。
除了经常性支付交易之外，商家还可以维护账户存档信息以促进回头客的支付卡交易。例如，在线商家可以允许购物者创建在线账户并存储与一种或多种支付方法对应的账户数据。当购物者准备结账并完成购买时，购物者可以简单地选择所存储的支付方法之一，这与必须重新输入他们的支付卡信息相反。
但是，存储支付卡信息的缺点是关于支付卡的信息可能会有变化。例如，账户持有者的支付卡可能到期，导致新的支付卡以新的到期日期被发出，但卡号保持不变。在此类情况下，支付卡的发行方拒绝包含过期的到期日期的授权请求消息。因此，在商家获得支付卡的更新后的到期日期之前，最初提交了授权请求的商家被阻止成功获得支付。由于商家和账户持有者广泛采用账户存档支付模式，因此，账户持有者可理解地难以用新的支付卡到期日更新每个商家。同样，它降低了账户存档支付模式的好处，要求商家在提交每个支付授权请求之前向每个账户持有者查询更新后的支付卡到期日期。
鉴于前述内容，至少一些已知系统可以向商家提供更新后的账户持有者支付卡信息。但是，为了在此类系统中获得更新后的账户数据，商家必须向商家的收单银行提交与一个或多个支付卡账户对应的账户查询，商家的收单银行然后将该查询转发到中央账户数据系统。响应于该查询，账户数据系统检索从发行方接收的对应的账户数据，并将检索到的账户数据传送到收单银行。然后，收单银行可以将检索到的账户数据转发给商家，然后商家可以更新其账户存档支付卡信息的数据库。
这些已知系统在几个方面受到限制。例如，这些已知系统不保证商家有权访问更新后的信息。在这些已知系统中，只要收单银行向中央系统注册商家，商家就可以提交账户查询并接收更新后的账户信息，甚至是尚未由账户持有者向商家注册和授权的账户信息。这个限制会导致欺诈问题。类似地，这些已知系统不会监督所提交的商家账户查询可能存在欺诈和/或故意欺诈的已标记商家。而且，这些已知系统可能不会及时地将更新后的信息传送给商家。在至少一些情况下，可能需要几天时间才能将更新后的信息传送给商家。鉴于前述内容，需要增强的账户数据系统，其中增强的系统和方法解决这些问题和其它问题。
技术实现要素：
在一个方面，提供了一种用于管理对存储在数据源内的数据的访问的计算机实现的方法。使用与一个或多个存储器设备通信的订户账户存档计费更新器(abu)计算设备来实现该方法。该方法包括接收包括更新后的账户标识符的更新后的账户数据，以及用于核实商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据的至少一个订阅规则。该方法还包括将更新后的账户数据存储在第一数据存储装置中，并且将所述至少一个订阅规则存储在第二数据存储装置中。该方法还包括从发出请求的商家接收包括至少一个候选账户标识符和识别发出请求的商家的一个商家标识符的注册请求，以及在将候选账户标识符与更新后的账户标识符匹配之后从第二数据存储装置中检索所述至少一个订阅规则。该方法还包括将所述至少一个订阅规则应用于发出请求的商家，确定发出请求的商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据，以及向发出请求的商家传送包括更新后的账户数据的更新响应。
在第二方面，提供了一种订户abu计算设备。订户abu计算设备包括与一个或多个存储器设备通信的一个或多个处理器并且被配置为接收包括更新后的账户标识符的更新后的账户数据，以及用于核实商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据的至少一个订阅规则。订户abu计算设备还被配置为将更新后的账户数据存储在第一数据存储装置中，并且将所述至少一个订阅规则存储在第二数据存储装置中。订户abu计算设备还被配置为从发出请求的商家接收包括至少一个候选账户标识符和识别发出请求的商家的一个商家标识符的注册请求，以及在将候选账户标识符与更新后的账户标识符匹配之后从第二数据存储装置中检索所述至少一个订阅规则。订户abu计算设备还被配置为将至少一个订阅规则应用于发出请求的商家，确定发出请求的商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据，以及向发出请求的商家传送包括更新后的账户数据的更新响应。
在又一方面，提供了一种其上实施有计算机可执行指令的非瞬态计算机可读介质。当计算机可执行指令由具有与一个或多个存储器设备通信的一个或多个处理器的订户abu计算设备执行时，使订户abu计算设备接收包括更新后的账户标识符的更新后的账户数据，以及用于核实商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据的至少一个订阅规则。计算机可执行指令还使订户abu计算设备将更新后的账户数据存储在第一数据存储装置中，并且将所述至少一个订阅规则存储在第二数据存储装置中。计算机可执行指令还使订户abu计算设备从发出请求的商家接收包括至少一个候选账户标识符和识别发出请求的商家的一个商家标识符的注册请求，以及在将候选账户标识符与更新后的账户标识符匹配之后从第二数据存储装置中检索所述至少一个订阅规则。计算机可执行指令使订户abu计算设备将所述至少一个订阅规则应用于发出请求的商家，确定发出请求的商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据，以及向发出请求的商家传送包括更新后的账户数据的更新响应。
附图说明
图1-图4示出了本文描述的方法和系统的示例实施例。
图1是图示具有订户账户存档计费更新器(abu)计算设备的支付平台的示意图。
图2是图示包括与图1的支付处理系统通信的图1中所示的订户abu计算设备的订户abu系统的图。
图3是图示图1和图2中所示的订户abu计算设备的示例的图。
图4是图示根据本公开一个示例实施例的使用图1和图2中所示的订户abu计算设备来核实账户存档信息的示例方法的流程图。
具体实施方式
本文描述的系统和方法涉及用于管理和核实订户(诸如注册商家)的订户账户存档计费更新器(abu)系统。订户abu系统被配置为存储账户数据、订阅数据和核实商家被授权接收与账户持有者相关联的更新后的账户数据并且可以被注册以接收这样的数据的至少一个订阅规则。订户abu系统包括被配置为执行本文详述的步骤的订户abu计算设备。
一般而言，订户abu计算设备从一个或多个发行方接收账户数据，并将账户数据维护在账户信息数据源中。然后，订户abu计算设备可以从一个或多个商家和/或收单方银行接收订阅数据。订户abu计算设备还可以从发行方接收订阅规则。订户abu计算设备可以将账户数据、订阅数据和订阅规则存储在单个信息数据源中或分开的信息数据源中。订户abu计算设备可以从商家接收对被注册以接收一个或多个账户的更新后的账户数据的请求。订户abu计算设备通过使用一个或多个订阅规则来核实商家可以被注册以接收更新后的账户数据。一经核实，订户abu计算设备就可以允许商家被注册，或者订户abu计算设备可以拒绝商家注册并返回包含拒绝的响应。在整个过程中，订户abu计算设备可以记录订阅数据。此外，订户abu计算设备可以接收订阅规则以及针对账户、注册商家和请求注册的商家的欺诈信息数据。
订户abu计算设备还可以认证注册商家是一个或多个账户的更新后的账户数据的有效接收者。订户abu计算设备通过使用一个或多个订阅规则来验证该注册商家被授权接收更新后的账户数据。一经验证，订户abu计算设备就可以将更新后的账户数据传送到注册商家，或者订户abu计算设备可以拒绝更新后的账户数据的传送，并且还可以中断商家登记以接收进一步更新后的账户数据。
在某些实施例中，订户abu计算设备可以基于所应用的订阅规则来生成和传送报告。在其它实施例中，订户abu计算设备可以自动生成并传送关于预定事件的报告(例如，从发行方接收更新后的账户数据或预定时间表，诸如每日、每两周等)。在替代实施例中，订户abu计算设备可以根据请求生成和传送报告。在某些实施例中，此类报告可以包括与账户持有者对应的更新后的账户信息。
为了促进商家注册的监督，订户abu计算设备可以从一个或多个发行方接收订阅规则。照此，发行方可以向订户abu计算设备指定允许的注册商家行为和/或提供用于允许注册或保留注册的某些预定条件。在其它实施例中，如果发生预定活动或者注册商家请求停止登记，那么订户abu计算设备可以中断订户abu系统内的注册商家登记。例如，如果在六(6)个月内没有系统活动，那么订户abu计算设备可以自动中断商家登记。
在一些实施例中，发行方可以具有针对具体账户范围的不同订阅规则。例如，与平均净值账户相比，不同的订阅规则可以应用于高净值账户，其可以由发行方银行标识号(bin)识别。bin可以随账户数据由发行方提供并由订户abu计算设备接收。订户abu计算设备可以通过使用基于所提供的bin从订阅规则集合中选择的订阅规则来核实请求注册以接收更新后的数据的商家。例如，基于bin，至少一个账户范围可以通过确定商家是否具有与账户标识符对应的先前批准的交易来核实请求注册的商家。如果存在来自商家的与账户标识符对应的先前批准的交易，那么核实商家并且批准注册。在另一个示例中，订户abu计算设备可以通过确定商家具有作为先前经常性卡不存在支付交易的一部分而提交的先前批准的授权消息来自动注册(例如，自动订阅)商家。换句话说，如果发行方对账户批准了来自商家的经常性支付授权请求，那么订户abu计算设备将假设商家现在被注册到所述账户。在又一个示例中，订户abu计算设备可以通过确定注册商家对账户数据的更新请求或账户数据的自动更新是否是自从与账户标识符对应的上次批准的交易以来超出预定时间段之后被接收到了，来核实注册商家被授权接收更新后的账户数据。如果账户数据的更新请求或自动更新请求超过预定时间段，那么商家不被核实、更新请求被拒绝，并且注册的登记可以被中断。
订户abu计算设备周期性地从一个或多个发行方接收账户数据并维护账户数据。如果注册商家或发行方希望核实或更新其账户数据，那么注册商家或发行方可以向订户abu计算设备提交更新请求。在某些实施例中，来自一个或多个注册商家或发行方的多个更新请求可以被收集并作为批被提交给订户abu计算设备。例如，收单方银行可以从一个或多个商家收集多个更新请求，并将更新请求作为批提交给订户abu计算设备。
响应于接收到更新请求，订户abu计算设备可以查找或以其它方式从账户信息数据源检索账户数据。在某些实施例中，可以基于账户标识符存储被存储在账户信息数据源中的账户数据，并且更新请求可以包括一个或多个注册商家标识符、以及注册商家正请求更新后的账户数据的一个或多个账户标识符。为了促进当前未调节的更新请求的监督定，订户abu计算设备然后可以通过应用至少一个订阅规则并确定注册商家被授权接收更新后的账户数据来核实更新请求。基于核实，订户abu计算设备可以允许更新请求并返回包含更新后的账户数据的更新响应，该更新响应被传送到授权的注册商家。或者，订户abu计算设备可以拒绝更新请求并生成声明更新请求被拒绝的拒绝响应。当更新请求被拒绝时，拒绝响应还可以提供关于该拒绝为什么发生的(一个或多个)原因。在任一情况下，所生成的响应都可以被传送到发行方和/或注册商家。
在另一个实施例中，如果注册商家或发行方希望核实或更新其账户数据，那么订户abu计算设备可以根据预定事件自动向注册商家或发行方传送账户更新。在某些实施例中，可以将多个账户更新传送给一个或多个注册商家或发行方。例如，注册商家可以每天接收多个账户更新。
在自动传送账户更新之前，订户abu计算设备可以使用一个或多个订阅规则来确定预定事件并核实接收账户更新的注册商家被授权接收这样的更新。
用于订户abu计算设备的订阅规则还可以从接受自欺诈监控源的商家欺诈数据导出，欺诈监控源诸如
订户abu计算设备的订阅规则还可以从接收自欺诈监控源的账户欺诈数据导出，类似于上面列出的欺诈监控源。订户abu计算设备从欺诈监控源接收账户欺诈数据，该账户欺诈数据可以包括退款数据、交易数据、平均交易数据和黑名单数据。在某些实施例中，订户abu计算设备使用从账户欺诈数据导出的订阅规则来核实请求注册的商家。例如，订阅规则可以包括确定账户标识符是否具有预定欺诈指示符。如果账户标识符具有预定欺诈指示符，那么商家未通过核实并且注册被拒绝。在另一个示例中，订户abu计算设备确定账户标识符是否在账户黑名单上。如果账户标识符在账户黑名单上，那么商家未通过核实并且注册被拒绝。在另一个示例中，订阅规则确定账户标识符的日期是否超过预定日期限制，使得旧账户标识符不能由请求注册的商家更新。例如，超过五十(50)个月的账户标识符可能不会由请求注册的商家更新，并且在这些情况下，商家被确定为未通过核实并且注册被拒绝。
在其它实施例中，订户abu计算设备的订阅规则包括接收从与请求者和发行方之间的支付卡交易对应的授权请求消息接收的商家反馈数据。对于支付卡交易，通常包括建议代码，其将来自发行方的指令提供给商家。例如，发行方可以请求商家停止维护账户持有者的账户存档信息。如果是这样，那么订户abu计算设备可以存储这个信息并使用它来核实请求注册的商家。例如，核实可以包括确定从存储的建议代码导出的反馈动作计数是否超过预定反馈动作计数限制。如果反馈动作计数超过预定反馈动作计数限制，那么商家未通过核实并且注册被拒绝。在另一个示例中，订户abu计算设备可以确定从存储的建议代码导出的反馈动作百分比是否超过预定核实反馈动作百分比限制。如果商家的反馈动作百分比超过预定反馈行动百分比限制，那么商家未通过核实并且注册被拒绝。
在其它实施例中，发行方向接收和存储商家黑名单的订户abu计算设备提供商家黑名单。订阅规则还可以包括确定请求注册的商家是否在商家黑名单上，并且如果是，那么商家被确定为未通过核实并且注册被拒绝。
为了减少生成和传送更新响应的时间，订户abu计算设备允许基于订户abu计算设备接收并存储的商家数据进行商家注册。一经注册，商家就被批准接收与账户持有者对应的更新后的账户数据。在某些实施例中，一经从商家接收到更新请求，就传送更新后的账户数据。在其它实施例中，订户abu计算设备被配置为基于预定事件自动传送更新后的账户数据。在其它实施例中，在传送更新后的账户数据之前，订户abu计算设备认证注册商家是更新后的账户数据的有效接收者。
本文描述的方法和系统可以使用计算机编程或工程技术来实现，包括计算机软件、固件、硬件或其任何组合或子集，其中通过执行以下当中的至少一个来实现技术效果：(a)接收更新后的账户数据，包括更新后的账户标识符，以及用于核实商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据的至少一个订阅规则，(b)将更新后的账户数据存储在第一数据存储装置中，(c)将至少一个订阅规则存储在第二数据存储装置中，(d)从发出请求的商家接收包括至少一个候选账户标识符和识别发出请求的商家的一个商家标识符的注册请求，(e)在将候选账户标识符与更新后的账户标识符匹配之后，从第二数据存储装置中检索至少一个订阅规则，(f)将至少一个订阅规则应用于发出请求的商家，(g)确定发出请求的商家被授权接收与更新后的账户标识符相关联的账户的更新后的账户数据，以及(h)向发出请求的商家传送包括更新后的账户数据的更新响应。
本文描述的系统和方法提供了以下技术优点：(a)降低账户存档支付卡交易将是欺诈的可能性；(b)识别并阻塞向可能具有欺诈性的商家传输更新后的账户数据，类似地减少最新的账户信息的传播；(c)控制并监督对abu系统的访问；(d)增加发行方对abu系统的参与；以及(e)减少最新账户信息的传输时间。
支付卡交易网络的示例
图1是图示包括订户abu计算设备34的支付平台20的示意图。本文描述的实施例可以涉及交易卡系统，诸如使用
在典型的交易卡系统中，被称为“发行方”或“发行银行”的金融机构向账户持有者22发行交易卡，诸如信用卡、借记卡等，账户持有者22在本文也称为消费者或账户持有者，其使用交易卡为从商家24的购买进行投标支付。为了接受利用交易卡的支付，商家24通常与作为金融支付系统一部分的金融机构建立账户。这种金融机构被称为“商家银行”、“收单银行”或“收单方”。在一个实施例中，账户持有者22在交易处理设备40(例如，销售点设备)处使用交易卡对购买进行投标支付，然后商家24从商家银行26对购买的金额请求授权。该请求通常通过使用销售点终端来执行，该销售点终端从账户持有者22的交易卡上包括的磁条、芯片、浮雕字符等读取账户信息，并与商家银行26的交易处理计算机电子地通信。在与在线商家的交易的上下文中，账户持有者22可以通过网站提供他们的账户信息，诸如他们的账号、卡核实号、到期日期等。可替代地，商家银行26可以授权第三方代表其执行交易处理。在这种情况下，销售点终端可以被配置为与第三方通信。这样的第三方可以被称为“商家处理器”、“收单处理器”或“第三方处理器”。
使用交换网络28，商家银行26的计算机可以与发行银行30的计算机通信，以确定账户持有者22的账户32是否信誉良好以及该购买是否被与账户持有者22对应的账户32的可用信用额度涵盖。基于这些确定，对授权的请求可以被拒绝或接受。如果请求被接受，那么可以向商家24发出授权码。
诸如商家24之类的商家可以将与一个或多个账户持有者对应的支付卡账户信息存储在商家账户信息数据源36中。在某些实施例中，商家账户信息数据源36可以是商家24可访问的本地或远程数据库。在交易期间，商家24可以从商家账户信息数据源36检索账户信息，而不是从账户持有者22获取信息，诸如通过让账户持有者22通过刷支付卡或手动输入支付卡信息来提供他或她的支付卡账户信息。所谓的“账户存档”交易可以包括诸如订阅费、会员费、电子账单等经常性支付。账户存档交易还可以包括当账户持有者22是商家24的回头客时的实例。因而，账户存档交易一般要求账户持有者最初提供他或她的支付卡账户信息，然后授权或登记账户存档服务。一旦登记，由账户持有者22进行的后续支付就可以通过或者自动计费账户持有者22或者通过从商家账户信息数据源36自动检索与账户持有者22对应的账户信息来简化。
例如，商家24可以是互联网服务提供商(isp)，其向账户持有者22提供互联网连接作为每月服务费的互换。账户持有者22可以向isp登记自动账单支付服务以支付每月服务收费。isp可以将账户持有者22的账户数据存储在商家账户信息数据源36中。当每月服务收费到期时，isp可以从商家账户信息数据源36检索账户数据，并且可以基于检索到的账户数据向发行方30提交交易。作为另一个示例，商家24可以是账户持有者22从其进行定期购买的在线商家。账户持有者22可以向在线商家创建用户简档并提供他或她的支付卡账户信息，然后在线商家可以将其存储在商家账户信息数据源36中。当账户持有者22稍后登录在线商家的网站并选择购买的商品或服务时，在线商家可以检索账户持有者22的支付卡账户数据并通过自动填充购买表格或利用检索到的账户数据执行类似步骤来促进账户持有者22的购买。
虽然账户存档交易可以为商家和账户持有者两者提供改进的效率，但是支付卡账户信息可能会有变化。例如，支付卡的到期日期可能失效，或者发行银行可以重新发行具有不同主账号(pan)的支付卡。如果商家24试图在这种变化之后向发行方30提交交易并使用过期的账户信息，那么发行方30可能拒绝该交易。因而，可以实现订户abu计算设备34以确保由商家24维护的账户数据是当前的。具体而言，订户abu计算设备34可以周期性地从一个或多个发行方(诸如发行方30)接收支付卡账户信息更新，并将接收到的支付卡账户信息存储在订户abu账户信息数据源38中。订户abu计算设备34然后可以使存储的支付卡账户信息可用于商家24，使得商家24可以更新商家账户信息数据源36。
在某些实施例中，订户abu账户信息数据源38可以存储一个或多个账户持有者(诸如账户持有者22)的支付卡账户信息。对于账户持有者的每个支付卡账户，订户abu账户信息数据源38可以包括当前账户信息，包括但不限于当前账户标识符和当前到期日期。订户abu账户信息数据源38还可以存储链接到对应的当前账户信息的过期的账户信息。因此，如果使用过期的账户信息向订户abu计算设备34提交对当前账户信息的更新请求，那么订户abu计算设备34可以基于提交的过期的账户信息在订户abu账户信息数据源38中定位对应的当前账户信息。
为了获得当前账户信息，商家24可以向订户abu计算设备34提交注册请求。注册请求可以包括一个或多个商家标识符，以及商家24正请求(一个或多个)当前账户持有者支付卡账户信息的一个或多个账户标识符。响应于注册请求，订户abu计算设备34可以核实商家24被授权接收更新后的数据。一经核实，abu计算设备24可以批准商家24注册请求，从而向商家24返回注册接受响应。
响应于注册请求，订户abu计算设备34可以使用商家标识符并且核实商家24被授权接收更新后的账户数据来访问存储在订户abu账户信息数据源38中的支付卡账户数据。基于核实，订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24返回注册接受响应。或者，订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24返回拒绝响应。注册接受和/或拒绝响应也可以由订户abu计算设备34发送给发行方30。
附加地或可替代地，发行方30可以设置由订户abu计算设备34使用的订阅规则。发行方30可以向发行方规则信息数据源44发送并提供订阅规则。订户abu计算设备34然后可以使用从发行方30接收并存储在发行方规则信息数据源44中的订阅规则来核实商家24被授权接收更新后的账户数据。照此，发行方30可以具有针对具体账户范围的不同订阅规则。例如，发行方30可以随支付卡账户数据提供bin，并使用bin来识别高净值账户和平均净值账户。订户abu计算设备34可以基于bin从订阅规则集合中选择用于核实商家24被授权接收更新后的账户数据的订阅规则。例如，发行方30可以为bin识别账户持有者22的更高净值账户提供更严格的规则集合，因为他们可以是欺诈活动的更大目标和/或具有更高的取款账户限制。
订户abu计算设备34可以通过应用从存储在欺诈信息数据源42中的包括账户活动数据、账户欺诈数据、商家活动数据、商家欺诈数据和商家反馈数据的一个或多个数据集合导出的至少一个订阅规则，来核实商家24被授权接收更新后的账户数据。欺诈信息数据源42一般存储关于账户活动、商家活动和欺诈活动中的至少一个的信息。可以从一个或多个欺诈监控源接收欺诈信息，欺诈监控源诸如mastercard有效避免欺诈系统(safe)、mastercard专家监控系统(ems)或任何其它欺诈监控源。
在某些实施例中，订户abu计算设备34可以通过使用从与账户持有者22的支付卡对应的并存储在欺诈信息数据源42中的账户数据导出的订阅规则来核实商家24被授权接收更新后的账户数据。例如，订户abu计算设备34可以通过确定账户标识符是否具有从欺诈信息数据源42中存储的账户欺诈数据导出的预定欺诈指示符来核实商家24被授权接收更新后的账户数据。欺诈指示符可以包括以下当中的一个或多个：确定商家24的当前支付卡交易是否超过账户持有者22对该交易类型的先前花费历史，和确定账户退款历史是否超过账户退款限制。如果存在用于账户持有者22的支付卡的预定欺诈指示符，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果用于账户持有者22的支付卡的预定欺诈指示符不存在，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。
在另一个示例中，订户abu计算设备34可以通过确定账户标识符是否在存储在欺诈信息数据源42中的账户黑名单上来核实商家24被授权接收更新后的账户数据。如果账户标识符在账户黑名单上，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果账户标识符不在账户黑名单上，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。在另一个示例中，订户abu计算设备34可以通过确定账户标识符的日期是否超过预定日期限制来核实商家24被授权接收更新后的账户数据。例如，如果由商家24提供的账户标识符大于预定日期限制，例如超过五十(50)个月，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果商家24提供的账户标识符小于预定日期限制，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。
在某些实施例中，订户abu计算设备34可以通过使用从存储在欺诈信息数据源42中的商家活动数据导出的订阅规则来核实商家24被授权接收更新后的账户数据。例如，订户abu计算设备34可以通过确定商家24是否具有存储在欺诈信息数据源42中的与账户持有者22的支付卡账户数据对应的先前批准的交易，来核实商家24被授权接收更新后的账户数据。如果在商家24和账户持有者22之间不存在先前批准的支付卡交易，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果在商家24和账户持有者22之间存在先前批准的支付卡交易，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。
在其它实施例中，订户abu计算设备34可以通过使用从存储在欺诈信息数据源42中的商家欺诈数据导出的订阅规则来核实商家24被授权接收更新后的账户数据。例如，订户abu计算设备34可以通过确定从存储在欺诈信息数据源42中的商家欺诈数据导出的欺诈退款计数是否超过预定欺诈退款计数限制，来核实商家24被授权接收更新后的数据。如果超过商家24的预定欺诈退款计数限制，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果未超过商家24的预定欺诈退款计数限制，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。
在另一个示例中，订户abu计算设备34可以通过确定从存储在欺诈信息数据源42中的商家欺诈数据导出的欺诈退款百分比是否超过预定欺诈退款百分比限制来核实商家24被授权接收更新后的账户数据。如果超过商家24的预定欺诈退款百分比限制，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果未超过商家24的预定欺诈退款百分比限制，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。在另一个示例中，订户abu计算设备可以通过确定商家24是否是从存储在欺诈信息数据源42中的商家欺诈数据导出的公共欺诈点来核实商家24被授权接收更新后的账户数据。如果商家24被确定为公共欺诈点，那么订户abu计算设备34可以确定商家24未经核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果商家24未被确定为公共欺诈点，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24的注册请求，从而向商家24提供注册接受响应。
在其它实施例中，订户abu计算设备34可以使用从存储在欺诈信息数据源42中的商家黑名单导出的订阅规则来核实商家24的注册。例如，订户abu计算设备34可以通过确定商家24是否在商家黑名单上来核实商家24的注册。如果商家24在商家黑名单上，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果商家24不在商家黑名单上，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。
订户abu计算设备34还可以被配置为通过使用从存储在欺诈信息数据源42中的商家反馈数据导出的订阅规则来核实商家24被授权接收更新后的账户数据。在发行方30和商家24之间的交易授权请求期间，发行方30可以在授权响应中包括向商家24提供指令的建议代码。例如，发行方30可以经由de48.84请求商家24采取关于支付卡账户数据的特定动作，诸如停止维护账户持有者22的账户存档信息。订户abu计算机设备34可以记录后续商家24活动，诸如在停止指令之后由商家24发送的对支付卡账户数据的注册请求的数量。照此，订户abu计算设备34可以查看商家反馈数据以确定商家24是否对反馈数据有动作，作为非欺诈性商家24的指示。
例如，订户abu计算设备34可以通过确定从存储在欺诈信息数据源42中的商家反馈数据导出的商家24的反馈动作计数是否超过预定的反馈动作计数限制来核实商家24被授权接收更新后的账户数据。如果超过商家24的预定反馈动作计数限制，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果未超过商家24的预定反馈动作计数限制，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。在另一个示例中，订户abu计算设备34可以通过确定从存储在欺诈信息数据源42中的商家反馈数据导出的商家24的反馈动作百分比是否超过预定反馈动作百分比限制来核实商家24被授权接收更新后的账户数据。如果超过商家24的预定反馈动作百分比限制，那么订户abu计算设备34可以确定商家24未通过核实并拒绝商家24注册请求，从而向商家24提供注册拒绝响应。但是，如果未超过商家24的预定反馈动作百分比限制，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据并批准商家24注册请求，从而向商家24提供注册接受响应。
一旦商家24注册请求被批准，订户abu计算设备34就可以将更新后的账户数据传送到商家24。订户abu计算设备34被配置为一经从商家24接收到更新请求和/或基于预定事件就将更新后的账户数据传送到商家24。例如，商家24可以向订户abu计算设备34提交更新请求，该更新请求可以包括一个或多个商家标识符，以及商家24正在请求(一个或多个)当前账户持有者支付卡账户信息的一个或多个账户标识符。响应于更新请求，订户abu计算设备36可以使用商家标识符访问存储在订户abu账户信息数据源38中的支付卡账户数据。随后，订户abu计算设备34可以从订户abu账户信息数据源38检索对应的当前账户信息，并将包含当前账户信息的响应消息传送给商家24。
在另一个示例中，订户abu计算设备34可以基于预定事件自动向商家24传送包含当前账户信息的响应消息。在某些实施例中，订户abu计算设备34可以一经从发行方30接收到更新后的账户数据就从订户abu账户信息数据源38检索与商家24相关联的当前账户信息。随后，订户abu计算设备34可以将包含当前账户信息的消息传送到商家24。在其它实施例中，订户abu计算设备34可以基于预定时间表从订户abu账户信息数据源38检索与商家24相关联的当前账户信息。例如，订户abu计算设备34可以被配置为每天向商家24传送包含当前账户信息的消息。
在一些实施例中，订户abu计算设备34可以累积更新后的账户数据并将一批更新后的账户数据提交给商家24。订户abu计算设备34可以使用可以由批文件端点和/或rest(表征性状态转移)端点组成的接口将该批更新后的账户数据传送到商家24。在某些实施例中，订户abu计算设备34可以基于预定事件自动地将该批更新后的账户数据传送给商家24。在其它实施例中，订户abu计算设备34可以一经从商家24接收到更新请求就将该批传送给商家24。
在替代实施例中，订户abu计算设备24可以认证商家24当前被授权接收更新后的账户数据。基于认证，订户abu计算设备34可以确定商家24当前被授权接收更新后的账户数据，并且可以生成包含当前支付卡账户数据的更新消息并将其传送给商家24。或者，订户abu计算设备34可以确定商家24不再被授权接收更新后的账户数据并且对商家24拒绝对更新后的账户数据的访问。订户abu计算设备34可以生成并传送表明对商家24拒绝对更新后的账户数据的访问的拒绝消息。更新消息和/或拒绝消息也可以由订户abu计算设备34发送到发行方30。
在另一个示例中，订户abu计算设备34可以通过确定来自商家24的更新请求是否是自从与账户持有者22的支付卡账户数据对应的上次批准的交易以来超出预定时间段之后被接收到了，来认证商家24被授权接收更新后的账户数据。如果商家24和账户持有者22之间的上次批准的交易自更新请求起超出预定时间段(例如二十四(24)个月)之后发生了，那么订户abu计算设备34可以确定商家24不再被授权接收更新后的账户数据并对商家24拒绝对更新后的账户数据的访问，从而返回表明对商家24拒绝对更新后的账户数据的访问的拒绝消息。但是，如果商家24和账户持有者22之间的上次批准的交易在预定时间段内发生，那么订户abu计算设备34可以确定商家24被授权接收更新后的账户数据，并且可以生成并向商家24传送包含当前支付卡账户数据的更新消息。
在某些实施例中，商家银行26可以累积更新请求并向订户abu计算设备34提交一批更新请求。在其它实施例中，对于该批中的每个更新请求，订户abu计算设备34可以向对应的商家传送响应。在其它实施例中，订户abu计算设备34可以将所有相关的当前账户信息累积到响应批中并将该响应批传送到商家银行26。然后，商家银行26可以根据需要将账户信息分发给先前提交了更新请求的每个商家。
订户账户计费更新器系统的示例
图2是图示根据本公开的示例实施例的订户账户存档计费更新器(abu)系统200的图，该系统包括消费者、商家、支付处理器、发行方和订户abu，其可以与订户abu计算设备34(在图1中示出)对应。
参考图2，订户abu系统200包括分别代表消费者220、商家230、支付处理器240、订户abu250和发行银行(“发行方”)260的计算设备，它们经由网络210彼此连接。网络210可以包括互联网、图1的交换网络28和/或一个或多个其它网络。例如，计算设备之间的连接可以包括无线网络、有线网络、电话网络、电缆网络、其组合等。无线网络的示例包括诸如wifi、wimax、wibro、局域网、个域网、城域网、蜂窝、蓝牙等网络。
消费者220可以是计算设备，例如，移动电话、智能电话、电话、计算机、膝上型计算机、台式计算机、平板电脑、mp3播放器、数字助理、服务器等。消费者220可以访问与商家230对应或由商家230托管的网站，和/或可以联系商家230的电话号码等。支付处理器240可以是诸如
商家230与计算设备对应，该计算设备被配置为接受和处理支付卡交易并维护包括与一个或多个持卡人相关联的支付卡账户数据的商家账户信息数据源(诸如数据库)。商家账户信息数据源可以结合到商家230中，或者可以以其它方式由商家230经由网络(诸如网络210)访问。商家账户信息数据源中维护的信息一般可以用于促进账户存档交易，诸如自动经常性支付。
订户abu250一般被配置为从发行方(诸如发行方260)接收账户数据以存储账户数据，并将账户数据提供给请求方(诸如商家230)。订户abu250还被配置为在将商家230注册为被授权接收更新后的账户数据之前并且在向商家230提供最新的账户数据之前管理和核实商家230被授权接收更新后的账户数据。
订户abu250可以包括或可以访问一个或多个数据源以促进管理订户abu系统200。例如，在图2的实施例中，订户abu250可以访问账户信息数据源252、欺诈信息数据源254和发行方规则信息数据源256。账户信息数据源252、欺诈信息数据源254和发行方规则信息数据源256中的每个可以是订户abu250的内部存储装置，或者可以远离订户abu250但可由订户abu250访问。账户信息数据源252、欺诈信息数据源254和发行方规则信息数据源256中的每个可以以一个或多个数据库、表或类似存储结构被存储在一个或多个数据存储设备上。
账户信息数据源252包含从一个或多个发行方(诸如发行方260)接收的账户数据。账户信息数据源252可以由订户abu250响应于通过网络210从发行方260接收账户数据而更新。在某些实施例中，账户数据可以由发行方260根据预定事件发送。在其它实施例中，订户abu计算设备250可以向发行方260进行呼叫，并且账户数据可以由发行方260响应于该呼叫而发送给订户abu250。在其它实施例中，发行方260可以一经改变与一个或多个账户持有者相关联的账户数据就自动向订户abu计算设备250发送账户数据。
订户abu250一般一经接收到注册请求就注册请求方，诸如商家230。可以直接从商家230通过网络210接收注册请求。注册请求一般包括一个或多个商家标识符，以及商家230正请求(一个或多个)当前账户持有者支付卡账户信息的一个或多个账户标识符。响应于注册请求，订户abu250可以核实商家230被授权接收更新后的数据。一经核实，abu250就可以批准商家230注册请求，从而向商家230返回注册接受响应。或者，订户abu250可以确定商家230未通过核实并拒绝商家230注册请求，从而向商家230返回拒绝响应。注册接受和/或拒绝响应也可以由订户abu250发送给发行方260。
结合注册请求，订户abu250可以在欺诈信息数据源254中创建条目或更新现有条目。欺诈信息数据源254一般存储与用于商家注册核实的订阅规则对应的账户活动数据、账户欺诈数据、商家活动数据和商家欺诈数据。在某些实施例中，订户abu250可以从一个或多个欺诈监控源接收欺诈数据，欺诈监控源诸如mastercard有效避免欺诈系统(safe)、mastercard专家监控系统(ems)或任何其它欺诈监控源，并在欺诈信息数据源254中存储数据。
订户abu250可以被配置为接收由发行方260通过网络210传送到发行方规则信息数据源256的订阅规则。例如，发行方260可以将订阅规则传送到发行方规则信息数据源256。作为响应，订户abu250接收订阅规则并应用订阅规则以核实商家230被授权接收更新后的账户数据。
订户abu250还可以被配置为在支付卡交易期间接收通过网络210传送的消息。例如，在某些实施例中，订户abu250可以接收授权消息，诸如从商家230发送到发行方260的授权请求消息和/或从发行方260发送到商家230的授权响应消息。当订户abu250处理交易消息时，订户abu250可以在欺诈信息数据源254中创建或更新条目。在某些实施例中，欺诈信息数据源254可以包括与账户存档交易对应的条目。例如，欺诈信息数据源254可以包括支付卡号、支付卡到期日期、商家标识符、金额、日期/时间、购买的商品/服务的描述等中的一个或多个。订户abu250还可以使用欺诈信息数据源254来跟踪反馈消息何时被包括在交易消息中。因而，欺诈信息数据源254可以包括建议代码字段，其指示一种或多种什么类型的反馈被从发行方260传送到商家230。
订户abu250还可以被配置为基于存储在订户abu账户信息数据源252、欺诈信息数据源254和发行方规则信息数据源256中的任何一个中的数据来生成和传送报告。报告可以为一方或多方(包括但不限于发行方、持卡人、商户、收单方和发行银行)被生成和提供，并且可以取决于为其生成报告的一方而包含不同的数据。例如，订户abu250可以为发行方生成报告，该报告列出对具体账户标识符具有注册拒绝的所有商家以及拒绝了该注册的订阅规则。在另一个示例中，订户abu250可以为商家生成指示商家是否在黑名单上的报告。
报告可以采取各种形式。例如，在某些实施例中，由订户abu250生成的报告可以被创建为用诸如可扩展标记语言(xml)的标记语言的文档。在其它实施例中，可以将报告生成为符合一个或多个标准的消息。这些标准可以包括但不限于iso8583和iso20022，它们一般分别规定与由账户持有者使用支付卡进行的电子交易相关的消息和金融机构之间传送的消息的格式和内容。在还有其它实施例中，报告可以以与通过网络210传送的其它消息兼容并插入其中的格式来生成。例如，订户abu250可以生成适于插入通过网络210在商家和发行方之间发送的认证请求或响应消息的报告。
订户abu250还被配置为一旦商家230注册请求被批准就将更新后的账户数据传送给商家230。订户abu250可以一经从商家230接收到更新请求和/或基于预定事件就传送更新后的账户数据。更新请求可以直接从商家230通过网络210接收，或者可以由收单方(诸如图1的商家银行26)一起批处理，并以批的格式被传送给订户abu250。更新请求一般包括一个或多个商家标识符，以及商家230正在请求(一个或多个)当前账户持有者支付卡账户信息的一个或多个账户标识符。响应于更新请求，订户abu250使用商家标识符访问存储在账户信息数据源252中的支付卡账户数据。随后，订户abu250可以从账户信息数据源252检索对应的当前账户信息，并将包含当前账户信息的响应消息传送给商家230。
在另一个实施例中，订户abu250被配置为基于预定事件自动向商家230传送包含当前账户信息的响应消息。在某些实施例中，订户abu250可以一经从发行方260接收到更新后的账户数据就从账户信息数据源252检索与商家230相关联的当前账户信息。随后，订户abu250可以将包含当前账户信息的消息传送到商家230。在其它实施例中，订户abu250可以基于预定时间表从账户信息数据源252检索与商家230相关联的当前账户信息。例如，订户abu250可以被配置为每天向商家230传送包含当前账户信息的消息。
在某些实施例中，订户abu250可以累积更新后的账户信息并向商家230提交一批更新后的账户信息。在替代实施例中，订户abu250可以一经从商家230接收到更新请求就将该批传送到商家230。在其它实施例中，订户abu250可以基于预定事件自动将该批传送到商家230。
在替代实施例中，订户abu250可以认证商家230当前被授权接收更新后的账户数据。基于认证，订户abu250可以确定商家230当前被授权接收更新后的账户数据，并且可以生成包含当前支付卡账户数据的更新消息并将其传送给商家230。或者，订户abu250可以确定商家230不再被授权接收更新后的账户数据并对商家230拒绝对更新后的账户数据的访问。订户abu250可以生成并传送拒绝消息，该拒绝消息表明对商家230拒绝对更新后的账户数据的访问。更新消息和/或拒绝消息也可以由订户250发送到发行方260。
订户abu计算设备的示例
图3是图示根据本公开示例实施例的可以被包括在图2的订户abu系统中的订户账户存档计费更新器(abu)计算设备的示例实施例的图。
参考图3，订户abu计算设备300可以与图2中所示的设备认证器250对应。订户abu计算设备300可以耦合到支付处理器240，或者可以是被包括在图2的系统中的分开的计算设备，并且可以经由网络210连接到一个或多个其它计算设备。在这个示例中，订户abu计算设备300包括接收器310、分析器320、处理器330和传送器340。订户abu计算设备300可以包括未示出的附加部件，或者少于所示部件的数量。而且，这个示例中的一个或多个部件可以组合或者可以由处理器330替换。本文描述的计算机部件(例如，接收器310；分析器320；处理器330；以及传送器340)可以包括专门被配置或编程为执行本文所述步骤的硬件和/或软件。
接收器310一般被配置为从一个或多个发行方(诸如图2的发行方260)接收账户数据。这种账户数据可以包括但不限于支付卡账号、支付卡账户到期日期等。接收器310还可以被配置为从各种数据源检索账户数据。例如，接收器310可以从账户信息数据源252、欺诈信息数据源254和发行方规则信息数据源256中的每个接收账户数据，如图2中所描绘的。接收器310还可以被配置为从一个或多个请求方(诸如商家)接收对存储在账户信息数据源252中的账户数据的更新请求。接收器310还可以被配置为从一个或多个欺诈监控源(诸如mastercard有效避免欺诈系统(safe)、mastercardexpertmonitoringsystem(ems)或任何其它欺诈监控源)接收存储在欺诈信息数据源254中的欺诈数据。接收器310还可以被配置为从发行方接收存储在发行方规则信息数据源256中的订阅规则。在某些实施例中，接收器310还可以被配置为接收通过交换网络(诸如图2的网络210)发送的消息，其可以包括但不限于授权请求和响应消息。由接收器310接收的消息和账户数据可以是以批格式，其聚合来自多个账户的多个消息或数据。因而，接收器310可以被配置为从这种批的格式解析个体消息和账户数据条目。
分析器320分析通过接收器310接收的数据和消息。分析器320一般确定接收到的数据或消息的类型，并识别处理器330要如何处理该数据或消息。在某些实施例中，分析器320可以确定由接收器310接收的数据或消息是否包括识别由接收器310接收的数据或消息的类型的标志或其它指示符。例如，指示符可以将消息标识为更新请求、欺诈数据或诸如授权请求或授权响应消息的交易相关消息之一。
在由分析器320分析之后，处理器330可以进一步分析和处理由接收器310接收的数据和消息，并执行附加的abu相关功能。
响应于从发行方接收到账户数据更新，处理器330一般可以更新账户信息数据源。例如，处理器330可以确定从发布方接收的账户数据更新是否包括与在账户信息数据源中维护数据的账户对应的账户数据。处理器330还可以将任何现有数据与账户数据更新的数据进行比较，以确定是否已发生了任何变化。最后，处理器330可以对于与新账户对应的任何数据向账户信息数据源添加新条目或者覆写现有账户的任何过期数据。由处理器330在账户信息数据源中记录的数据可以包括但不限于账号和到期日期。
当更新账户信息数据源中的现有记录时，处理器330还可以填充数据字段或创建被覆写的账户数据的记录。这些字段或记录可以被交叉引用或以其它方式链接到从发行方接收的对应的更新后的账户数据。这样做允许订户abu计算设备300识别与可以由请求方提交的过期账户数据对应的当前账户数据。
响应于从商家接收到注册请求，处理器330可以使用至少一个订阅规则来核实商家被授权接收更新后的账户数据，并确定商家被授权接收更新后的账户数据。更具体而言，处理器330可以确定什么账户数据正在被请求并确定要应用的至少一个订阅规则，应用至少一个订阅规则，确定商家是否被授权接收更新后的账户数据，批准注册请求，以及生成由传送器340传输的注册接受或拒绝响应。
在某些实施例中，处理器330可以基于被包括在账户数据中的银行标识号(bin)从订阅规则集合中选择订阅规则。例如，处理器330可以通过应用至少一个订阅规则用于确定商家被授权接收更新后的账户数据来核实商家被授权接收更新后的账户数据，至少一个订阅规则包括以下中的至少一个：确定商家具有与账户标识符对应的先前批准的交易，和确定由商家发送的注册请求自从与账户标识符对应的上次批准的交易以来在预定时间段内被接收到。
处理器330可以通过应用至少一个订阅规则用于确定从商家欺诈数据导出的商家来核实商家被授权接收更新后的账户数据。例如，确定从商家欺诈数据导出的欺诈退款计数在预定欺诈退款计数限制内；确定从商家欺诈数据导出的欺诈退款百分比在预定欺诈退款百分比限制内；以及确定商家不是公共欺诈点。
在某些实施例中，处理器330可以通过应用至少一个订阅规则用于确定从账户欺诈数据导出的商家来核实商家被授权接收更新后的账户数据。例如，确定账户标识符不具有从账户欺诈数据导出的预定欺诈指示符；确定账户标识符不在账户黑名单上；以及确定账户标识符的日期在预定日期限制内。
处理器330可以通过应用至少一个订阅规则用于确定从建议代码数据导出的商家来核实商家被授权接收更新后的账户数据。例如，确定从建议代码导出的反馈动作计数在预定反馈动作计数限制内，以及确定从建议代码导出的反馈动作百分比在预定反馈动作百分比限制内。在一些实施例中，处理器330可以通过应用至少一个订阅规则用于确定从商家黑名单导出的商家来核实商家被授权接收更新后的账户数据，例如确定商家不在商家黑名单上。
除了处理账户数据之外，处理器330还可以在欺诈信息数据源中创建或更新条目。欺诈信息数据源一般可以存储关于账户和/或商家活动的信息。因而，对于一个或多个支付卡账户，处理器330可以在欺诈信息数据源中创建或修改指示账户活动数据和/或账户欺诈数据的记录。此外，对于一个或多个商家标识符，处理器330可以在欺诈信息数据源中创建或修改指示商家活动数据和/或商家欺诈数据的记录。
处理器330还可以被配置为处理与发行方规则信息数据源内的发行方的订阅规则对应的订阅规则。此外，处理器可以生成包含或基于来自账户信息数据源、欺诈信息数据源和发行方规则信息数据源中的一个或多个的数据的更新响应。
在某些实施例中，订户abu计算设备300还可以包括用于传送数据的传送器340，数据包括但不限于注册接受/拒绝响应、更新响应消息以及对来自账户信息数据源、欺诈信息数据源和发行方规则信息数据源中的一个或多个的账户数据的请求/查询。
用于维护和核实账户存档信息的示例方法
图4是图示用于维护和核实账户存档信息的方法400的示例的图，该方法可以由与至少一个存储器设备通信的订户账户存档计费更新器(abu)计算设备(诸如图3的订户abu计算设备300)执行。
最初，订户abu计算设备可以从发行方402接收更新后的账户数据连同至少一个订阅规则，发行方402可以是发行银行。更新后的账户数据可以与持卡人(诸如账户持有者)对应。可以提供至少一个订阅规则来核实商家被授权接收当前账户数据。订户abu计算设备可以从发行方请求更新后的账户数据连同至少一个订阅规则，或者发行方可以在没有请求的情况下将当前账户数据连同至少一个订阅规则一起传送到订户abu计算设备。
然后，订户abu计算设备可以将更新后的账户数据存储在第一数据存储装置404中，并且将至少一个订阅规则存储在第二数据存储装置406中。在一个实施例中，第一数据存储装置和第二数据存储装置可以在分开的账户信息数据源中。在另一个实施例中，第一数据存储装置和第二数据存储装置可以在单个账户信息数据源中。将更新后的账户数据和至少一个订阅规则存储在账户信息数据源中可以包括在账户信息数据源中创建新条目或覆写现有条目。存储更新后的账户数据还可以包括更新对应的数据字段，诸如更新的上次日期/时间和/或过期的账户数据。
订户abu计算设备可以从发出请求的商家408接收注册请求。注册请求可以包括至少一个候选账户标识符和一个商家标识符，其中每个商家标识符识别请求对应的账户标识符的注册核实的商家。响应于接收到注册请求，订户abu计算设备可以在将候选账户标识符与更新后的账户标识符410匹配之后从第二数据存储装置中检索至少一个订阅规则。订户abu计算设备可以将至少一个订阅规则应用于发出请求的商家412以确定商家被授权接收更新后的账户数据414。
在某些实施例中，订户abu计算设备可以基于被包括在账户数据中的银行标识号(bin)从订阅规则集合中选择订阅规则。例如，订户abu计算设备可以通过应用至少一个订阅规则来核实商家被授权接收更新后的账户数据，该至少一个订阅规则包括以下中的至少一个：确定商家具有与账户标识符对应的先前批准的交易，和确定由商家发送的更新请求自从与账户标识符对应的上次批准的交易以来在预定时间段内被接收到。
订户abu计算设备还可以从欺诈监控源接收商家欺诈数据，并通过应用至少一个订阅规则用于确定从商家欺诈数据导出的商家来核实注册请求。例如，确定从商家欺诈数据导出的欺诈退款计数在预定欺诈退款计数限制内；确定从商家欺诈数据导出的欺诈退款百分比在预定欺诈退款百分比限制内；以及确定商家不是公共欺诈点。
在某些实施例中，订户abu计算设备可以从欺诈监控源接收账户欺诈数据，并通过应用至少一个订阅规则用于确定从账户欺诈数据导出的商家来核实商家被授权接收更新后的账户数据。例如，确定账户标识符不具有从账户欺诈数据导出的预定欺诈指示符；确定账户标识符不在账户黑名单上；以及确定账户标识符的日期在预定日期限制内。
订户abu计算设备还可以接收与发行方和商家之间的支付卡交易响应对应的建议代码，并存储该建议代码。通过应用至少一个订阅规则用于确定从建议代码数据导出的商家，核实商家被授权接收更新后的账户数据可以发生。例如，确定从建议代码导出的反馈动作计数在预定反馈动作计数限制内，以及确定从建议代码导出的反馈动作百分比在预定反馈动作百分比限制内。
在一些实施例中，订户abu计算设备可以接收商家黑名单并通过应用至少一个订阅规则用于确定从商家黑名单导出的商家(例如，确定商家不在商家黑名单上)来核实商家被授权接收更新后的账户数据。在其它实施例中，订户abu计算设备可以从发行方接收订阅规则。
订户abu计算设备可以确定商家被授权接收更新后的账户数据并批准注册请求，生成并向商家416传送注册接受响应和更新响应，或者订户abu计算设备可以确定商家未通过核实并拒绝注册请求，从而生成对商家的注册拒绝响应。
附加的考虑
计算机程序(也称为程序、软件、软件应用、“应用”或代码)包括用于可编程处理器的机器指令，并且可以以高级过程和/或面向对象的编程语言和/或汇编/机器语言来实现。如本文所使用的，术语“机器可读介质”和“计算机可读介质”是指用于向可编程处理器提供机器指令和/或数据的任何计算机程序产品、装置和/或设备(例如，磁盘、光盘、存储器、可编程逻辑设备(pld))，包括接收机器指令作为机器可读信号的机器可读介质。但是，“机器可读介质”和“计算机可读介质”不包括瞬态信号。术语“机器可读信号”是指用于向可编程处理器提供机器指令和/或数据的任何信号。
如本文所使用的，术语“卡”、“交易卡”、“金融交易卡”和“支付卡”是指任何合适的交易卡，诸如信用卡、借记卡、预付卡、收费卡、会员卡、促销卡、常旅客卡、身份证、礼品卡，和/或可以持有支付账户信息的任何其它设备，诸如移动电话、智能电话、个人数字助理(pda)、密钥卡(keyfob)和/或计算机。每种类型的交易卡都可以用作用于执行交易的支付方法。此外，消费者卡账户行为可以包括但不限于购买、管理活动(例如，余额检查)、账单支付、目标的实现(满足账户余额目标、按时支付账单)和/或产品注册(例如，移动应用下载)。
例如，一个或多个计算机可读存储介质可以包括在其上实施的用于维护账户存档信息的计算机可执行指令。在这个示例中，计算设备可以包括存储器设备和与存储器设备通信的处理器，并且当由所述处理器执行时，计算机可执行指令可以使处理器执行方法，诸如在图4-6的示例中所描述和示出的方法。
如本文所使用的，处理器可以包括任何可编程系统，包括使用微控制器、精简指令集电路(risc)、专用集成电路(asic)、逻辑电路以及能够执行本文所述功能的任何其它电路或处理器的系统。以上示例仅是示例，因此不旨在以任何方式限制术语“处理器”的定义和/或含义。
如本文所使用的，术语“软件”和“固件”是可互换的，并且包括存储在存储器中以供处理器执行的任何计算机程序，包括ram存储器、rom存储器、eprom存储器、eeprom存储器和非易失性ram(nvram)存储器。上述存储器类型仅是示例，因此对于可用于存储计算机程序的存储器的类型不是限制性的。
在一个实施例中，提供了一种计算机程序，并且该程序在计算机可读介质上实施。在示例中，系统在单个计算机系统上执行，而不连接到服务器计算机。在另一个示例中，系统在
如本文所使用的，以单数形式且以词“一”或“一个”开头的元素或步骤应当理解为不排除多个元素或步骤，除非明确地叙述了这种排除。此外，对本公开的“示例实施例”或“一个实施例”的引用不旨在被解释为排除还结合所述特征的附加示例的存在。
本文件末尾的专利权利要求书不旨在援引35u.s.c.§112(f)进行解释，除非明确叙述了传统的装置加功能语言，诸如在(一个或多个)权利要求中明确陈述的“用于……的装置”或“用于……的步骤”语言。
本书面描述使用示例来描述本公开，包括最佳模式，并且还使得本领域的任何技术人员能够实践本公开，包括制造和使用任何设备或系统以及执行任何结合的方法。本公开的专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有不与权利要求的字面语言不同的结构元素，或者如果它们包括与权利要求的字面语言无实质区别的等同结构元素，那么这些其它示例意图在权利要求的范围内。
- 还没有人留言评论。精彩留言会获得点赞！