额度信息的获取方法、额度管控规则的建立方法及装置与流程

本说明书一个或多个实施例涉及额度管控技术领域，尤其涉及一种额度信息的获取方法、额度管控规则的建立方法及装置。

背景技术：

在相关技术中，很多业务系统都存在额度管控需求，并为此分别采用独立的额度管控功能。比如，账号管理系统在处理用户账号的登录行为时，可以限制每一用户账号在每天允许发生的连续密码输入错误事件，以防止出现账号盗用。

技术实现要素：

有鉴于此，本说明书一个或多个实施例提供一种额度信息的获取方法、额度管控规则的建立方法及装置，可以对多个业务系统进行集中式的额度管控，有助于简化业务系统的复杂度，实现对额度管控功能的复用、节省处理资源。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种额度信息的获取方法，包括：

额度管控平台接收业务系统传入的额度管控请求；

所述额度管控平台查询对应的额度管控规则库，以获取匹配于所述额度管控请求的额度管控规则；

所述额度管控平台根据所述额度管控规则确定所述额度管控请求对应的额度信息；

所述额度管控平台向所述业务系统返回所述额度信息，以由所述业务系统实施相应的额度管控操作。

根据本说明书一个或多个实施例的第二方面，提出了一种额度管控规则的建立方法，包括：

额度管控平台接收业务系统传入的规则创建请求；

所述额度管控平台根据所述业务系统输入的额度管控主体、管控目标、规则维度和管控策略，生成相应的额度管控规则；所述额度管控规则用于指示所述额度管控平台：在所述业务系统传入匹配于所述额度管控主体和所述规则维度的额度管控请求时，按照所述管控策略对所述管控目标进行额度管控；

所述额度管控平台将所述额度管控规则存入对应的额度管控规则库。

根据本说明书一个或多个实施例的第三方面，提出了一种额度信息的获取所述，包括：

接收单元，使额度管控平台接收业务系统传入的额度管控请求；

查询单元，使所述额度管控平台查询对应的额度管控规则库，以获取匹配于所述额度管控请求的额度管控规则；

确定单元，使所述额度管控平台根据所述额度管控规则确定所述额度管控请求对应的额度信息；

返回单元，使所述额度管控平台向所述业务系统返回所述额度信息，以由所述业务系统实施相应的额度管控操作。

根据本说明书一个或多个实施例的第四方面，提出了一种额度管控规则的建立装置，包括：

接收单元，使额度管控平台接收业务系统传入的规则创建请求；

生成单元，使所述额度管控平台根据所述业务系统输入的额度管控主体、管控目标、规则维度和管控策略，生成相应的额度管控规则；所述额度管控规则用于指示所述额度管控平台：在所述业务系统传入匹配于所述额度管控主体和所述规则维度的额度管控请求时，按照所述管控策略对所述管控目标进行额度管控；

存储单元，使所述额度管控平台将所述额度管控规则存入对应的额度管控规则库。

由以上技术方案可见，本说明书一个或多个实施例通过建立统一的额度管控平台，可以对各个业务系统提供集中式的额度管控，而无需由业务系统单独实现额度管控功能，有助于降低业务系统的复杂度，并且便于处理资源在各个业务系统之间实现共用。同时，通过使用额度管控规则，便于业务系统自定义所需的额度管控功能，从而满足各个业务系统的个性化的额度管控需求。

附图说明

图1是一示例性实施例提供的一种额度管控系统的示意图。

图2是一示例性实施例提供的一种额度管控系统的架构示意图。

图3是一示例性实施例提供的一种额度信息的获取方法的流程图。

图4是一示例性实施例提供的一种额度管控规则的建立方法的流程图。

图5是一示例性实施例提供的一种建立额度管控规则的示意图。

图6是一示例性实施例提供的一种实施额度管控的示意图。

图7是一示例性实施例提供的一种额度管控方法的流程图。

图8是一示例性实施例提供的一种电子设备的结构示意图。

图9是一示例性实施例提供的一种额度信息的获取装置的框图。

图10是一示例性实施例提供的另一种电子设备的结构示意图。

图11是一示例性实施例提供的一种额度管控规则的建立装置的框图。

