前言

市场上的规则决策引擎产品众多，但大多局限于IP、设备、账号等层面，提供的是现成的风控标签和规则。然而，真正的风控，需要的不仅仅是标签和规则。

极验的业务规则决策引擎与众不同，这款决策引擎以界面流程编排为优先设计，为核心，对各种外部数据进行计算、查询、阈值比较和规则触发通知的整体编排。它不仅仅能做到市场上其他产品能做到的，还能做到市场上其他产品做不到的，并协助客户完成初期的规则搭建工作，逐步引导客户熟悉运营流程，直至他们能够轻松驾驭并自主运营。

我们将从以下几个角度来展示它的特点。

别人做到的，我们可以做

目前绝大部分市场上的规则决策引擎产品，都是从IP、设备、账号等层面输出风控标签、画像和已经设置好的聚合运算规则。

而要想做好风控，通常要根据业务场景、历史数据和风险容忍度进行定制化。毕竟规则再多，也可以穷尽，而当下的业务在变、技术在变、对手在变。风控从来都是持续的对抗，持续的变化，而不是一劳永逸的过程。

我们的流程编排系统能够实现任意参数的访问控制，可以非常具体、灵活地描述在什么情况下规则应当被触发（例如，表达式可以定义设备关联账号数的具体数值，或者特定时间段内的行为模式）。

具体到某个范围触发某条规则

如果把黑产对抗比作战场，这就相当于别人卖你的是各式各样的武器，而我们给你的是一个武器制作工厂，不仅能生成出各式各样的武器，你还可以根据你的需要，去定制生产你所需要的装备。

为了更好地说明以上情况，我们对市面上常见的规则决策引擎规则进行了盘点：

某规则决策引擎的风控规则合集

这些规则大致分为三类：

使用滑动窗口统计某一种模式(键)出现的频率。

使用滑动窗口统计某个分组键下另外某个维度去重的计数。

请求参数表达式逻辑判定。

以“使用滑动窗口统计某一种模式(键)出现的频率”为例，例如同设备 1天内关联账号数过多，其实就是典型的分组去重逻辑。系统会根据设备的唯一标识来进行分组，然后统计在 1天的时间窗口内与此设备关联的不同账号数量。如果同一账号多次尝试登录，通常只会计作一次。

我们很容易在我们的流程编排上去实现这个需求：

Step1、拖拽自定义模组至流程

拖拽需要的模块进入流程

Step2、编辑参数形成规则

可以应用任何参数进入频率计算

Step3、编辑完成

一个账号、IP、设备ID，在某段时间内出现频次规则

Step4、开始运行

应用在整个规则判断流程

别人做不到的，我们可以做

在业务决策引擎的流程中，都离不开输入、计算、输出这三个环节，想象一下，你是一家快递分拣中心的负责人，你的任务是确保每个包裹从到达的那一刻起，就立刻被分类并送往正确的目的地。包裹（数据）一到达（输入），就立刻被处理并送往下一个目的地（输出结果）。

在这三个流程中，为了满足更多客户的需求，我们在各个环节都做了相当多的创新。

规则决策抽象出来的三要素

一）在输入环节

我们支持多样化的自定义数据接入方式。不仅限于传统的本地数据库，我们还扩展了对外部API调用的支持。例如，金融行业可以通过外部征信查询接口获取数据，电商公司则可以接入物流公司的API来实时追踪包裹状态。此外，我们还能够高效处理实时数据流，如Kafka、RabbitMQ等消息队列系统，确保数据的即时性和准确性。

二）在计算环节

我们采用了硬实时处理机制，确保数据一经输入便立即进行运算并输出结果，以满足特定行业和场景对系统响应速度的极高要求。

常规的流式计算框架，如Spark Streaming和Flink，虽然能够处理实时数据，但在维持计算状态时可能导致程序不稳定，恢复困难。此外，这些框架通常需要将计算结果与数据库进行周期性同步，导致结果呈现异步性。这对于业务规则决策引擎（BRDE）来说是一个重大缺陷，因为它需要实时同步计算结果以参与流程编排，而异步结果会造成语义上的损失。

