一种风险信息输出、风险信息构建方法及装置与流程

本申请涉及信息技术领域，尤其涉及一种风险信息输出、风险信息构建方法及装置。

背景技术：

随着信息技术的迅速发展，很多业务都可以在网上进行，给人们的生活带来了很多便利，同时，在网络上进行的业务也是存在风险的。比如，某些业务可能是非法业务，或者，某些业务虽然是合法业务，但是由非法用户冒充合法用户进行的，等等。针对这类情况，网上的业务平台一般会基于预定的风险控制规则和/或风险控制模型，对在该业务平台上进行的业务进行风险控制，得出风险控制决策结果，并输出给该业务的所属方，并根据风险控制决策结果对该业务进行后续处理，其中，风险控制决策结果可以是：拒绝该业务或通过该业务等。

在现有技术中，在输出风险控制决策结果时，还可以输出相应的风险信息给业务的所属方，该风险信息用于解释导致该风险控制决策结果的原因，目前，各业务平台一般都是预先对使用的风险控制规则进行简单的翻译，然后作为风险信息输出给业务的所属方。

但是，在实际应用中，业务的不同所属方的行业经验、风险控制能力参差不齐，相应地，业务的不同所属方对风险信息的需求程度或深度也可能不同，而上述现有技术中输出风险信息时并未考虑到这种差异，因此，上述现有技术中输出的风险信息对于业务的不同所属方的适用性较差。

技术实现要素：

本申请实施例提供一种风险信息输出、风险信息构建方法及装置，用以解决现有技术中输出的风险信息对于业务的不同所属方的适用性较差的问题。

本申请实施例提供的一种风险信息输出方法，包括：

根据预定的、包含一个或多个风险因子的风险控制规则和/或风险控制模型，在各所述风险因子中，确定与业务的风险控制决策结果对应的风险因子，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

确定与所述对应的风险因子对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致所述风险控制决策结果的原因；

根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息；

输出所述确定的风险信息，以便于所述业务的所属方获得所述确定的风险信息。

本申请实施例提供的一种风险信息输出装置，包括：

风险因子确定模块，用于根据预定的、包含一个或多个风险因子的风险控制规则和/或风险控制模型，在各所述风险因子中，确定与业务的风险控制决策结果对应的风险因子，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

风险信息第一确定模块，用于确定与所述对应的风险因子对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致所述风险控制决策结果的原因；

风险信息第二确定模块，用于根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息；

风险信息输出模块，用于输出所述确定的风险信息，以便于所述业务的所属方获得所述确定的风险信息。

本申请实施例提供的一种风险信息构建方法，包括：

对预定的风险控制规则和/或风险控制模型进行拆解，获得所述风险控制规则和/或风险控制模型包含的一个或多个风险因子；

分别为获得的各所述风险因子构建一个对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致业务的风险控制决策结果的原因，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

以便于在所述风险控制决策结果输出时，根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定并向所述业务的所属方输出细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息。

本申请实施例提供的一种风险信息构建装置，包括：

风险因子获得模块，用于对预定的风险控制规则和/或风险控制模型进行拆解，获得所述风险控制规则和/或风险控制模型包含的一个或多个风险因子；

风险信息构建模块，用于分别为获得的各所述风险因子构建一个对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致业务的风险控制决策结果的原因，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

以便于在所述风险控制决策结果输出时，根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定并向所述业务的所属方输出细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息。

本申请实施例通过上述至少一种技术方案，可以针对每个风险因子，构建对应于该风险因子的、细化程度不同的多级风险信息，以适应业务的不同所属 方对于风险信息需求的不同层级的需求程度和/或深度，并且可以用不同的风险信息需求等级，表征对于风险信息需求的不同层级的需求程度和/或深度，进而，在输出风险信息时，可以根据业务的所属方的风险信息需求等级，在多级风险信息中，确定并输出细化程度与业务的所属方的风险信息需求等级匹配的至少一级风险信息，以便于业务的所属方获得输出的风险信息，因此，本申请的方案输出的风险信息对于业务的不同所属方的适用性较好，可以部分或全部地解决上述现有技术中的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的风险信息输出方法的过程；

