个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
参考
交易事件及其生命周期
交易事件就是交易，如：登录、注册、转账等，而且这些还只是大类，通常转账有手机号转账、银行卡号转账等，币种又有人民币、外币、数字人民币等，这只是从方式、币种区分，其实还有很多，而且流程是相对复杂的。
以下仅是随意的例子，不可深究。
要在转账中加入风控一定也是了解转账的整体流程的。
从风控业务的角度出发，接入风控的交易数据就可以称为交易事件🤝
虽然说是这么说，风控的接入要熟悉整个交易流程，但是为了简化，其实是可以把所有交易分为事前事中事后的。
事前事中事后风控
来一波AI的介绍吧
事前风控（Preventive Risk Control）
事前风控是指在风险事件发生之前所采取的预防措施。这一阶段的目的是尽可能减少风险发生的概率和影响。事前风控的重点在于预测和准备，包括：
- 风险识别与评估：识别可能面临的风险类型，评估其发生的可能性及潜在影响。
- 制定策略与规则：根据风险评估结果，制定风险控制策略和规则，如信用审批标准、交易限额等。
- 建立预警系统：设置预警指标和阈值，以便在风险指标接近危险水平时提前警告。
- 培训与教育：对员工进行风险管理培训，提高其风险意识和处理能力。
- 合规性审查：确保所有操作遵循相关的法律法规和行业准则。
事中风控（In-process Risk Control）
事中风控是在风险事件正在发生或业务活动正在进行时实施的控制措施。这一阶段的目标是实时监测风险，及时干预以减轻风险影响。事中风控的特点包括：
- 实时监控：利用数据和分析工具，对关键指标进行实时监测，以识别异常或潜在风险。
- 动态调整：根据实时数据调整策略，如调整信用额度、暂停可疑交易等。
- 快速响应：一旦检测到风险，立即启动应急计划，采取行动阻止风险扩大。
- 沟通与协调：确保信息流通，及时与相关部门沟通，协同应对风险。
事后风控（Post-event Risk Control）
事后风控是在风险事件发生后采取的控制和恢复措施。这一阶段关注的是评估风险影响，学习经验教训，防止未来再次发生类似风险。事后风控包括：
- 事件分析：详细分析风险事件的原因、过程和后果，确定责任归属。
- 损失评估：量化风险事件造成的财务和非财务损失。
- 整改与改进：根据事件分析结果，制定整改措施，优化现有风控体系。
- 学习与培训：总结经验教训，对员工进行再培训，增强风险防范意识。
- 报告与反馈：编写事件报告，向上级管理部门汇报，并将结果反馈给相关部门，促进持续改进。
这三个阶段的风控措施相互关联，共同构成一个全面的风险管理体系。事前风控侧重于预防，事中风控强调实时反应，而事后风控则致力于从错误中学习并持续改进。在实际操作中，这三个阶段应该被看作是一个连续的闭环过程，而不是孤立的步骤。
事前、事中、事后风控（风险控制）是风险管理的三个重要阶段，每个阶段都有其独特的目标和实施策略，旨在识别、评估和减轻风险。
总结
事前本质上是交易发生前，这阶段要做的就是预防。建立审批标准流程、交易限额、设置预警阈值、宣贯培训都是预防手段。AI中已经讲了这三个阶段是相互关联、打配合的。
如：建立审批流程、设置交易限额、预警阈值，这些并不是凭空设置的，而是由事中、事后风控反馈而来的。就比如说，建立个人信用贷款审批标准流程，在0.1版本只需要查询个人征信记录就好，但是从后期接借贷表现，计算出要根据个人收入及其稳定程度，需要阶梯式设置不同的放款金额，这就是流程的配合，其后的表现应该是有完善的反馈机制，有助于流程的开展的。
如下表示交易发生的流程，不同列表示不同层级。
如果在这个流程中加入风控，可以有下面这样的示例图。
第一个开始与其过程表示事前流程，第二个开始表示交易流程，其通过一系列流程后在过程d进行风控，下面这部分表示风控系统，在风控系统内部再经过一系列流程，最终对交易事件进行决策，返回到过程d，而过程d可以执行也可以不执行决策，不进行决策就进行流程d原本的后面过程，进行决策的话，就会有通过或不通过等结果，而结果最终还是会反馈到风控系统，风控系统再经过一些流程反馈到事前流程中，如计算限额、信用额度等。这就是交易接入风控后的反馈机制的一种体现。
结果通知/回调
从前面交易接入风控来看，其实一笔交易是有割裂的，交易接入风控后，拿到了决策结果后执行后续流程，在后续流程中又需要接入风控，用于给予风控决策结果的结果和交易结果。什么意思呢？
交易结果表示当前交易的结果，说的完全是废话🙂↕️简单划分为成功和失败
成功：1、决策结果就是通过，交易也顺利进行下去了；2、决策并非通过，而是一种验证方式，但是验证通过并且交易顺利完成。
失败：1、决策结果直接结束，当风控系统认定风险过大就可以设定验证之上的决策，直接干预交易，如拒绝本次交易、锁定账户等；2、决策结果是某种验证方式，但是验证失败导致交易流程提前结束；3、决策结果是通过，但是因为某些异常，交易没能顺利完成。
这些结果对于风控系统是很重要的，因为这些数据本身就是交易流程中的重要数据，只有把这些数据也给到风控系统才能保证交易事件的完整性。才能构建起完善可靠的风控系统，如果有个用户突然使用非常用设备登录，而且人脸验证又连续失败3次，这应该有够可疑了吧！
割裂就表现在结果与事中事件分成两步与风控系统交互，所以一定要保证多笔交易可以对应起来。常用方法就是每笔交易都有唯一的交易流水号，风控系统在收到交易事件后首先根据交易事件本身的交易流水号生成唯一的交易事件ID，交易事件ID保证了风控系统中数据唯一性。
下面是一个简图，从风控系统数据的角度来看。
每笔交易事件在风控系统中对应一笔数据，数据包含交易系统字段（包含事件本身数据和扩展计算而来的数据，如：解析数据）、指标计算结果（针对的是当笔交易，其本身可能另有存储方式）、决策链路（因为风控系统的灵活性和实时性，在调整了风控规则和链路后实时生效，所以两笔时间相近的交易可能对应着不用的决策链路）、结果（表示当笔交易命中的策略集、策略、规则，规则又可分为正式规则和模拟规则，模拟规则用于新规则的过渡，调用方可区分使用）。这些数据都是事中交易就可产生的，交易结果是交易事件数据的补充，作为交易结果此时进行决策也没有意义，总不能对于一笔已完成（不管成功失败都算是已完成）的交易再决策吧。
所以通知有两种区分，1、将其划分为不同交易；2、同笔交易，结果通知。
如图，第一个开始表示分为不同交易时的通用流程，所有交易都需要校验、入参处理、策略、规则、决策流程，也是因此，事中是需要指标计算和决策等完整流程的，但是作为结果虽然不需要决策，但是还是要进行指标计算的；第二个开始表示同笔交易时，结果通知，事中还是保留所有完整流程，但是结果已经简化了流程，加入了关联事中交易、减去了决策流程。
举个例子，一笔交易有a：A向B转账的事中风控流程，b：A向B转账的结果。
将a、b作为两笔不同交易，设置规则时就要注意不能重复累积和多余的决策计算。因为b本身就是a的结果，所以大多数数据都和a保持一致，如金额、账户这些总不能改变。那么要设置一个金额求和指标时就是区分了。指标A向B转账金额求和，计算的就是b结果成功的交易金额之和，而不是a的金额之和，因为a与b成功的关系永远是大于等于。而且前面也讲了既然b是结果，那么其决策没有意义，所有不用决策，但是还是要计算指标的。不同交易优点就是流程相对统一，复杂在于指标和规则的设置上，缺点是数据和计算的冗余。同笔交易的优点是节省数据空间，简化指标规则配置，缺点就是设计上要多花一些心思。
以下从同笔交易来说明结果通知的交互方式。1、交易结果被动通知，由交易系统发起，将交易结果送给风控系统；2、风控系统主动回调获取交易结果。正好对应着Push和Pull。
以下引用AI。
主动回调
主动回调是指接收方需要定期或在特定时机向发送方请求操作的结果或状态，以获取最新的信息。通知的接收方主动地（pull）信息，通常通过以下方式实现：
- 定期轮询: 接收方定期发送请求，询问操作的结果或状态。例如，每隔一段时间或在特定事件触发时发送请求。
- 条件触发: 在特定条件满足时（如用户登录、页面加载完成等），接收方发送请求获取最新的数据。
- API调用: 接收方通过调用API获取数据或状态信息，根据操作结果进行后续处理。
特点是接收方需要主动发起请求，以获取操作结果或状态更新。这种方式，实时性可能稍逊一筹，但适用于一些不需要即时通知的场景，同时能够控制请求频率和资源消耗。
被动通知
被动通知是指系统或服务在完成操作后，向事先指定的目标发送通知，无需接收方发出请求。通知的发送方推动（push）消息给接收方，通常通过以下方式实现：
- 实时通知: 在操作完成或事件发生后，系统即时向事先注册的接收方发送通知，通知内容可以包括操作结果、状态更新等。
- 即时推送: 使用实时通信协议（如WebSocket）或推送通知服务（如Firebase Cloud Messaging、Apple Push Notification Service），确保通知能够即刻到达接收方。
- 数据推送: 将操作结果或状态变更直接推送给接收方，通常通过API调用或异步消息队列实现。
优势在于实时性强，接收方无需轮询或定期检查操作状态，而是在操作完成后立即得到通知。
写在最后
拙作艰辛，字句心血，望诸君垂青，多予支持，不胜感激。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
433
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