与此同时，另一种常见的流式计算方法是通过消息队列消费数据，并利用Redis保存状态（如HyperLogLog或Set），这种方法减轻了流程序的状态管理负担，提高了系统的稳定性和可恢复性。然而，这种方式在面对黑产等不确定请求时，可能会因热点数据难以预测而给Redis数据库带来极大的不稳定性。

举个例子，这就像一个自动传送带系统，厨师做好菜后放在传送带上，直接送到顾客手中。这个系统减轻了厨师的工作量，但如果很多顾客同时点同一道菜，传送带可能会因为某道菜（热点数据）过多而卡住，影响整个餐厅的运作。

正因如此，许多决策引擎产品未能将计算过程直观展示于界面。我们的决策引擎则不同，我们强调计算的透明度和可监控性，特别设计了计算过程的可视化功能。这样，用户能够更深入地理解、监控和管理计算活动，不仅提升了用户体验，还增强了系统的可维护性和可解释性。

计算过程的可视化

我们采用的BRDE在线计算方案，通过haproxy的stick table实现了滑动窗口的去重运算。此运算基于当前事件时间，例如，若当前时间为2024-11-11T22:49:00，则统计周期为2024-11-10T22:49:00至2024-11-11T22:49:00，以此完成去重运算，并与流程编排相结合，实现实时计算结果的返回，以供后续运算使用。

以一个具体场景为例，假设我们设定一个电商平台的预警条件为最近10分钟内订单量超过1000笔。传统的统计方法可能会在17:50至18:00这个固定时间窗口内进行计算。然而，如果订单激增实际上发生在17:55至18:05这一时段，那么依赖固定时间窗口的传统大数据统计将会出现明显的边界效应，分开看17:50至18:00和18:00至18:10，散落在2个时间窗口，都是正常的， 但实际最近17:55至18:05这10分钟的窗口是异常的，但逃离了这个频率项制定的范围。

相较之下，我们的实时数据处理技术采用动态的、连续滚动的时间范围来进行数据聚合，通过多次覆盖数据，有效减少了边界效应，并能捕捉到更细微的变化。一旦达到预警阈值便迅速采取行动。正如常言所说，预防优于治疗，实时止损的效果远优于事后的补救措施。

以某电子商务平台为例，若商品价格设置失误导致偏低，可能会引发消费者在极短时间内的大量抢购，瞬间销量可能高达数万件。但是，传统的预警系统只能在统计周期结束后才发出警报，这意味着我们只能在获取统计结果后才开始采取止损措施，从而错过了最佳干预时机。相较之下，极验业务决策引擎提供一体化的流程编排，还提供了高性能的实时算子。因此，一旦损失濒临预警阈值，系统即可迅速触发警报，显著提升了风险管理的效率和有效性。

同时，极验业务决策引擎提供了极高的灵活性，允许在计算前后进行按需过滤和实时计算。同时，haproxy作为计算引擎，在我们极验的基准测试中，在8核16GB的机器上展现出了高达20万QPS的计算性能，确保了系统的高效运行。

三）在输出环节

在规则触发后，相较于其他规则引擎仅输出风险标签（如高信用风险、低欺诈风险等），我们的系统更加注重实际业务场景的后续处理。虽然标签是风险处理的一个重要指标，但它并不代表风险的完全解决。

因此，我们的业务决策引擎允许用户采取进一步行动，如要求用户进行二次验证或直接限制设备登录，以防范账户盗用和欺诈行为，确保风险得到有效控制。

发邮件或者短信通知

请求、节点和响应

我们助力客户平滑过渡

当然，规则设置并非没有成本。它不仅需要人力运营，而且对专业知识有较高的门槛。

然而，极验凭借十二年的安全SaaS服务经验和成熟的客户成功团队，我们拥有对各行各业业务风控场景的深入理解。基于这些理解，我们不仅能够提供标准化接入售后服务，还能根据客户的具体需求设置定制化的风控规则。这不仅能够帮助客户更好地适应和应对各种业务挑战，还能减少他们的运营成本，降低知识门槛，使他们能够更专注于自己的核心业务。

立即注册试用：https://www.geetest.com/brde