图2为本申请实施例提供的在一种针对支付业务的风险控制场景下，为各风险因子构建的风险信息集合示意图的一部分；

图3为本申请实施例提供的在一种针对支付业务的风险控制场景下，为各风险因子构建的风险信息集合示意图的一部分；

图4为本申请实施例提供的风险信息构建方法的过程；

图5为本申请实施例提供的一种针对支付业务的风险控制场景下，用于输出风险信息的infocode分级输出模块的结构示意图；

图6为本申请实施例提供的一种针对支付业务的风险控制场景下，infocode三层框架示例图；

图7为本申请实施例提供的对应于图1的风险信息输出装置结构示意图；

图8为本申请实施例提供的对应于图4的风险信息构建装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在背景技术中已经提到，风险信息可以用于解释导致对应的风险控制决策结果的原因，业务的不同所属方对风险信息的需求程度或深度也可能不同。

具体地，以业务的所属方是业务对应的商户为例。对于从业时间较长、经验丰富的商户，他们更希望看到风险控制决策结果背后的业务呈现出的各方面的风险信号，也即，更希望看到细化程度较高(比较具体的、深入的等)的风险信息，从而有助于提高自身风险控制水平、了解当前风险趋势；而对于行业新商户，他们更多投入在市场拓展，没有专业的团队接收和处理专业的风险信息输出，鉴于这种情况，细化程度较低(比较宏观的、浅显的等)的风险信息由于容易理解，因此，反而更适用于这类商户。

而现有技术中输出风险信息时并未考虑诸如上述差异，从而导致输出的风险信息对业务的不同所属方的适用性可能较差。

针对上述现有技术中的问题，本申请的方案的核心思想是：构建细化程度不同的多级(多个层级)风险信息，以适应业务的不同所属方对风险信息不同层级的需求程度和/或深度，从而提高输出的风险信息对业务的不同所属方的适用性，其中，对风险信息不同层级的需求程度和/或深度可以用不同的风险信息需求等级表征，多级风险信息可以是基于历史风险控制经验构建的。下面对本申请的方案进行详细说明。

图1为本申请实施例提供的风险信息输出方法的过程，该过程的执行主体可以是服务器或终端，更具体地，执行主体可以是服务器或终端上用于输出风险信息的功能模块。可作为所述服务器的设备包括但不限于：个人计算机、大中型计算机、计算机集群等；可作为所述终端的设备包括但不限于：手机、平 板电脑、智能手表、车载移动台、个人计算机等。执行主体并不构成对本申请的限定，为了便于描述，本申请实施例均以执行主体是服务器为例进行说明。

图1中的过程可以包括以下步骤：

s101：根据预定的、包含一个或多个风险因子的风险控制规则和/或风险控制模型，在各所述风险因子中，确定与业务的风险控制决策结果对应的风险因子，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的。

在本申请实施例中，所述业务可以指“一笔业务”，针对每笔业务都可以分别执行一次图1中的过程。

在本申请实施例中，可以基于风险控制规则和/或风险控制模型，对业务进行风险控制，获得风险控制决策结果，其中，风险控制规则一般是由风险控制模型执行的，风险控制模型本身也可以包含有风险控制规则。在实际应用中，可以将风险控制规则、风险控制模型作为一个整体看待，并可以将这个整体称为：风险策略体系。

随着网络业务的日益复杂化，在对业务进行风险控制时，单一的风险行为刻画已难以精准地防控风险，因此，目前的风险控制规则在某些简单场景下虽然也可以是单一的行为特征，但在更多的场景下是多种行为特征的组合。对业务进行风险控制的过程，即是对该业务的各行为特征(可通过该业务的相关数据提取)与风险控制规则的各行为特征，分别对应匹配的过程，进而可以根据匹配结果进行决策，以确定风险控制决策结果。

