如果把业务平台比喻为一颗树，那么需要投入足够的养分才能快速生长，而业务风险则是寄生于树木窃取养分的角色，只有充分抵御这种风险，才能成长为参天大树。这就是业务风险在平台发展中扮演的角色。

在大部分场景下，风控意味着阻断用户操作，在大部分人眼里与用户体验是背道而驰的存在。单就电商领域而言，竞争逐渐白热化，用户体验成为了吸引用户的重要因素，此时风控如何在尽可能不打扰到用户的情况下，能阻断尽可能多的恶意行为？这是一场善与恶的博弈，也是关乎生死存亡的博弈。 

为实现用户体验与风控需要的平衡，行业内有一个著名的原则：轻管控、重检测、快响应。怎么来理解这个原则呢？

轻管控：在出现风险，需要阻断用户操作时，阻断动作宜轻不宜重。能验证码校验就不短信校验，能短信校验就不禁访。每一步都需要照顾用户感受。看似简单，其实背后涉及到对用户风控行为以及对用户风控阻断动作的分层管理。

重检测：通过尽可能多的获取用户信息（包括静态及动态数据），由规则引擎进行实时或离线计算，来动态分析每个用户及采取行为的风险程度。这里需要尽量全的数据来源，以及非常强大的规则引擎，才可以实现良好的检测效果。

快响应：是指在检测出用户存在的风险后，如何进行快速阻挡。这里的重点是快，意味着对业务的理解要细，提前在关键动作进行布局，才可以做到尽可能减少损失。

了解了原则，再跟大家聊一聊业务风控的业务模型设计~

个人认为，业务风控的业务模型主要分为六层，分别为数据输入层、数据计算层、数据输出层、运营管控层、业务接入层以及用户触达层。

这六层侧重的点也各有不同，下面为大家简单说明：

 一 数据输入层 

如何获取数据？获取什么数据？数据准确性如何？

这是数据输入层需要解决的三个问题。

★ 获取数据方式

目前获取数据主要有两种方式，一种是主动获取，一种是被动获取。主动方式是自己去业务方数据库、日志里面去读，这样可以拿到最全的信息，而不用依赖消息报等被处理过的二手数据。被动方式就是提供接口给业务研发，让业务把消息按格式标准传过来。这种配合周期非常长，但成本较低，可以按照标准来拿到高质量的信息，所以是比较常见的风控系统搭建方式。

★ 获取数据种类

鉴于目前大部分公司都采用第二种方式，因此与业务方如何合作，获取高质量的数据就很重要了。对数据种类的要求是能全就全，能深就深。

以注册登录行为为例对数据详细程度进行深入：

基础的登陆注册数据，就可以从频率、登陆注册特征来进行分析；

进一步拿到登录注册行为的上下文，比如登陆前访问了哪些页面，登陆后去访问了什么，就可以从访问行为轨迹来增加更多的分析维度，例如页面停留时间，是否有访问到必访问的页面；

用户的操作行为数据，比如鼠标移动的轨迹、键盘输入，进一步从操作过程来增加分析维度，比如是不是输入密码的时候有过多次输入删除？是不是直接复制粘贴的账号密码？

★ 如何保证获得数据的准确性

对采集回来的数据必须定期的对数据质量进行监控——已经采集到的数据可能因为技术架构调整，代码更新等各类奇葩原因造成采集回来的数据不准了，如果无法及时发现可能造成后面一系列分析过程都出现错误。

采集点尽量选择稳定的业务点，比如采集登录日志，一次性在公共服务采集好，后面出现问题只要找一个点。但如果是去前端从WEB、移动端等各个调用登录服务的点去采集，出了问题要改动的工作就会成倍增加，还有可能出现新业务点的日志无法覆盖的情况。

数据输入原则：

宜早不宜晚，宜全不宜少；

数据分层处理：实时数据与离线数据分离。实时数据接入需要评估RT时间及准备一旦被降级的预案。

 二 数据计算层 

数据计算层是由各种规则、模型等算法形成的计算核心，一般都依附在一个强大的规则引擎之上。

为什么采用规则引擎？因为黑产的反应速度实在太快了。如果把风控规则都硬编码进业务代码中，那一旦规则被绕过，反应速度就会非常慢。规则引擎必须能把策略逻辑从业务逻辑中解藕出来，让防御者可以灵活配置规则在静默模式下验证和实时上线生效，并可以去随时调整。

虽然说数据技术层主要是研发和算法同学处理的，但作为产品可以做的，除了了解基本的规则、模型及实现原理外，还可以增加对规则的生命周期及健康度的评估，比如：

风控系统的规则有多少？

哪些已经很久没有触发了？

产生误判投诉的对应规则有哪些？

