智能风控系统搭建1

　　这几个月一直待业在家。疫情的原因思索了一下过往。参与了3家公司不同领域的风控系统的设计。从前到后把风控系统所以环境都细细思索。感觉还是刚刚入门而已。
　　公众号的大部分粉丝都是大厂的精英或者优秀的创业者及部分学生。
　　大多数人做风控意识非常迷茫。未来要面对什么问题不可能都了解，当你做的每一个给你都得小心。因为你的一个不注意走错方向，可能在未来某一个阶段会被全盘推翻。这次某信就是一个很好的例子。
　　很多人问我什么会离开。其实在某一个时间自己的位置非常尴尬，问题解决不了，如果要修改就得面临极大的成本（时间成本与沟通成本）
　　当初我负责的业务安全风控。其实业务风控主要做四件事，
　　1。拿到尽可能多的数据
　　2。灵活的数据分析平台
　　3。对已知风险进行拦截
　　4。分析风险拦截的价值及优化策略
　　就那账号安全来说。拿到登陆注册的数据，我们可以通过特征频率访问路径键盘输入甚至是否复制粘贴的账号密码来分析维度，
　　但是风控关心的信息，信息业务可能并不是那么关心、类如IP地址、referer。
　　但这些信息的缺失可能造成很多策略没法做，所以在采集信息开始的时候就要有个明确的信息列表，一旦妥协了后面再去返工让研发加的话人家会记你一辈子。
　　我们获取数据分为2种。
　　1。主动
　　自己去数据库、日志里面去读。
　　这种方式实时性比较差，而且基本有什么拿什么，想加信息是比较难的，但不需要研发配合太多事情，适合喜欢自己动手丰衣足食的场景。
　　当然有些比较成熟的公司有自己的消息总线，风控可以去实时的订阅信息然后作为数据源进行分析，但这种对中小企业就不可能存在的，
　　2。被动获取
　　被动获取就是提供接口给研发，让业务把消息按格式标准发过来。
　　这种配合周期非常长，但可以按照标准来拿到高质量的信息，所以是比较常见的风控系统搭建方式。
　　当你的数据源稳定，就得让分析人员更快地去查询原始日志，
　　日志并不是简单地存下来，从风控分析的需求来看，通过IP、用户名、设备等维度在一个较长的跨度中搜索信息是非常高频的行为，同时还存在在特定类型日志，比如在订单日志或者支付日志中按特定条件搜索的需求。
　　而这些主要是为了能够让分析人员可以快速的还原风险，例如从客服那边得到了一个欺诈的案例，那么现在需要从日志中查询欺诈时间段内这个用户做了什么，这个过程如果有一个界面可以去做查询，显然比让分析人员用grep在一大堆文件中查询要快的多，并且学习门槛也要低得多。
　　如果在日志做过标准化的前提下，也可以进行后续的业务语言转译，将晦涩难懂的日志字段转化为普通员工都能看得懂的业务语言，也能极大的提升分析师在还原时阅读日志的速度。
　　例如在分析某个帐号被盗的时候，往往需要把被盗期间登录的IP地址和用户历史常用的IP地址进行比对，即使我们现在可以快速的对原始日志进行查询，筛选一个用户的所有历史登录IP并察看被盗IP在历史中出现的比例也是一个非常耗时的工作。
　　再比如我们的风控引擎在自动判断用户当前登录IP是否为常用IP时，如果每次都去原始日志里面查询聚合做计算也是一个非常费时费力的事。
　　那么，如果能预定义这些变量并提前计算好，就能为规则引擎和人工节省大量的时间了，而根据这些变量性质的不同，采取的计算方式也是不同的。我们有一个标准可以去辨别：频繁、对时效敏感的利用实时计算（比如访问频率、时间间隔）；而相对不频繁、对时效不敏感的利用定时计算（比如用户的常用IP、设备，即使少算短期内的登录记录，也不会受到太大影响）。
　　一个设计优雅的规则引擎是把分析师的经验决策和数据最终转化为风险输出的核心模块，首先说为什么需要规则引擎而不是选择硬编码逻辑
　　我无数次遇到过这种场景，一个上午刚刚上线的策略，没过1个小时，攻击者或者欺诈者就已经试出绕过策略的方法了，如果你的风险控制逻辑是硬编码，那么恭喜你，再走一遍开发测试发布流程。（前一段时间万顺叫车风控负责人交谈的时候他们就有这个坑）
　　快速响应是安全的生命线，无法想象还有比被攻击者胖揍48小时然后才反应过来
　　所以策略引擎必须能把策略逻辑从业务逻辑中解读出来，让防御者可以灵活配置规则在静默模式下验证和实时上线生效，并可以去随时调整。
　　类似的开源框架有很多，各有优劣，但如果需要降低学习曲线，必须进行一层包装（这里又是一个比较大的话题）。
　　分析平台设计的差，那么就只有设计者自己会用（甚至自己用得都不爽）
　　设计的好，你会发现处理投诉的客服、分析师都会很乐意来用你的分析平台为他们解决问题。