进一步地，每种行为特征可以分别用一个风险因子进行概括。在这种情况下，风险控制规则可以包含有一个或多个风险因子，相应地，可以将风险控制规则拆解为一个或多个风险因子。类似地，风险控制模型也可以包含有一个或多个风险因子。

在本申请实施例中，涉及所述对应的风险因子的所述业务数据可以指：属于该业务的、反映该风险因子对应的行为特征的数据。风险控制决策结果可以 对应于一个或多个风险因子，其中，若业务的风险控制决策结果是由属于该业务的、反映某个或某几个风险因子对应的行为特征导致的，则可以称：该风险控制决策结果对应于所述某个或某几个风险因子。

业务的风险决策结果具体可以包括：拒绝该业务、或通过该业务、或对该业务进行人工审核，等等。

s102：确定与所述对应的风险因子对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致所述风险控制决策结果的原因。

由于不同的风险因子分别对应不同的行为特征，因此，对于对应于不同风险因子的风险决策结果，用于解释导致风险决策结果的风险信息相应地也可以不同。

如上所述，可以据此预先建立风险因子与风险信息之间的对应关系。具体的，在本申请实施例中，可以预先分别为每个风险因子构建一个对应的风险信息集合。风险信息集合中可以包含细化程度不同的多级风险信息，该风险信息集合对应的风险因子也即：该风险信息集合包含的多级风险信息对应的风险因子。

需要说明的是，本申请中所述的风险信息集合中包含多级风险信息，具体含义可以是：该多级风险信息已经构建完毕，并存放与该风险信息集合中；或者，该多级风险信息虽然尚未构建完毕，但是，用于构建该多级风险信息的素材已经在风险信息集合中准备就绪，当要输出该多级风险信息时，可以根据这些素材实时地构建出该多级风险信息，再输出。

在本申请实施例中，多级风险信息具体可以是多个层级的风险信息，所述多个层级的风险信息可以是逐层进行细化的。例如，顶层的风险信息是宏观的、笼统的，次层的风险信息是对顶层的风险信息进一步的细化(具体地解释，和/或扩充部分新内容等)，以此类推，除了顶层的风险信息以外，以下每层的风险信息都可以是对上一层风险信息进一步的细化。

当然，所述多个层级的风险信息也可以不具有“逐层细化”的关联关系。例如，可以是相对独立地构建各个层级的风险信息的，在这种情况下，并不一定要基于上一层风险信息构建本层的风险信息。

在本申请实施例中，对多级风险信息层级的划分可以是根据历史风险控制经验，和/或业务的所属方的需求等进行的。不同业务可以有不同的划分方式，本申请对多级风险信息层级的具体划分方式并不做限定。

s103：根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息。

在本申请实施例中，业务的所属方的风险信息需求等级可以用于表征：该业务的所属方的风险信息需求程度和/或深度。

在实际应用中，业务的所属方的风险信息需求等级可以由服务器根据历史数据推定，也可以由该业务的所属方指定等。前一种方式可以减少业务的所属方的操作，便利性较高；后一种方式由于是直接采用的所属方自身的意见，因此准确性较高。本申请对所述风险信息需求的等级具体数量和等级具体划分方式并不做限定。

在本申请实施例中，业务的不同所属方的风险信息需求等级可能不同，相应地，可以分别向所述不同所属方输出对应层级的风险信息，以分别适应不同所属方的需求。

进一步地，对于多级风险信息，每个风险信息需求等级可以唯一匹配该多级风险信息中的其中一级风险信息，也可以同时匹配该多级风险信息中的其中两级甚至更多级风险信息。

s104：输出所述确定的风险信息，以便于所述业务的所属方获得所述确定的风险信息。

在本申请实施例中，可以将确定的风险信息直接输出给业务的所属方；也可以将该风险信息输出给其他设备或功能模块，再由其他设备或功能模块将该 风险信息发送给业务的所属方；还可以先保存该风险信息，被动地等待业务的所属方查询后，再输出该风险信息；等等。