具体实施方式

图1是一示例性实施例提供的一种额度管控系统的示意图。如图1所示，以客户平台11(用于响应和处理客户业务等)、数据平台12(用于响应和处理数据业务等)、对象平台13(用于响应和处理对象业务等)等多个业务系统为例，本说明书一个或多个实施例可以通过提供如图1所示的额度管控系统10，对上述的客户平台11、数据平台12、对象平台13等各个业务系统进行集中式、统一化的额度管控，而无需在各个业务系统中单独实现额度管控功能，不仅可以在满足各个业务系统的个性化额度管控需求的同时，降低业务系统的复杂度，而且有助于对各个业务系统的额度管控情况进行统一查看和管理。

图2是一示例性实施例提供的一种额度管控系统的架构示意图。如图2所示，该系统可以包括额度管控平台21和业务系统22、业务系统23等至少一个业务系统。

额度管控平台21可以为包含一独立主机的物理服务器，或者该额度管控平台21可以为主机集群承载的虚拟服务器，或者该额度管控平台21可以为云服务器。在运行过程中，额度管控平台21可以实现本说明书一个或多个实施例的额度管控功能。

业务系统22、业务系统23等可以为包含一独立主机的物理服务器，或者该业务系统22、业务系统23等可以为主机集群承载的虚拟服务器，或者该业务系统22、业务系统23等可以为云服务器。在运行过程中，业务系统22、业务系统23等可以分别实现各自的业务功能，并在额度管控平台21处实现所需的额度管控功能，而无需单独集成额度管控功能。

而对于业务系统22、业务系统23等与额度管控平台21之间进行交互的网络24，可以包括多种类型的有线或无线网络。在一实施例中，该网络24可以包括公共交换电话网络(publicswitchedtelephonenetwork，pstn)和因特网。

图3是一示例性实施例提供的一种额度信息的获取方法的流程图。如图3所示，该方法可以包括以下步骤：

步骤302，额度管控平台接收业务系统传入的额度管控请求。

步骤304，所述额度管控平台查询对应的额度管控规则库，以获取匹配于所述额度管控请求的额度管控规则。

在本实施例中，所述额度管控规则库可以用于集中记录所有业务系统对应的额度管控规则。换言之，额度管控平台可以同时对接所有业务系统，每个业务系统均可以根据实际需求在额度管控平台上建立所需的额度管控规则，并由额度管控平台记录于额度管控规则库中，以便于各个业务系统后续从该额度管控规则库中选取所需的额度管控规则。当然，在其他实施例中，额度管控平台也可以分别为每一业务系统创建独立的额度管控规则库，以分别存储各个业务系统建立的额度管控规则。

在本实施例中，所述额度管控平台可以从所述额度管控请求中获取额度管控主体的信息，并从所述额度管控规则库中获取与所述额度管控主体相关的备选额度管控规则；然后，所述额度管控平台解析所述备选额度管控规则包含的第一维度，并确定所述额度管控主体在所述第一维度下的第一维度值，从而筛选出符合所述第一维度和所述第一维度值的备选额度管控规则，以作为匹配于所述额度管控请求的额度管控规则。例如，假定额度管控主体为用户，额度管控请求中可以包含该用户的用户账号，使得额度管控管控平台可以从额度管控规则库中选取所有与该用户账号相关的备选额度管控规则；假定每一用户账号存在相应的会员等级，比如会员等级可以包括金牌会员、银牌会员、铜牌会员等，而业务系统可以分别创建对应于金牌会员的第一规则、对应于银牌会员的第二规则、对应于铜牌会员的第三规则等，但是由于额度管控请求中并未包含上述用户账号在“会员等级”维度上的维度值，因而额度管控平台首先会获取上述的第一规则、第二规则和第三规则等，并从这些规则中解析出诸如“会员等级”等第一维度，然后额度管控平台再通过确认上述用户账号在该“会员等级”维度下的维度值，比如当该维度值为“金牌会员”时，额度管控平台应当确定上述的第一规则匹配于上述的额度管控请求，因而筛选出上述的第一规则、筛除第二规则、第三规则等其他的备选额度管控规则。