一个新规则在建立起初的效果肯定是最有效的（因为这时风险问题正在发生，而规则正好对应了风险），但随着时间其有效性是快速下降的，比如攻击者都知道网站三次输入密码错误触发验证码，那么他们会傻傻的尝试第三次猜测密码的概率有多大？

那么是否有人在定期的去统计分析这些规则的效率就是风控产品的重要运营环节了，而运营风控产品所要付出的代价是往往大于常规互联网业务产品的，并且是保证项目能够持续产出价值并不断迭代进化的一个前提。

 三 数据输出层 

数据输出层是将数据计算层的计算结果转化为可以被下游使用的分数，主要的输出为用户的风险画像、风险分数及风险等级。

数据输出层主要的原则是数据可读性高（因为会直接被运营及下游业务方消费，需要降低使用方的使用成本，提高效率）以及可复用性（一个输出的数据，可以在多个场景下被使用。比如垃圾注册的数据可以同时被反欺诈，反作弊等场景使用）。

 四 运营管控层 

如果说上面三层主要靠技术的手段来实现风险管控，那么运营管控层主要是靠人为经验来对技术尚无法处理的风险进行管控。

技术尚无法进行处理的风险主要分为两种，一是样本较少，计算准确度不足，然而危害较大的风险行为，比如金融盗卡、诈骗等；二是人为、非机器行为的风险行为，比如工作室层次的大量人工刷单等。

以上两种都是需要运营的经验来进行判断会更为合理。同时运营层的处理结果也会反馈到数据输出层，优化数据输出的准确性，也有利于为算法及模型提供较为准确的样本进行学习。

 五 业务接入层 

风控的业务模型是环环相扣的，在已经具备了数据处理能力以及运营后台之后，如果没有业务方接入，那相当于只有内功而无法出拳，这样就只是风控内部的自娱自乐，无法为业务保驾护航。在风控与业务技术的合作中，一切要以业务为重，因此在风控合作中，需要注意：尽可能避免给业务带来不必要的麻烦。

如何做到与业务进行良好的合作，主要从4点出发：

★ 呈现给业务研发直白的判定结果

我们最终从数据中发现的报警和问题最终是要在业务逻辑中去阻拦的，在接入这些结果的时候，往往分析师觉得可以提供的信息有很多，比如命中了什么规则、这些规则是什么、什么时候命中的、什么时候过期，一个code list给他们说明对应希望做的操作，一定把中间结果等等包装成最终结果再给出去。

★ 实时与离线计算分离，降低业务系统压力

因为T＋0在接入的时候要额外承担很多计算成本，结果要现场算出来而延时要求又很高，所以一般都只在攻击者得手关键步骤采取实时判断（比如订单支付或者提现请求）。而对于其他场景可以选择T＋1方式，比如登录或者提交订单等。

★ 超时及降级预案准备

风控风险判断的最基本原则就是要不影响业务逻辑，所以超时机制在一开始就要严格约定并执行，一旦发现风控接口超过预计响应时间立马放行业务请求。

★ 充分关注业务流量

平时可能流量很小的业务，突然因为某个活动（比如秒杀）流量大增，除了在接入之初要对风险判断请求有了解，对后续的活动也要提前准备，否则如果资源预估不足，突然又赶上这个点接了T+0接口有很多要现场计算的逻辑，那业务分分钟会把风控降级。

 六 用户触达层 

风控的用户触达，主要包括各种C端的安全中心、安全组件以及多样的风控阻断操作。在这一层，需要做的是细化管控手段，以及重视用户体验。

★ 细化管控手段

风控管控手段需要丰富，包括图形验证码，语音验证码，实名校验，touchid校验，密保问题，禁访，禁买，禁言等，在不同场景下，采取对应的方式，而不是千遍一律。千遍一律的话，太轻会导致管控效果不佳，太重的话会极大影响用户体验。

★ 重视用户体验

这点说起来容易做起来难。在获客成本高昂的今天，假设获客成本是100块，他可能因为被风控之后，文案警告的简单粗暴，缺少申诉出口或者流程难以继续而选择用脚投票，从而离开。

而这些是产品可以做的事情，使用提醒式而非警告式的文案；在被风控后及时提示用户后续的操作；与客服同学加强沟通（任何风控准确率都不是100%的，所以在和研发沟通好接入后一定要告诉一线同事们风控阻断可能出现的表象（文案提示）以及大致的原因，以避免一线客服们对风险拦截的投诉不知道如何解释，并给出具体的阻断回复措施（CRM后台增加白名单、删除黑名单权限等等））都是可以有效提高用户体验的方法。

来源 | 金融科技安全VX公号

专注金融科技安全领域，分享有价值的行业风控干货，多角度洞察行业热点，发布最新行业安全资讯。

免责声明：转载内容仅供读者参考。如您认为本公众号的内容对您的知识产权造成了侵权，请立即告知，我们将在第一时间核实并处理。