在本申请实施例中，风险控制决策结果、以及为该风险控制决策结果确定的风险信息可以由同一个设备输出，也可以分别由不同设备输出，本申请对此并不做限定。进一步地，本申请对该风险控制决策结果和该风险信息的输出时刻与输出先后顺序也不做限定，一般地，可以在输出该风险控制决策结果时，一并输出该风险信息，如此可以便于业务的所属方及时知晓导致该风险控制决策结果的原因。

通过上述方法，可以针对每个风险因子，构建对应于该风险因子的、细化程度不同的多级风险信息，以适应业务的不同所属方对于风险信息需求的不同层级的需求程度和/或深度，并且可以用不同的风险信息需求等级，表征对于风险信息需求的不同层级的需求程度和/或深度，进而，在输出风险信息时，可以根据业务的所属方的风险信息需求等级，在多级风险信息中，确定并输出细化程度与业务的所属方的风险信息需求等级匹配的至少一级风险信息，以便于业务的所属方获得输出的风险信息，因此，本申请的方案输出的风险信息对于业务的不同所属方的适用性较好，可以部分或全部地解决上述现有技术中的问题。

基于上述方法，本申请实施例还提供了上述方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，如前所述，风险控制规则和/或风险控制模型包含的每个风险因子可以分别与预定的一个风险信息集合建立有对应关系。在这种情况下，对于步骤s102，确定与所述对应的风险因子对应的风险信息集合，具体可以包括：根据所述对应关系，在预定的各所述风险信息集合中，确定与所述对应的风险因子对应的风险信息集合。

当然，也可以不预先构建风险信息集合，而是在要使用时再实时地构建。在这种情况下，对于步骤s102，确定与所述对应的风险因子对应的风险信息 集合，具体可以包括：根据所述对应的风险因子，构建与所述对应的风险因子对应的风险信息集合。

在本申请实施例中，在执行步骤s103的过程中，用到了业务的所属方的风险信息需求等级信息，为了便于实施本申请的方案，下面提供两种获得该风险信息需求等级信息的方式，作为示例：

第一种方式，可以预先由业务的所属方指定自己的风险信息需求等级，或者，由服务器指定业务的所属方的风险信息需求等级；然后将指定的风险信息需求等级信息写入预定配置文件中。则在执行步骤s103前，可以从该预定配置文件中读取到该风险需求等级信息。第一种方式可以减少业务的所属方的操作，便利性较高。

第二种方式，可以在要执行步骤s103时，再实时地由服务器推定业务的所属方的风险信息需求等级。具体地，服务器可以根据获取的所述业务的所属方的风险控制水平信息和/或风险控制需求信息，推定所述业务的所属方的风险信息需求等级。第二种方式由于参考了业务的所属方的相关信息，因此，准确性较高。

需要说明的是，本申请对风险控制水平信息和/或风险控制需求信息的获取方式并不做限定，可以是由服务器在与业务的所属方的历史交互过程中采集的，也可以是由服务器侧的管理人员通过与业务的所属方进行的沟通获知，并输入服务器的，等等。

在本申请实施例中，对于步骤s104，前面已经给出了若干实施方式。在实际应用中，比较常见的一种实施方式如下：

输出所述确定的风险信息，具体可以包括：在所述风险控制决策结果输出给所述业务的所属方时，向所述业务的所属方输出所述确定的风险信息。这种实施方式的优点是：业务的所属方可以在看到风险控制决策结果时，相对同步地看到对应的风险信息，业务的所属方的体验较好，便于根据该风险信息，有方向性地对业务进行后续处理，比如，去除风险后重新提交业务等。

“多级风险信息”、“风险信息需求等级”均是本申请的方案的重点之一，为了便于理解，在此分别对它们进一步地说明。

