风控策略产品经理：金融风控的业务规则和策略模型（四）

这篇文章主要给大家介绍一下风控产品的系统架构，内容有点多，但是都是非常有用的，希望各位小伙伴能够耐心的看完。
风控产品系统架构

第一阶段

这个时候的风控服务将所有在线决策功能整合在一个系统内实现，包括规则判断、名单库、流量计算，而这些逻辑都基于数据库实现。

基于当时携程对风控的需求，系统以满足功能为主。
PM大白话去理解：

规则怎么判断？就是根据数据库记录大于、小于、等于等判断规则，接收到风险事件后获取流量值和规则进行比较，得到最终的风险判断；

名单库怎么判断？数据库维护黑白名单信息（属性类型、属性值、判断依据等），程序判断风险事件中的值是否命中名单。

第二阶段

然而，在上线运行一段时间后，随着携程业务的增长，风控系统的流量不断增加，基于SQL的流量统计耗时严重制约了系统的响应时间，因此优化改版。

那么怎么改呢？

由于主要性能瓶颈在于数据库实现的流量查询，这次优化主要方向就是优化流量查询的实现：在原来单个数据库的基础上，采用分库分表的方式均摊压力，以达到更快的响应时间和更高的吞吐量。

架构图如下：（下图）
这个阶段的版本比较重要。是为后面新版打了很关键的基础。

从特点来看：

更方便快捷的接入除了支付风险，业务的风险也需要风控支持；

更多的外部数据接入：用户信息、位置信息、UBT信息；

更丰富的规则逻辑：支持任意变量的规则判断，支持更多的判断逻辑；

更高的性能：流量10x的增长，响应时间不超过1秒；

编程语言的更新：携程推动公司内.net转java。

基于以上，才有了实时性的风控在线支撑，也就是3.0版本了。

下篇文章继续给大家介绍第三阶段，一定要好好理解哦，这些都是一些干货内容。赶紧去看看接下来的内容吧！

以上就是“风控策略产品经理：金融风控的业务规则和策略模型（四）”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站。