其中，上述的第一维度可以为静态维度，即该第一维度对应的第一维度值不会发生变化，比如当业务系统需要实现充值业务时，假定第一维度为“充值渠道”，相应的第一维度值可以固定为“银行a”，而额度管控平台可以直接获取静态的所述第一维度值；例如，业务系统可以在发起额度管控请求时，在该额度管控请求中包含该第一维度对应的第一维度值，使得额度管控平台可以读取该第一维度值。或者，上述的第一维度可以为动态维度，即该第一维度对应的第一维度值可能发生变化，比如当业务系统需要实现重置业务时，假定第一维度为“会员等级”，则由于用户的“会员等级”可能发生变化，因而第一维度值也会随之变化，那么额度管控平台可以确定所述第一维度对应的维度值提供方，并从所述维度值提供方处获取动态的所述第一维度值。

在本实施例中，所述额度管控请求中除了可以包含上述额度管控主体的信息之外，还可以包括第二维度的第二维度值，使得额度管控平台在获取上述的备选额度管控规则时，还可以使得备选额度管控规则与所述第二维度和所述第二维度值相关，从而在一定程度上减少备选额度管控规则的数量，有助于在后续过程中更为高效地从备选额度管控规则中筛选出匹配于额度管控请求的额度管控规则。

步骤306，所述额度管控平台根据所述额度管控规则确定所述额度管控请求对应的额度信息。

在本实施例中，装置额度管控平台可以根据所述额度管控请求对应的额度管控主体，确定所述额度管控主体的已使用额度；然后，所述额度管控平台根据所述已使用额度和所述额度管控规则定义的总额度，计算相应的剩余额度，以作为所述额度管控请求对应的额度信息。

其中，当所述额度管控请求存在多条相匹配的额度管控规则时，所述额度管控平台可以分别计算每条额度管控规则对应的剩余额度，然后选出数值最小的剩余额度，以作为所述额度管控请求对应的额度信息。

步骤308，所述额度管控平台向所述业务系统返回所述额度信息，以由所述业务系统实施相应的额度管控操作。

相应地，图4是一示例性实施例提供的一种额度管控规则的建立方法的流程图。如图4所示，该方法可以包括以下步骤：

步骤402，额度管控平台接收业务系统传入的规则创建请求。

步骤404，所述额度管控平台根据所述业务系统输入的额度管控主体、管控目标、规则维度和管控策略，生成相应的额度管控规则；所述额度管控规则用于指示所述额度管控平台：在所述业务系统传入匹配于所述额度管控主体和所述规则维度的额度管控请求时，按照所述管控策略对所述管控目标进行额度管控。

在本实施例中，各个业务系统可能对同一规则维度分别采用自定义的描述方式；那么，所述额度管控平台可以根据业务系统采用的第一描述方式和该额度管控平台自行使用的第二描述方式，建立起该第一描述方式与第二描述方式之间的映射关系，使得当所述规则维度被所述业务系统采用自定义的第一描述方式进行描述时，所述额度管控平台可以根据该映射关系，将所述规则维度由所述第一描述方式转换为所述额度管控平台采用的第二描述方式。

步骤406，所述额度管控平台将所述额度管控规则存入对应的额度管控规则库。

在本实施例中，所述额度管控规则库可以用于集中记录所有业务系统对应的额度管控规则。换言之，额度管控平台可以同时对接所有业务系统，每个业务系统均可以根据实际需求在额度管控平台上建立所需的额度管控规则，并由额度管控平台记录于额度管控规则库中，以便于各个业务系统后续从该额度管控规则库中选取所需的额度管控规则。当然，在其他实施例中，额度管控平台也可以分别为每一业务系统创建独立的额度管控规则库，以分别存储各个业务系统建立的额度管控规则。

由以上技术方案可见，本说明书一个或多个实施例通过建立统一的额度管控平台，可以对各个业务系统提供集中式的额度管控，而无需由业务系统单独实现额度管控功能，有助于降低业务系统的复杂度，并且便于处理资源在各个业务系统之间实现共用。同时，通过使用额度管控规则，便于业务系统自定义所需的额度管控功能，从而满足各个业务系统的个性化的额度管控需求。