在本申请实施例中，所述业务的所属方的风险信息需求等级是预定的多个风险信息需求等级之一，用于表征所述业务的所属方的风险信息需求程度和/或深度。所述多个风险信息需求等级可以与所述多级风险信息一一对应并匹配，且表征风险信息需求程度和/或深度越高的风险信息需求等级，在所述多级风险信息中匹配的那一级风险信息的细化程度可以越高。

以所述业务是支付业务，该支付业务的所属方是该支付业务对应的商户为例。其中，所述支付业务可以主要基于第三方支付平台进行，也可以主要基于银行提供的支付平台进行。

可以将支付业务场景下的所有商户划分为三类，风险信息需求程度和/或深度相对低的一类称为：“弱管控商户”；风险信息需求程度和/或深度相对适中的一类称为：“一般管控商户”；风险信息需求程度和/或深度相对高的一类称为：“强管控商户”。

相应地，多级风险信息具体可以是三个层级的风险信息，在输出风险信息时，若业务的所属方是弱管控商户，则可以输出细化程度最低的那个层级的风险信息，若该所属方是一般管控商户，则可以输出细化程度适中的那个层级的风险信息，若该所属方是强管控商户，则可以输出细化程度最高的那个层级的风险信息。

在本申请实施例中，多级风险信息可以是根据所述风险控制规则和/或风险控制模型，以及相关的历史风险控制经验数据构建，以及以易于所述业务的所属方理解的描述方式进行描述的。

历史风险控制经验可以包括服务器在针对历史业务的风险控制过程中总结出的经验，以及业务的所属方提供的现成可用的经验等。例如，服务器可以根据业务的所属方已提供的信息，推定该所属方或与该所属方相似的其他所属方所需求的风险信息，以及什么样的风险信息是易于该所属方或与该所属方相 似的其他所属方理解的；业务的所属方也可以主动告知服务器自己需要怎样的风险信息，以及自己容易理解的风险信息描述方式等；这些数据都可以作为历史风险控制经验数据。

所述风险信息可以是程序代码形式的信息，也可以是自然语言形式的信息。现有技术中对风险控制规则进行简单翻译就作为风险信息，而本申请的方案可以根据历史风险控制经验，以通俗易懂的语言描述风险信息，以易于业务的所属方理解，因此，基于本申请的方案输出的风险信息适用性更好。

本申请实施例提供了在一种针对支付业务的风险控制场景下，为各风险因子构建的风险信息集合示意图，如图2、图3组合所示。其中，图2和图3分别为该风险信息集合示意图的一部分，图2中“盗卡风险”的各子节点是在图3中示出的。

在该场景下，将风险信息称为“风险信息提示编码(infocode)”，将为各风险因子构建的风险信息集合合称为“infocode体系”。需要说明的是，这两个名称仅是一种示例，并不构成对本申请的限定，在其他的场景，也可以用其他的名称命名。

在图2、图3中是以一个树形结构表示该infocode体系的，“风险信息提示编码体系”节点是该树形结构的根节点。在该树形结构的第二层一共有4个分支，每一个分支下分别是一个infocode集合，这些infocode集合分别为：“盗卡风险”节点内容及其所有子节点内容构成的集合、“盗账户风险”节点内容及其所有子节点内容构成的集合、“可信体系”节点内容及其所有子节点内容构成的集合、“银行系统拒绝”节点内容及其所有子节点内容构成的集合。

每个infocode集合分别对应于一个风险因子(风险因子省略未示出)，每个infocode集合包含多级infocode，从树形结构的第二层开始往下，每一层分别是多级infocode中的其中一级infocode，越往下的infocode的细化程度越高。

以“盗卡风险”节点所属的infocode集合为例，在图3中可以看见，该infocode集合包含有三级infocode。第一级infocode包括“盗卡风险”节点内 容；第二级infocode包括“高风险账户”、“信息冲突”、“高风险环境”、“风险网络”、“高危事件属性”、“异常行为路径”、“速率”这7个节点内容。

