前言
所谓的风险识别，主要是针对企业在运营过程中对于面向互联网的业务，可能由于运营人员的不规范操作，或系统本身存在漏洞，或业务规则存在漏洞，或被攻击，被褥羊毛等行为产生的损失。而风险识别就是为了能够快速发现、控制上述等行为的发生，尽可能的降低损失。
本文将针对近些年来我们在日常的业务经营中发现的一些比较常见的风险事件进行梳理，并分享一些所采取的应对措施。
重点关注业务
首先，先针对几类重点业务风险类型做一个简单的划分，具体如下：
账号类：系统账号一方面对于黑产来说往往是后续一系列其他套取利益的前提，另一方面也是盗号者侵害他人利益的首选方式，因此对于账号的管理实际上是非常重要且必要的。
常见的与账号有关的风险行为有：
- 大量注册账号进行囤积，以便后续大批量使用；
- 发现系统注册漏洞或注册信息验证不充分，导致通过虚假信息方式注册的行为；
- 弱密码导致被账号被盗用，并引起一系列不良行为，如：资金损失，信息被篡改，权限被篡改，账号被拿到其他可利用的场景使用等行为；
- 账号的登录行为异常，如同一设备或IP出现多个不同账号登录或一个账号被不同的设备登录。
- 撞库风险，如果不采取任何限制，用户可以通过系统返回的某些信息来作出判断，比如如果提示账号不对，则说明改账号不存在，如果提示密码不对，则说明账号是存在的，只是密码不对而已。
运营类：运营类的大多数问题，主要是由于企业运营管理人员操作导致，通常运营管理人员的账号权限也比较大，因此这类账号一旦被盗，将会对系统造成严重的安全隐患，因此很多关键的操作通常都需要进行二次审核。
相关的风险行为有：
- 商品价格配置错误
- 广告配置错误
- 活动配置错误
- 利用职位便利，帮助获得低价或活动参与，或其他客户信息等以此牟取利益。
- 其他各类可能外露的信息，由于未经审核而带来的潜在影响。
营销类：这一类主要就是针对营销活动而来的，也是被黑产重点关注的一项。常见的有优惠券领取、商品秒杀、营销活动参与等。一旦被黑产发现某些漏洞，则会迅速的通过之前囤积的大量账号而占用大量的活动资源，从而给正常的营销活动造成影响。
相关的风险行为有：
- 由于没有事先设置金额的上限，而导致营销金额超预期。
- 营销的目标用户超预期。
- 单用户的某个活动参与次数超阈值。
- 单用户的某个优惠金额使用出现异常。
- 礼品卡、券、积分、返利、现金等发放异常。
- 利用标签类享受特殊待遇。
- 活动留后门参与。
交易类：交易类和营销类有点类似，都是通过不断的测试来找到系统漏洞而获利。比如某种条件下会出现结算金额计算错误，某种条件下会出现优惠券不核销等等。除此之外，通过平台交易也是常见的用来完成洗钱的方式之一。
相关的风险行为有：
- 结算费用过高或过低。
- 结算优惠的金额过高。
- 短时间内频繁产生交易或取消交易。
- 交易存在时空上的异常。
充值类：这是洗钱、诈骗、套利、圈钱等非法资金入口的重点关照对象，是整个黑产获利的环节中非常重要的一部分。
相关的风险行为有：
- 大额充值、小额充值
- 频繁充值、退款
- 同一账户频繁收到多种不同来源（IP、设备、付款用户等）的入账资金
- 通过诱导被骗用户跳转我方收银台完成支付，完成诈骗。
- 参与充值活动、或其他类似支付类活动，获得相关活动利益后就退款，尤其是三方合作类，以此获取利益。
思想策略
系统风控主要是根据事先定义好的一些规则、策略来实施，在必要的链路上通过埋点上报等方式监测数据是否达到了设定的阈值，或对产生的数据进行阶段性的分析，以此来发现问题。
要完成上述的管控，通常我们会在事件产生的前、中、后三个阶段分别作出相应的策略。
- 事前：该阶段通常指的是在系统产生数据之前能采取的一些措施，起到提前阻断的作用。
比如当发现运营人员配置的商品价格经计算后高于某个阈值时，可以给出警告，让其二次确认或触发其他流程；当发券金额超过一定阈值时，当授信额度超过一定阈值时，当某个活动的用户影响范围超过一定阈值时，等诸如此类的场景，必须要经过二次审核；
该阶段主要是通过系统流程上的约束来减少人为犯错或故意破坏的可能。
- 事中：我们当然不能期望流程约束、系统规则能防范住所有问题，很多风险本身就来源于业务行为的过程之中。
比如某个营销活动中，我们规定每人只能领取一张优惠券，但却有人领到了多张；规定一笔交易最多优惠 10 元，但却发现结算单中优惠金额超过 10 元；某人1分钟前还在A点消费，下1分钟就在B点消费了等。
针对此类问题通常就需要我们有能力对实时产生的业务数据进行分析，并采取适当的干预（诸如短信验证、身份验证等等），及时止损。
- 事后：无论是事前还是事中，前提都是你已经知道了可能存在的风险项再对此做出应对策略，而事后阶段往往是针对未知风险而进行的，通过大量的数据分析与对比，将可疑的信息提取出来，再完善风险识别的规则，最后通过事前或事中阶段进行控制。
处理手段
- 注册事件
以注册事件为例，早期时注册信息可上报埋点作为后续特征提取指标，当制定出明确的风控规则之后，业务系统即可直接请求风险识别系统，风险识别系统依据账号注册事件的策略规则返回相关风险等级，业务系统再根据不同的风险等级返回给客户端对应的结果响应。
关键信息
| 字段 | 描述 |
|---|---|
| 账号 ID | 用于标识用户唯一身份的 ID |
| 手机号 | 国内三大运营商11位手机号 |
| 用户昵称 | |
| 用户姓名 | |
| 归属城市 | 用户定位所在城市，或用户手机号归属城市 |
| IP | 客户端请求 IP |
| 设备指纹 | 识别设备的唯一 ID |
| userAgent | HTTP请求头部包含的User-Agent字段信息。 |
| refer | HTTP请求头部包含的referer字段信息。 |
| APP 版本号 | |
| 注册来源 | - PC |
- H5
- APP
- 小程序 | | 来源 id | 注册来源唯一用于标识用户身份的 ID | | 设备类型 | - PC
- MOBILE | | 注册时间 | |
实时处理
- 支付事件
| 字段 | 描述 |
|---|---|
| 平台用户ID | |
| 商户订单号 | 由商户自己生成，商户自己保证不重复 |
| 支付订单号 | 完成交易申请成功后，由服务端返回给商户 |
| 支付交易类型 | 支付宝、微信、银联等 |
| 支付交易状态 | 交易创建，待付款；未付款，交易超时；支付成功；转入退款 |
| 交易时间 | |
| 支付完成时间 | |
| 交易金额 | |
| 订单描述 | 展示给买家的信息 |
| appid | 商户在各个支付平台的ID |
| 买家ID | 如买家的支付宝账号、微信的openid等 |
| 用户的客户端IP | |
| 订单附加信息 | 用于回传给商户服务端使用 |
| 订单超时时间 | 在此时间之前未完成交易的订单将被关闭 |
| 交易优惠信息 | 订单优惠的信息，商户的优惠，支付平台的优惠。 |
除此之外，还有交易、登录、优惠券领取、文本内容等场景都可采取类似处置方式。
小结
风控系统的构建目标要覆盖到全业务的全场景中，要对各个环节中的潜在风险点进行监控，并有能力在必要时进行干预、控制，确保业务的正常运营与健康发展。
当然，如果早期阶段业务规模还不是很庞大，也可以先多以'事前、事后'的方式。事前，首先是要提升系统与业务风险安全的意识，很多事情不是因为没有能力去做，而是根本就没想去做。事后，可以对已产生的数据进行定时采集，还可以每日对数据进行汇总后进行分析与比对。实际上，大多数场景也并不一定要做到实时的处理，前期只要能有发现的能力以及发现后控制的手段即可，相比之下晚一点发现倒也没那么重要。
总之，安全风控系统一定是一个先完成，再逐步完善的过程，也是过一个多方博弈的过程，千万不要一开始就去追求完美。