风控在任何一个公司都是比较神秘的存在，不仅线上很少分享，从安全角度讲也很少对外披露它的架构及设计。本人将就参与的风控建设谈谈风控的技术。（本文来源于本人内部分享PPT，仅从技术角度探讨风控体系建设，不涉及公司内部机密，限于篇幅，一些细节没能交待完整）
风控架构演进
经过1年多风控系统的建设，已经将公司内部风控系统从业务代码为主的风控架构改造为了平台化为主的2代架构，进而改造成为动态化及离线数据模型化的2.5代架构，正在向深度学习，在线数据模型的3代架构上演变。
不得不说，与阿里，腾讯，京东等大厂相比，公司的风控体系还相对比较薄弱，但在有限的资源下将整个体系建设推进到目前的程度已经比较满意。
技术架构
首先来看目前风控的技术架构，从业务及架构层面将风控划分为五大体系：分别是存储体系，识别体系，支撑体系，运营体系，数据计算体系。
其中存储体系包括hbase，mysql，redis，es，hive，实际上都利用了现有的框架或开源项目。
识别体系包括控制平台（控制系统，批处理系统，决策系统，总线系统），处罚平台（处罚系统），分析平台（规则系统，模型系统）， 数据平台（数据系统，运营数据系统）。
支撑体系主要是指后台配置系统。
运营体系主要是指风控运营系统，kibana报表系统。
数据计算体系主要指大数据及离线计算平台及基于其上的数据分析业务。
其调用关系如下图：
业务架构
其次，来看整个系统的业务架构。目前已经初步具备的
业务能力有，营销作弊，交易欺诈，登录注册防控，内容防控
数据模型能力有，用户画像及风险评级，关联反查，风险大盘，各类报表等
运营能力有，用户预警，商户预警，案件审核，综合信息查询
并且基于现有的数据，分类整理并形成了自身的数据资产，分别为名单类，用户类，设备类，环境类，位置类。
风控系统的性能表现
下图是生产环境压测效果，采用12000用户并发压测得到约8w TPS，平均响应时间为141ms，错误率在万分之五。
其中积累的有效请求达到1.7亿，数据量达8TB
风控系统建设的难点
灵活高效的接入：通常只有1周甚至更短时间，业务复杂多样；如何减少发版失误和事故
极短的响应时间：业务通常只给100ms，最多200ms的超时
并发吞吐要求高：接入业务较多，调用量大；有的业务用风控抵挡攻击
大量数据处理：数据量相对较大，如何有效利用；数据查询回溯要求较高
对抗升级：攻击者不停猜测内部规则；数据如何为对抗服务
大促稳定性：如何保证调用量增加后不宕机；如何在出问题情况下依然服务
下篇将针对这些难点一一详细描述如何去解决。
What else?
多租户及开放平台服务
由于公司内部有多个子公司都想通过风控系统去自行控制，因而将数据隔离的多租户就尤为重要了，对于不同的租户而言，使用的是同一个平台同一套系统，但是所有的界面，数据计算，报表都只会看到本租户下的数据，而不能越权到其他租户，多租户本质上是一种权限控制，但是相比权限，其隔离更深更彻底。
另外，由于风控积累数据及服务已经较多，许多外部系统都想共享风控的数据和服务，将风控的部分业务作为开放平台提供服务也是深化风控改造的重要步骤。
规则效能分析
对于规则的设定只能凭经验，规则到底定得好不好也需要有数据衡量，规则效能分析就是用来衡量规则有效性的手段。
基于神经网络的反欺诈
基于这篇论文，将每次session的点击序列输入RNN，提供适当风险样本，让其识别风险session《Session Based Fraud Detection》。反欺诈这方面可以做得更多，但是神经网络在可解释性方面太差，这种场合被控了申述时毫无反驳理由。不过不失为一个判断依据。
智能运维
对于线上系统，从智能运维到智能决策，从熔断到自愈，寄往于系统可以做到自动决策，某些问题自动修复。
TimeWheel算法
对于风控这种时效要求较高的应用，需要在请求时控制超时。通常，这种控制超时的方式是新起一个线程，通过控制线程的执行时间来控制超时，在大压力时，大量线程会给整个系统的CPU切换带来负担，能否只用一个线程控制所有超时的计算，这样一来，将大大减小线程数量，将CPU负载降低。
如下是一种称为Timewheel的算法，实际上是模仿TCP发送包之后用来计算超时的算法，试想，如果操作系统底层对每个tcp包都新建一个线程来计时，那操作系统早挂了。
觉得博主写的好的欢迎关注转发，谢谢