为了便于理解，下面以第三方支付场景为例，针对本说明书一个或多个实施例的技术方案进行详细说明。在第三方支付场景下，第三方支付公司内部往往会涉及到很多业务系统，比如图5-6所示的资金平台、客户平台、支付平台等，这些业务系统都需要实现独立的额度管控，可以通过额度管控平台予以实现。

1、建立额度管控规则

图5是一示例性实施例提供的一种建立额度管控规则的示意图。如图5所示，第三方支付公司中的资金平台51、客户平台52、支付平台53等各个业务系统可以各自向额度管控平台54发起规则创建请求，以建立满足其个性化需求的额度管控规则。同时，由于各个业务系统的额度管控功能都由额度管控平台54实现，可以避免各个业务系统对于额度管控功能的重复开发和资源浪费，并且便于第三方支付公司的管理人员从额度管控平台54处通过统一视图查看各个业务系统的额度管控状况。并且，基于本说明书一个或多个实施例的额度管控方案，当第三方支付公司出现新的业务系统时，只需要同样接入额度管控平台54并创建相应的额度管控规则即可，从而实现对新的业务系统的无缝接入，易于兼容对业务系统的扩展。

资金平台51、客户平台52、支付平台53等业务系统在需要创建额度管控规则时，可以向额度管控平台54发起规则创建请求，该规则创建请求中包括：额度管控主体、管控目标、规则维度和管控策略，以供额度管控平台54据此生成相应的额度管控规则。

额度管控主体。额度管控主体用于表明“对谁进行额度管控”，可以表征为任何能够被业务系统标识的个体，比如第三方支付公司的客户、该客户的账户、该客户的银行卡、第三方支付公司的外部合作商户等，均可以作为本说明书一个或多个实施例中的额度管控主体。

管控目标。管控目标用于表明“对什么进行额度管控”，可以表征为额度管控主体所能够支配的任何对象，比如金额、交易笔数、密码输错次数等，并且可以管控目标可以仅包含一种对象(比如单独管控“金额”或“交易笔数”)，也可以同时包含多种对象(比如同时管控“金额”和“交易笔数”)。并且，针对每种对象可以对细粒度进行选择；以“金额”为例，可以针对“货币种类”进行细粒度选择，比如当选择“人民币”时，可以针对“人民币”实施相应的额度管控，而“美元”或其他币种则不受可以额度管控或实施其他的额度管控。

规则维度。规则维度用于表明“在什么场景下进行额度管控”，可以表征为额度管控主体或管控目标相关的任意维度，以“产品”维度为例，可以划分为支付产品、提现产品等。其中，本说明书一个或多个实施例的规则维度可以按照多个层次的细粒度进行划分，比如仍以“产品”维度为例，针对上述的支付产品、提现产品等，可以进一步实现更小细粒度的划分，比如这些更小细粒度的维度可以来源于产品属性(如支付产品的支付渠道等)、用户属性(如用户的认证等级)、商户属性(如商户的商品类目)、卡号属性(如信用卡或储蓄卡等)等。

规则维度可以包括两种类型：静态维度和动态维度。静态维度是指维度值维持不变的维度，比如“支付渠道”可以固定为“银行a”、“银行b”等，这些静态维度的维度值可以由业务系统确定后，包含在上述的规则创建请求中，以传入额度管控平台54。动态维度是指维度值可能发生变化的维度，比如“用户的认证等级”可能随着用户行为而发生变化，那么业务系统可以不将相应的维度值随规则创建请求传入额度管控平台54，而由额度管控平台54从相应的维度值提供方处获得。

管控策略。管控策略用于表明“怎么进行额度管控”。业务系统可以从多个角度定义管控策略，比如管控周期等；当然，本说明书一个或多个实施例并不对此进行限制。以管控周期为例，业务系统可以设定该管控周期为单笔、日、月、年、终身等，当然也可以采用其他任意时长作为该管控周期。

额度管控平台54通过提取规则创建请求中的额度管控主体、管控目标、规则维度和管控策略等信息，即可生成相应的额度管控规则。额度管控规则可以包括额度管控主体、管控目标等信息，以及采用规则表达式的形式来记录规则适用的情况，比如该规则表达式可以通过“与”、“或”、“非”、“等于”、“不等于”等逻辑来组合表现上述的管控策略等。