可以看到，第二级infocode是对第一级infocode的进一步细化；类似地，第三级infocode是对第二级infocode的进一步细化，比如，第二级infocode中的“高风险账户”节点内容被细化为第三级infocode中的“新账户”、“休眠账户”、“情报完成度”、“账户登录时存在批量行为”这4个节点内容，第二级infocode中的“信息冲突”节点内容被细化为第三级infocode中的“交易信息存在冲突”、“信用卡验证信息冲突”这2个节点内容，等等。

从图2、图3可以看出，细化程度越高的infocode可以越具体地解释导致风险控制决策结果的原因。

需要说明的是，图2、图3中的节点内容可能并未完全示出，而且图2、图3仅是对多级infocode的示例而已，并不构成对本申请的限定。

上面对本申请实施例提供的风险信息输出方法进行了详细说明，基于同样的思路，本申请实施例还提供了一种风险信息构建方法。

图4为该风险信息构建方法的过程，该过程的执行主体可以与图1中的过程的执行主体相同，在此不赘述。

图4中的过程可以包括以下步骤：

s401：对预定的风险控制规则和/或风险控制模型进行拆解，获得所述风险控制规则和/或风险控制模型包含的一个或多个风险因子。

s402：分别为获得的各所述风险因子构建一个对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致业务的风险控制决策结果的原因，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

以便于在所述风险控制决策结果输出时，根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定并向所述业务的所属方输出细化程 度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息。

通过图4中的方法，输出的风险信息对于业务的不同所属方的适用性较好，可以部分或全部地解决上述现有技术中的问题。

基于同样的思路，本申请实施例还提供一种针对支付业务的风险控制场景下，用于输出风险信息的infocode分级输出模块的结构示意图，如图5所示。

图5中的模块主要可以分为三个部分：

第一部分，infocode框架，用于根据支付业务平台的历史风险控制经验数据，构建infocode三层框架。多级风险信息即是基于该infocode三层框架构建的。

第二部分，infocode映射。这里的“映射”主要风险控制规则和/或风险控制模块包含的各风险因子(即：风险因子1、风险因子2、…、风险因子x)与各风险信息集合(即：infocodea、infocodeb、…、infocodex)之间的对应关系映射。

其中，每个风险信息集合都包含有对应的多级风险信息，比如，infocodea包含了codea1、codea2、codea3这三级逐级细化的风险信息。

第三部分，infocode输出。用于将多级风险信息分级输出给风险信息需求等级匹配的业务的所属方。

其中，风险信息需求等级一共有三个级别，即为：弱管控商户的级别、一般管控商户的级别、强管控商户的级别。其中，弱管控商户可以是无风险控制能力或不关注风险控制的小商户或新商户，一般管控商户可以是有一定风险控制能力，但无专业风险控制团队的中小型商户，强管控商户可以是有较强风险控制能力、已组建专业风险控制团队的大中型商户。

在实际应用中，服务器可以实时地分析每笔支付业务，在结合风险控制规则和风险控制模型给出“拒绝该业务”或“通过该业务”等风险控制决策结果时，也可以将对应级别的infocode输出给该业务的所属方。

进一步地，本申请实施例还提供了一种针对支付业务的风险控制场景下， infocode三层框架示例图，如图6所示。

在图6中，采用的风险控制规则称为“新账户冲突换多卡”，其可以拆解为“新账户”、“冲突”、“换多卡”这3个风险因子。

每个风险因子分别对应于一个infocode集合，风险因子可以从更为细化的维度进行刻画，进而可以构建出三级infocode，三级infocode即构成一个infocode集合。例如，“冲突”存在盗卡和盗账户风险(可作为第一级infocode)，进一步地，盗卡风险可以分为卡bin冲突、设备冲突等类型(可作为第二级infocode)，更进一步地，卡bin冲突可以分为发卡国与ip国冲突、发卡国与收货国冲突等(可作为第三级infocode)。

基于图5、图6中的方案，可以有效增强支付业务平台与商户的良性互动，提升支付风险控制体验。

