3、风险识别与分类：合规风险源分析、风险分类体系

好，咱们进入第三个实操环节。风险识别与分类，说白了就是搞清楚两件事：风险从哪来，以及它属于哪一类。这一步做不好，后面的预警模型全是空中楼阁。我见过太多团队，一上来就搞机器学习、搞大数据，结果连风险源都没摸清楚，最后系统跑出来的全是噪音。

嗯，咱们一步步来。

3.1 合规风险源分析：先找到“雷”在哪

风险源分析，我习惯把它分成三个维度去挖：

• 内部流程：制度有没有漏洞？流程有没有断点？
• 外部环境：监管政策变了没？行业潜规则是什么？
• 人员行为：员工有没有越权？有没有利益冲突？

举个例子。我在做某银行的反洗钱系统时，发现大量预警都是“客户身份信息不完整”。一开始大家以为是系统对接问题，后来一查，其实是柜员为了冲业绩，故意跳过了一些必填字段。你看，这就是典型的人员行为风险源。

我个人常用的方法是“五问法”。比如：

1. 这个风险事件第一次出现是什么时候？
2. 触发它的直接动作是什么？
3. 这个动作背后有没有制度缺失？
4. 同行业有没有类似案例？
5. 如果现在不改，三个月后会发生什么？

你想想看，问完这五轮，风险源基本就浮出水面了。

3.2 风险分类体系：给风险贴标签

找到风险源之后，就要分类。分类不是为了好看，而是为了差异化应对。不同类别的风险，预警阈值、响应流程、责任部门都不一样。

我一般把合规风险分成三大类：

风险类别	典型场景	预警信号
操作风险	系统宕机、数据录入错误、流程违规	交易失败率上升、操作日志异常
法律风险	合同条款违规、知识产权侵权、监管处罚	法务退回率增加、监管问询函
声誉风险	负面舆情、客户投诉、媒体曝光	社交媒体负面提及量激增

这里要注意，风险类别不是互斥的。一个事件可能同时触发操作风险和声誉风险。比如数据泄露，既是操作失误，又会引发舆论危机。所以分类体系要支持“多标签”，而不是单选。

3.3 风险分类的落地：从理论到代码

光说理论不行，咱们看看代码里怎么落地。下面是我在一个项目中用过的风险分类引擎核心逻辑：

# 风险分类引擎示例（Python伪代码）
def classify_risk(event):
    # 规则1：如果涉及系统故障或人为失误 -> 操作风险
    if event.has_keyword(['系统宕机', '数据错误', '操作违规']):
        risk_type = '操作风险'
        confidence = 0.8
    # 规则2：如果涉及合同、法规、监管 -> 法律风险
    elif event.has_keyword(['合同违约', '监管处罚', '诉讼']):
        risk_type = '法律风险'
        confidence = 0.9
    # 规则3：如果涉及公众舆论、客户投诉 -> 声誉风险
    elif event.has_keyword(['负面舆情', '投诉', '媒体曝光']):
        risk_type = '声誉风险'
        confidence = 0.7
    else:
        risk_type = '待分类'
        confidence = 0.3

    return {'type': risk_type, 'confidence': confidence}

嗯，这里要强调一下：分类规则一定要可配置。监管政策三天两头变，你总不能每次改代码吧？我习惯把规则存到数据库里，运营人员可以直接在后台调整关键词和权重。

3.4 知识体系总览：一张图说清楚

下面这张图是我自己梳理的，把风险识别与分类的整个逻辑串起来了。你仔细看看，应该能秒懂。

你看，从风险源分析到风险识别，再到风险分类，最后输出结果。这三个环节不是一次性的，而是持续迭代的。监管政策一变，风险源可能就变了，分类规则也得跟着调。

3.5 实操中的几个坑

• 别把分类搞得太细。我见过有人分了20多个子类，结果每个子类下面只有两三个事件，统计意义都没有。三类到五类足够了。
• 别忽略“其他”类别。总有一些风险是规则覆盖不到的，留一个“待分类”的兜底，定期人工审核。
• 分类规则要可回溯。每次分类结果都要记录是哪个规则触发的，方便后续优化。我习惯在数据库里加一个 rule_id 字段。