其中，业务系统可能由于行业习惯等原因，对于相同对象的描述方式与额度管控平台54不一致，比如对于上述规则维度中的维度名称和维度值，业务系统可能采用第一描述方式、额度管控平台54可能采用第二描述方式。那么，额度管控平台54在接收到业务系统传入的规则创建请求时，可以根据该第一描述方式与第二描述方式之间的映射关系，对该规则创建请求中的上述规则维度等信息进行转换，使其转换为适用于该额度管控平台54，便于额度管控平台54进行统一管理。

额度管控平台54可以维护如图5所示的额度管控规则库55，该额度管控规则库55用于额度管控平台54存储各个业务系统创建的额度管控规则。当然，额度管控平台54也可以针对每一业务系统分别维护对应的额度管控规则库，本说明书一个或多个实施例并不对此进行限制。

2、实施额度管控

图6是一示例性实施例提供的一种实施额度管控的示意图。如图6所示，第三方支付公司中的各个业务系统存在额度管控需求时，可以向额度管控平台54发送相应的额度管控请求，下面以业务系统“支付平台53”为例，结合图7对额度管控平台54实施额度管控的过程进行描述。如图7所示，实施额度管控的过程可以包括以下步骤：

步骤702，额度管控平台54收到来自支付平台53的额度管控请求。

额度管控平台54在接收到支付平台53发送的额度管控请求时，可以获取该额度管控请求包含的额度管控主体的信息和场景维度的信息。举例而言，假定第三方支付公司中某一客户在支付平台53处登录一账户，并基于该账户实施支付操作，则额度管控请求中的额度管控主体可以为该账户，而场景维度可以为与该支付操作或相应的支付产品相关的某个维度。

步骤704，额度管控平台54获取额度管控请求包含的额度管控主体和场景维度。

步骤706，额度管控平台54获取与额度管控主体和场景维度相关的备选额度管控规则。

额度管控平台54可以基于上述的额度管控主体和场景维度的信息，从额度管控规则库55中选取与额度管控请求(实际上是指该额度管控请求中包含的上述额度管控主体和场景维度的信息)相关的备选额度管控规则。当然，在一些实施例中，额度管控请求中也可以仅包含额度管控主体的信息，则此处获得的备选额度管控规则可以仅与该额度管控主体的信息相关。但是，当额度管控平台54同时基于额度管控主体和场景维度从额度管控规则库55中查找相关的备选额度管控规则时，显然可以在一定程序上减少备选额度管控规则的数量，从而有助于提升在后续过程中对备选额度管控规则做进一步筛选的操作效率。

步骤708，额度管控平台54解析备选额度管控规则涉及的维度。

备选额度管控规则有可能最终匹配于额度管控请求，也有可能并不适用于额度管控请求。因此，额度管控平台54需要对备选额度管控规则做进一步筛选。以“支付渠道”和“用户的认证等级”这两个维度为例，假定“支付渠道”包括银行a、银行b，“用户的认证等级”包括金牌会员、银牌会员和铜牌会员，那么根据额度管控请求提供的额度管控主体和场景维度等信息，额度管控平台54可以获得这两个维度下的所有备选额度管控规则，即6条备选额度管控规则，分别对应于“银行a+金牌会员”、“银行a+银牌会员”、“银行a+铜牌会员”、“银行b+金牌会员”、“银行b+银牌会员”和“银行b+铜牌会员”。

步骤710a，当涉及到静态维度时，额度管控平台54从额度管控请求的请求参数中获取静态维度的维度值。

步骤710b，当涉及到动态维度时，额度管控平台54向动态维度的维度值提供方询问维度值。

额度管控平台54在选取备选额度管控规则时，虽然并不清楚这些备选额度管控规则的上述情况。但是，额度管控平台54可以通过解析上述的备选额度管控规则，确定这些备选额度管控规则所涉及到的规则维度，比如额度管控平台54可以确定上述的备选额度管控规则与“支付渠道”和“用户的认证等级”等维度相关。