需要说明的是，在以上各例中均是以“一共有三级的多级风险信息”作为“多级风险信息”的示例的，在实际应用中，多级风险信息也可以共有两级，或者共有三级以上，等等。另外，本申请的方案可以针对全部风险因子实施，也可以只针对部分风险因子实施。

以上为本申请实施例提供的风险信息输出方法、风险信息构建方法，基于同样的思路，本申请实施例还提供相应的风险信息输出装置、风险信息构建装置，如图7、图8所示。

图7为本申请实施例提供的对应于图1的风险信息输出装置结构示意图，具体包括：

风险因子确定模块701，用于根据预定的、包含一个或多个风险因子的风险控制规则和/或风险控制模型，在各所述风险因子中，确定与业务的风险控制决策结果对应的风险因子，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

风险信息第一确定模块702，用于确定与所述对应的风险因子对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述 风险信息用于解释导致所述风险控制决策结果的原因；

风险信息第二确定模块703，用于根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息；

风险信息输出模块704，用于输出所述确定的风险信息，以便于所述业务的所属方获得所述确定的风险信息。

可选地，所述风险控制规则和/或风险控制模型包含的每个风险因子分别与预定的一个风险信息集合建立有对应关系；

风险信息第一确定模块702具体用于：根据所述对应关系，在预定的各所述风险信息集合中，确定与所述对应的风险因子对应的风险信息集合。

可选地，所述装置还包括：

风险信息需求等级确定模块705，用于在风险信息第二确定模块703确定细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息前，确定预定配置文件中指定的所述业务的所属方的风险信息需求等级；或者，根据获取的所述业务的所属方的风险控制水平信息和/或风险控制需求信息，推定所述业务的所属方的风险信息需求等级。

可选地，风险信息输出模块704具体用于：在所述风险控制决策结果输出给所述业务的所属方时，向所述业务的所属方输出所述确定的风险信息。

可选地，所述业务的所属方的风险信息需求等级是预定的多个风险信息需求等级之一，用于表征所述业务的所属方的风险信息需求程度和/或深度；

所述多个风险信息需求等级与所述多级风险信息一一对应并匹配，且表征风险信息需求程度和/或深度越高的风险信息需求等级，在所述多级风险信息中匹配的那一级风险信息的细化程度越高。

可选地，所述多级风险信息是根据所述风险控制规则和/或风险控制模型，以及相关的历史风险控制经验数据构建，以及以易于所述业务的所属方理解的描述方式进行描述的。

可选地，所述业务的风险控制决策结果包括：拒绝所述业务、或通过所述业务、或需对所述业务进行人工审核。

可选地，所述业务包括支付业务，所述业务的所属方包括所述支付业务对应的商户。

图7中的装置具体可以位于服务器或终端上。

图8为本申请实施例提供的对应于图4的风险信息构建装置结构示意图，具体包括：

风险因子获得模块801，用于对预定的风险控制规则和/或风险控制模型进行拆解，获得所述风险控制规则和/或风险控制模型包含的一个或多个风险因子；

风险信息构建模块802，用于分别为获得的各所述风险因子构建一个对应的风险信息集合，所述对应的风险信息集合包含细化程度不同的多级风险信息，所述风险信息用于解释导致业务的风险控制决策结果的原因，所述风险控制决策结果是根据所述风险控制规则和/或风险控制模型，以及涉及所述对应的风险因子的所述业务数据确定的；

以便于在所述风险控制决策结果输出时，根据所述业务的所属方的风险信息需求等级，在所述多级风险信息中，确定并向所述业务的所属方输出细化程度与所述业务的所属方的风险信息需求等级匹配的至少一级风险信息。

图8中的装置具体可以位于服务器或终端上。

需要说明的是，本申请提供的装置是与本申请提供的方法一一对应的，因此，所述装置也具有与所述方法类似的有益技术效果，由于上面已经对所述方法的有益技术效果进行了详细说明，因此，这里不再赘述所述装置的有益技术效果。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包 含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

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

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

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。