以下PPT材料来自于本人在公司内部的技术分享
一、风控定义
1.1 风险控制
风控，风险控制。
风险控制：指风险管理者采取各种措施和方法,消灭或减少风险事件发生的各种可能性,或者减少风险事件发生时造成的损失。金融的核心是风险控制。
定义很明确。找到风险事件，然后控制它发生或者发生造成的损失。
那么，什么事件是风险的？风险控制的控制，到底是什么？
拆开看，风险，和 ，控制。
1.2 风险
风险：指在某一特定环境下，在某一特定时间段内，某种损失发生的可能性。换句话说，是在某一个特定时间段里，人们所期望达到的目标与实际出现的结果之间产生的距离称之为风险。
风险有两种定义：
一种定义强调了风险表现为不确定性；
而另一种定义则强调风险表现为损失的不确定性。
若风险表现为不确定性，说明风险产生的结果可能带来损失、获利或是无损失也无获利，属于广义风险，金融风险属于此类。而风险表现为损失的不确定性，说明风险只能表现出损失，没有从风险中获利的可能性，属于狭义风险。
1.3 控制
控制：控制主体按照给定的条件和目标，对控制客体施加影响的过程和行为。
构成控制活动必须有三个条件：
- 要有明确的目的或目标，没有目的或目标就无所谓控制；
- 受控客体必须具有多种发展可能性，如果事物发展的未来方向和结果是唯一的、确定的，就谈不上控制；
- 控制主体可以在被控客体的多种发展可能性中通过一定的手段进行选择，如果这种选择不成立，控制也就无法实现。
1.4 总结
风险，期望目标和现实结果的差距（这个差距，其实就是事务不确定性，毕竟理想很丰满，现实很骨感）。清楚的定义这个差距度量，就可以量化风险。
控制，就是通过施加一些手段，靠近我们期待的目标。手段，例如，事前准入，事中监控处置，事后追偿等。
二、风控核心业务
明确了风控的核心定义之后，价值在哪里？围绕着定义，找到风控业务最核心的本质，然后围绕这个本质，去构造和规划核心业务能力。
那么，风控业务的核心本质是什么？风险，还是控制？我认为都不是，或者说还是太上层了，本质是目标，目标，目标！！从风险的定义，和 控制的定义，都可以发现，有个重复的词，就是目标。因此，整个风控业务是围绕的 目标 产生的。
在定义中，我们说，现实和目标之间是存在距离的，这个距离我们称之为风险。比如，我们的目标是使用信贷业务的用户，100%都是好人，都会按时还款；但是，现实世界肯定存在坏人，肯定有不按时还钱，或者压根就跑路不还钱的；那么，这两者差异，就是风险，如何最小化或者最合理话风险，就是控制了。
但是，一款产品，大的层面来讲，他的风险目标，好像很明确。但是，当我们去量化，去落地，发现并没有那么简单。例如，上面讲好人，是对这个用户未来行为的预测，怎么判断他是个好人呢？这就是挑战！！！此外，对于一款产品，上面说的是风险目标，但实际上，一款产品的目标，很多时候是营收，例如，其会存在针对不同风险用户，使用不同定价，然后做最大化利润，这个时候，目标的刻画就更复杂了。
先来分析业务产品的风险目标。风险的定义是不确定性，也就是说，如果明确一个东西不会变，那么就不存在风险，也就不需要去刻画。一款业务产品，存在不确定性的，是什么？相关利益方，也就是 参与业务的用户（商家，用户，机构 等）。（可能还有人说，存在市场变动，经济危机等不确定性，一般而言，我们不太会涉及过深，一般通过黑名单、行业类目等粗粒度控制）
那么，业务的风险目标的本质，就可以简化为，业务参与方 未来一直 都是好用户。
接下来，就是如何刻画 好用户（或者说，坏用户）。一般的方式，算法对用户风险进行建模，产出各种维度的分值；或者风控策略同学，根据专家经验写一些规则，产出好坏结果，或者风险级别，分值等。对应的业务系统应该具备的核心能力，就是模型引擎能力，规则引擎能力。
然后我们发现，不管是模型，还是规则，一般在实时判断决策的时候，都需要大量的过去或者当前的指标数据进行支持，因此，还需要具备强大的，指标能力。
因此，这一步，我们发现，风控系统，应该具备的产品能力如下：
现在，我们有了最核心的能力，找到了目标。然后，围绕目标，开始做风险和控制了。有了目标，去实现风险，就很简单。再看风险定义，某一段时间内，目标和现实的差距。时间段，一般我们会拆成三部分，开始（事前），进行中（事中），结束（事后）。
也就是说，我们需要关注业务活动开始时，两者差距；业务活动进行中，两者差距；业务结束时，两者差距。
开始时，一般称为是准入风险决策。业务进行中，一般称为事中风险监控。结束时，如果存在风险，则称为事后风险追偿。
因此，我们可以在不同的时间段，将当前活动对象的指标数据和目标数据进行计算，获取风险值，或者风险结果。因此，应该具备的产品能力变化为：
再来看，控制。控制，是通过一些手段，缩小预期目标和现实结果的差距，不断靠近预期目标。
例如，我们在事前准入阶段，预期判断一个用户未来会存在违约行为时，不允许该用户享受某款产品服务。在用户运行进入服务过程中，可能会存在准入判断不准确，或者一些外部环境、国家政策等导致的现实和预期目标的差距变大时，会进行一些处罚动作的执行。如果以上手段都未能控制风险，则进行事后追偿阶段，需要进行一些补偿措施，尽量减少风险，或者说风险导致的损失。
因此，我们将原来的产品能力进行扩充：
以上，风控基础产品能力，已经完成了。
下面，我们对最基础的产品能力，进行不断分解，然后进行合并抽象。
2.1 事前准入决策
准入决策，主要是判断一个用户是否可以享受产品服务，通过限制风险用户进入服务中，来控制整体风险敞口。此外，在事前过程也可以通过风险准入和定价来多维度控制风险，这块有2.4细说，
准入决策，对外提供风险决策能力，返回给业务方该风险事件是否存在风险。
对准入决策功能进行细分，然后抽象之后，我们发现，准入决策系统，主要包括以下几个方面（目前准入决策承接两块业务，业务的准入决策，以及风控的风险决策）：
- 统一的接入能力。风控为各种业务场景提供统一的决策能力，通过统一的接口，路由到对应的决策规则，返回决策结果。
- 产品化输出能力。对于准入，接入方后端接入一个接口，前端直接对接组件，不需要复杂重复的开发工作；风险决策这块，规则引擎会有大量的详细规则命中输出，但是由于安全性，以及业务方接入成本，需要对决策结果进行配置化信息输出；
- 接入配置化。以后台配置的方式来管理接入的业务，减少重复的无价值的开发工作；
- 数据可视化。
2.2 事中风险监控
和事前准入决策不同，事中风控，主要在于主动监听业务变动，或者各种风险因子的变动，做一些处置动作。
因此，对于事中风险监控，主要的功能是 风险因子的变动监控，处置功能的编排和执行。
这里，我们将监控和处置独立开，两种产品能力里面，风险监控主要是观察各个可能影响风险系数的因子变动，或者根据外部其他渠道的风险事件数据，进行重新分析本业务域的风险情况。而处置产品能力，主要在于确认风险之后，需要执行对应的风险控制手段，避免风险损失的扩大。
事中监控，主要包括：
- 风险因子变动监控：对于核心风险因素，并且变动之后，可能会带来较大风险变化的事件，一般采用实时消息模式监听，然后判断对应业务风险结果；其他情况，则采用定时周期型的任务方案，对全量或者增量数据执行跑批，更新最终风险决策结果。
- 联动风险监控：金融风控并行的，还有其他风控业务，以及治理业务线等，这些业务线的处罚动作等，都可以提供给金融风控业务，作为一个很重要的风险数据源。
- 异常事件分析处置：各种异常情况的人工分析，然后进行处理；以及一些风险判断后的处置动作，需要人工介入。也就是，不能通过系统规则模式直接执行处置结果的情况下，需要进行分析处置模块。
处置通知能力，主要是在判断各种风险之后，会联动进行处置。
- 处置能力；
- 通知能力；
- 人工审核；
2.3 事后风险追偿
目前事后，主要是做一些赔付和追偿操作。主要包括：
- 对被保护方，在服务受损时，进行赔付动作；
- 对服务主体，目前主要是商家，启动追偿操作。
和通常的风控不同的地方，在于金融风控的主要业务对象是金融，因此，还需要重点设计金融业务相关的风险业务。
2.4 授信&风险定价
我们新增风险定价部分的产品能力，对外主要提供授信签约、授信决策，以及 授信定价部分，其他主要是渠道路由和场景接入的管理。
2.5 总结
因此，我们可以得出整体的风控业务架构：
这里，认为风控引擎和指标服务，是内部技术体系，对于业务架构而言，不在其内进行设计。
三、风控核心技术
技术，服务于业务。所以，根据业务的简单架构图，我们给出对应的系统架构：
和业务架构基本保持一致，事后追偿这块，主要是审核系统完成。风控主要提供两大产品服务，支撑外部业务。
我们应用上，按照业务架构，很清晰明确的来划分不同的限界上下文。
核心域：
- 风险决策子域：围绕这 风险事件 领域来展开，包括风险事件请求和风险事件配置信息两部分。直接依赖 风控引擎通用域能力，审核 通用域能力，完成请求接口的返回。
- 授信额度子域：围绕这 授信 领域来展开，包括授信签约、授信准入、授信额度、授信定价 等4个子领域模型。除了依赖 风控引擎通用域能力，审核 通用域能力 之外，还会依赖 授信渠道支撑子域能力。
- 事中监控子域：围绕这 监控 领域来展开，包括 实时事件监听、周期任务跑批监控、异常事件处置 等3个部分。除了依赖 风控引擎通用域能力 之外，还会依赖 风险处置 支撑子域能力
- ……
通用域和支撑域：风控引擎子域，数据特征子域、审核系统子域；风险处置子域、数据分析子域。
以上系统模块，就可以完整支撑业务的运转。梳理完支撑业务需要的系统能力之后，接下来，来聊聊风控核心两大模块，风控引擎，和 指标服务。
3.1 风控引擎系统
当前风控决策引擎系统，还存在一些不足。下面，主要是介绍未来整体规划架构：
3.2 数据能力-指标中心
先看特征中心对外提供的能力：
特征中心，最核心的能力，就是对外提供批量指标查询。目前指标特征，主要分为4部分：实时计算指标，离线指标，三方外采特征，二方内部特征。
从上图可以看出来，指标都是自生产，采取读写分离模式。生产统一抽象是两部分，一部分是数据预计算，然后直接查询存储设备；另一部分是数据实时查询，对特征中心而言，socket网络流，就是其存储设备。（系统代码层面，都是在基础设施层交互层面来完成。）
然后，看下特征中心架构：
架构化之后，分为 接入层，能力层，存储层，运营层。能力层，是核心，主要是 指标生产和指标查询。查询主要分为：元数据和各种配置信息加载和请求预处理；对请求数据进行路由到各个指标特征模块进行数据查询；获取结果进行处理或者异常场景的降级操作等。
运营层，在整个特征中心非常重要。数据指标的配置化，低代码化，都是基于运营配置的完整功能下完成的。主要涉及：各层级模型管理；各种脚本根据配置来自动化生成；最后查询的特征元数据配置、对外接口配置 以及 对外需要的流水账单数据。
特别说明。在指标生产中，涉及到数据的质量治理：数据正确性核对，以及 数据的修正。尤其是实时计算指标，数据的修正，非常需要。上游的任务数据修复，由于flink时间窗口的限制，需要对数据进行修正。细节不详细介绍。
最后，看下数据架构：
数据的分层，是为了数据的复用和统一。数据平台化或者中台化，最核心的目标，就是数据模型的统一和复用，从而提升数据指标的加工效率，以及口径的统一。
四、 低代码化的风险决策演进
决策系统接入的演进！代码编码接入，→ 配置化维度，→ 产品化组件维度 ，→ 解决方案维度
五、 全景化的风险数据运营
数据分析，未来风险运营的核心能力支撑，通过数据驱动风险运营和风险管理。
数据可视化：运营策略维度，业务产品维度，系统开发维度。（以下可视化大盘图来自网上，主要是数据监控思想上的体现）
六、研发下阶段