那么，额度管控平台54可以进而针对额度管控请求包含的额度管控主体的信息，确定上述维度对应于该额度管控主体的维度值。对于“支付渠道”等静态维度，业务系统可以直接确定该静态维度的维度值，因而可以在额度管控请求中包含额度管控主体在该静态维度下的维度值，比如假定该维度值为“a银行”；对于“用户的认证等级”等动态维度，业务系统无法直接确定该动态维度的维度值，因而可以由额度管控平台54主动向该动态维度的维度值提供方(比如图6所示的会员管理平台56)进行询问，以获得相应的维度值，比如“金牌会员”。其中，可以由业务系统将该动态维度的维度值提供方的信息告知额度管控平台54，或者额度管控平台54上可以预配置有该动态维度的维度值提供方的信息，或者额度管控平台54可以通过其他途径获知该动态维度的维度值提供方的信息。

步骤712，额度管控平台54根据维度值筛选出匹配于额度管控请求的额度管控规则。

额度管控平台54根据确定出的“银行a”和“金牌会员”等维度值，可以对上述的备选额度管控规则进行筛选，从而将“银行a+金牌会员”对应的备选额度管控规则确定为匹配于上述的额度管控请求，而筛除其他的“银行a+银牌会员”、“银行a+铜牌会员”、“银行b+金牌会员”、“银行b+银牌会员”和“银行b+铜牌会员”等对应的备选额度管控规则。

在其他实施例中，业务系统可以主动向动态维度的维度值提供方发起询问，以获知该动态维度的维度值，并将该维度值包含于额度管控请求中。换言之，业务系统可以将静态维度、动态维度的维度值均添加至额度管控请求中，使得额度管控平台54可以根据该额度管控请求包含的额度管控主体、场景维度、静态维度及其维度值、动态维度及其维度值，直接从额度管控规则库中确定出相匹配的额度管控规则。但是，通过由额度管控平台54向动态维度的维度值提供方询问维度值，使得各个业务系统不需要与这些维度值提供方保持连接关系，而完全将询问操作集中于额度管控平台54上，可以显著简化整个系统的复杂度、提升系统可靠性。

步骤714，额度管控平台54计算剩余额度，并返回至支付平台。

额度管控平台54根据确定出的匹配于额度管控请求的额度管控规则，可以确定该额度管控规则定义的总额度，并结合额度管控主体的已使用额度，从而计算出相应的剩余额度，将该剩余额度作为额度信息返回至业务系统。例如，假定银行a规定金牌会员的每日支付限额为2万元人民币，如果上述客户的账户在当天已经支付了1万3千元人民币，那么额度管控平台54可以告知支付平台53其剩余额度为7千元人民币；相应地，支付平台53可以据此确定基于该账户的支付操作是否能够顺利完成，比如当支付操作请求的支付额不大于7千元人民币时，该支付操作可以顺利完成，而当支付操作请求的支付额大于7千元人民币时，该支付操作将无法顺利完成。

在一些情况下，额度管控平台54可能同时匹配到多条额度管控规则。例如，假定规则1定义为a银行规定金牌会员的每日支付限额为2万元人民币，而规则2定义为a银行规定所有会员的每月支付限额为10万元人民币，如果上述客户的账户在当天已经支付了1万3千元人民币、当月已经支付了9万5千元人民币，那么额度管控平台54可以根据规则1计算出剩余额度为7千元人民币、根据规则2计算出剩余额度为5千元人民币，则额度管控平台54选取数值最小的剩余额度5千元人民币，并将其告知支付平台53。

综上所述，本说明书一个或多个实施例所提出的基于集中式的额度管控方案可以把额度管控缩小到几个关键的控制点进行控制，从而将业务系统从沉重的额度配置和繁琐的额度控制逻辑中解脱出来，可以在较短的开发周期内完成复杂的业务额度控制体系，提高功能复用率、提升研发效率。

同时，基于额度管控规则的管理方式，可以实现个性化、多样化的额度管控，包括：额度控制主体的的多样性、管控目标的多样性、规则维度的多样性、额度控制策略的多样性等。

此外，在本说明书一个或多个实施例的额度管控方案中，基于软件可配置和soa(service-orientedarchitecture，面向服务的架构)的思想，便于业务系统迅速、无缝地接入额度管控平台，可以提升管控效率、降低研发成本。

图8示出了根据本说明书一个或多个实施例的一示例性实施例的电子设备的示意结构图。请参考图8，在硬件层面，该电子设备包括处理器802、内部总线804、网络接口806、内存808以及非易失性存储器810，当然还可能包括其他业务所需要的硬件。处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行，在逻辑层面上形成额度信息的获取装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图9在软件实施方式中，该额度信息的获取装置可以包括：

接收单元901，使额度管控平台接收业务系统传入的额度管控请求；

查询单元902，使所述额度管控平台查询对应的额度管控规则库，以获取匹配于所述额度管控请求的额度管控规则；

确定单元903，使所述额度管控平台根据所述额度管控规则确定所述额度管控请求对应的额度信息；

返回单元904，使所述额度管控平台向所述业务系统返回所述额度信息，以由所述业务系统实施相应的额度管控操作。

可选的，所述额度管控规则库用于集中记录所有业务系统对应的额度管控规则。

可选的，所述查询单元902具体用于：

使所述额度管控平台从所述额度管控请求中获取额度管控主体的信息；

使所述额度管控平台从所述额度管控规则库中获取与所述额度管控主体相关的备选额度管控规则；

使所述额度管控平台解析所述备选额度管控规则包含的第一维度；

使所述额度管控平台确定所述额度管控主体在所述第一维度下的第一维度值；

使所述额度管控平台筛选出符合所述第一维度和所述第一维度值的备选额度管控规则，以作为匹配于所述额度管控请求的额度管控规则。

可选的，所述额度管控请求中还包括第二维度的第二维度值，所述备选额度管控规则还与所述第二维度和所述第二维度值相关。

可选的，所述查询单元902使所述额度管控平台通过下述方式确定所述额度管控主体在所述第一维度下的第一维度值：

当所述第一维度为静态维度时，使所述额度管控平台获取静态的所述第一维度值；

当所述第一维度为动态维度时，使所述额度管控平台确定所述第一维度对应的维度值提供方，并从所述维度值提供方处获取动态的所述第一维度值。

可选的，所述确定单元903具体用于：

使所述额度管控平台根据所述额度管控请求对应的额度管控主体，确定所述额度管控主体的已使用额度；

使所述额度管控平台根据所述已使用额度和所述额度管控规则定义的总额度，计算相应的剩余额度，以作为所述额度管控请求对应的额度信息。

可选的，所述确定单元903具体还用于：

当所述额度管控请求存在多条相匹配的额度管控规则时，使所述额度管控平台分别计算每条额度管控规则对应的剩余额度；

使所述额度管控平台选出数值最小的剩余额度，以作为所述额度管控请求对应的额度信息。

图10示出了根据本说明书一个或多个实施例的一示例性实施例的电子设备的示意结构图。请参考图10，在硬件层面，该电子设备包括处理器1002、内部总线1004、网络接口1006、内存1008以及非易失性存储器1010，当然还可能包括其他业务所需要的硬件。处理器1002从非易失性存储器1010中读取对应的计算机程序到内存1008中然后运行，在逻辑层面上形成额度管控规则的建立装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图11，在软件实施方式中，该额度管控规则的建立装置可以包括：

接收单元1101，使额度管控平台接收业务系统传入的规则创建请求；

生成单元1102，使所述额度管控平台根据所述业务系统输入的额度管控主体、管控目标、规则维度和管控策略，生成相应的额度管控规则；所述额度管控规则用于指示所述额度管控平台：在所述业务系统传入匹配于所述额度管控主体和所述规则维度的额度管控请求时，按照所述管控策略对所述管控目标进行额度管控；

存储单元1103，使所述额度管控平台将所述额度管控规则存入对应的额度管控规则库。

可选的，所述额度管控规则库用于集中记录所有业务系统对应的额度管控规则。

可选的，还包括：

转换单元1104，当所述规则维度被所述业务系统采用自定义的第一描述方式进行描述时，使所述额度管控平台根据预定义的映射关系，将所述规则维度由所述第一描述方式转换为所述额度管控平台采用的第二描述方式。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。