在前面三篇文章中，我们阐述了风险管控数智化升级的必要性，分析了DRP数据底座的建设路径，描绘了RCB风控大脑的架构。

DRP解决数据从哪里来的问题，RCB解决数据往哪里去的问题。但在这两者之间，有一个关键环节决定着整个体系是“智能化”还是“仅仅线上化”——那就是风险模型。

如果把RCB比作一个真正意义上的“大脑”，那么风险模型就是大脑中负责感知、判断和决策的神经网络。DRP提供了感官输入，规则引擎提供了基础反射，而风险模型则是那个能够识别复杂模式、预判未知风险、持续自我进化的核心智力。

没有风险模型，RCB最多算一个高级版的规则执行器，离“数智化”还有相当距离。

那么，什么是风险模型？它与穿透式监管中强调的“规则模型”是什么关系？它靠什么输入来运行，又产出什么来驱动管理？从业务场景出发，如何一步步设计出可落地的风险模型？

本文试图回答这些问题。

一、风险模型的概念、分类与来源

（一）什么是风险模型

风险模型并不是一个全新的概念。在金融领域，它已经经历了数十年的发展。银行业很早就用信用风险模型评估贷款违约概率，用市场风险模型计量投资组合的潜在损失，用操作风险模型识别内部流程中的漏洞。

这些模型有一个共同特征：它们将风险判断从专家的主观经验，转化为基于数据和算法的客观计算。

将这一理念引入更广泛的企业风险管理领域，我们可给出一个通用的定义：风险模型，是指基于数据驱动的方法，将业务规则、内控合规要求、风险判断逻辑或统计学习算法，转化为可被计算机系统自动执行的数学表达式或算法程序，用于识别、评估、预测和预警各类风险的智能工具。

这个定义，有两个关键点需要展开。

第一点是“数据驱动”。传统风险管理依赖制度文件和专家经验。制度规定“应该怎么做”，专家根据经验判断“哪里可能出问题”。但制度和经验都是静态的、滞后的。风险模型则建立在真实业务数据的基础上。合同履行数据、采购交易数据、资金支付数据、供应商行为数据。模型从这些数据中“学习”风险模式，而不是依赖某个人在某个时刻的直觉判断。

第二点是“可被计算机系统自动执行”。纸面上的风险矩阵、定性评分表不是模型，因为计算机无法读取它们、无法用它们对新交易做出判断。真正的风险模型必须部署到RCB等风控平台中，能够在业务发生的毫秒级时间内完成计算和判定。它不是在会议室里讨论的风险清单，而是在生产环境中持续运行的判断程序。

（二）风险模型的分类：规则模型与风险分析模型

在企业风控实践中，风险模型通常分为两大类：规则模型和风险分析模型。

两者在原理、适用场景、设计方法和维护方式上存在差异，但它们不是替代关系，而是互补关系。

规则模型，基于明确的业务规则和逻辑条件，将风险判定标准转化为系统可自动执行的条件表达式（如阈值比较、时间顺序判断、逻辑组合等），用于实时或准实时地识别、预警或阻断特定违规行为。

规则模型的基石是专家知识。业务分析师和风控专家将已知的风险模式抽象为一条条具体的规则。例如，“同一招标项目中，两家以上投标人的机器制作码相同，则判定为串通投标嫌疑”，“单笔付款超过100万元需经财务总监审批”。

规则模型的优点是执行效率高、判定结果确定性强、可解释性极强——每一次判定都可以追溯到触发它的具体条件和数值，这对于合规审计和责任追溯至关重要。

规则模型也有其局限性：它只能识别已经被明确定义过的风险模式。对于新型、隐蔽的风险形态，规则模型无能为力。而且当规则数量增加到成百上千条时，规则之间可能出现重叠、冲突甚至失效，维护成本急剧上升。

风险分析模型，是基于历史数据和统计学习算法（如逻辑回归、图神经网络等），挖掘数据中隐藏的风险模式和关联规律，用于评估风险概率、发现异常交易行为或预测未来风险趋势。

风险分析模型是典型的数据驱动模式。它不依赖于专家预先定义“什么是风险”，而是通过分析数以万计的正常案例和异常案例，自主挖掘出风险事件中隐藏的、非线性的复杂关联。

例如，它可能发现某些看似无害的行为组合——某供应商总是在周三下午提交报价、报价金额总是比第二名低3%左右、该采购项目的经办人近期与该供应商有间接社交关联——实际上是围标串标的早期信号。这些信号可能极其微弱且多维交织，人类专家几乎不可能事先想到。

风险分析模型的优势在于可以覆盖规则模型难以处理的复杂场景，并且具备持续学习的能力，能够适应新型风险形态。

其挑战在于：模型训练和优化过程较为复杂，初始构建周期较长；同时，某些复杂模型（如深度学习模型）存在“黑箱”问题，决策路径不如规则模型清晰，在强合规性场景中可能受到限制。

在实际风控体系中，两类模型通常配合使用。规则模型负责“已知的已知”风险——那些制度明确禁止、判断边界清晰的事项，用于实时拦截和高频校验。风险分析模型负责“未知的未知”风险——那些隐蔽、复杂、难以用固定规则描述的风险模式，用于深度扫描和异常发现。

（三）风险模型与穿透式监管中的“规则模型”

在国资委穿透式监管的文件中，出现一个与风险模型高度相关但又有所区分的术语——“规则模型”。

需要厘清两者的关系，因为这是很多企业法务合规人员在理解政策要求时容易混淆的地方。

国务院国资委在《关于做好2026年中央企业内部控制体系建设与监督工作有关事项的通知》中，明确要求“积极构建重点领域内控监管规则模型”。

这一表述将“规则模型”从技术概念提升到了政策要求的高度。

在穿透式监管的政策语境下，“规则模型”是一个比技术意义上的“规则模型”更为宽泛的概念。

它不仅指基于明确逻辑的规则判定，而是涵盖了整个智能风控体系：包括数据采集、模型分析（无论是规则模型还是机器学习模型）、预警触发、核查派单、整改跟踪的完整闭环。

也就是说，15号文中的“规则模型”，实际上是指“用于监管的智能化模型体系”，它既包含我们前面定义的基于业务规则的规则模型，也包含基于机器学习算法的分析模型，还包括与之配套的数据治理机制、预警处置流程、持续迭代方法等管理要素。

二、风险模型的输入与输出

理解了风险模型是什么之后，下一步就要回答：一个风险模型在系统中是如何运转的？它的输入是什么，输出又是什么？

（一）风险模型的输入

风险模型的输入，是经过DRP治理后的高质量数据。

DRP从各业务系统（采购、合同、财务、供应商管理等）采集原始数据，进行清洗、标准化、关联、质检后，以数据流或数据集的形式提供给RCB的规则与模型层。没有这个高质量的数据底座，任何风险模型都无法正常运行。

具体来说，输入数据可以分为以下几类：

第一类是业务交易数据。这是最基础、最核心的输入。例如，采购订单中的供应商名称、采购金额、采购品类；合同文本中的合同条款、签约方、合同金额、付款条件；付款申请中的收款账户、付款金额、付款时间；入库单和验收单中的货物数量、质量评价、验收日期。这些数据是企业经营活动的原始记录，是风险判断的基础素材。

第二类是财务数据。预算执行情况、成本数据、应收应付账款余额、资金流水等。财务数据往往最能反映业务的真实状况，是风险分析的重要维度。例如，一个供应商的付款周期突然大幅缩短，可能意味着关系异常；一个项目的预算执行率异常低，可能暗示进度滞后或虚报。

第三类是外部数据。供应商的工商注册信息、司法涉诉记录、行政处罚信息、舆情新闻、信用评级等。这类数据企业自身不产生，需要通过API接口或定期导入的方式接入DRP。外部数据对于识别供应商风险、合规风险尤为重要。

第四类是历史标注数据。这是训练风险分析模型所必需的。机器学习模型需要通过“正样本”（历史上确认的风险事件）和“负样本”（历史上确认的正常业务）来学习风险模式。历史数据的质量直接决定了模型的初始效果。如果企业过去对风险事件的记录不完整、不准确，训练出来的模型效果就会大打折扣。这也是为什么数智化升级需要与基础管理提升同步推进——模型再先进，也解决不了数据本身的问题。

第五类是规则配置数据。对于规则模型而言，输入还包括业务专家配置的规则表达式、阈值参数、风险等级映射等。这些配置数据决定了模型的行为逻辑。

（二）风险模型的输出

风险模型的输出，是驱动后续风控行动的信号。根据模型类型和应用场景的不同，输出形式多种多样，归为以下几类。

第一类是风险评分或风险等级。这是风险分析模型最常见的输出形式。模型对输入的业务数据计算出一个数值分数（如0到100分），然后根据预设的阈值映射为风险等级（如低风险、中风险、高风险、严重风险）。例如，一个供应商风险评分模型输出85分（满分100分），按照集团标准属于“高风险”，系统将自动标记该供应商为高风险供应商，在后续采购流程中触发额外审查。评分的优势在于精细、可排序，便于进行优先级管理和资源分配。

第二类是预警信号。无论是规则模型还是风险分析模型，最终都可能触发预警。预警信号通常包含以下信息：触发时间、触发规则/模型名称、风险等级、关联的业务单据（合同号、订单号、付款单号等）、风险描述的简要说明。预警信号推送至RCB的风险监测预警模块后，系统会根据风险等级和预设规则，自动确定责任人并推送通知。预警信号是连接“模型判断”和“管理行动”的桥梁。

第三类是判定结果。在某些强控制场景中，模型输出的是一个二值判定结果——“通过”或“阻断”。例如，资金支付合规性模型发现付款申请缺少必要的审批记录，系统直接输出“阻断”，支付流程无法继续。这类输出通常不需要人工复核，由系统自动执行。它适用于那些确定性极高、必须刚性执行的控制点。

第四类是预测信息。部分风险模型还具有预测能力。例如，基于供应商的历史履约数据、财务状况、行业景气指数，模型可以预测“该供应商在未来三个月内有35%的概率出现交付延迟”。这个预测结果可以输出给采购部门，作为合同续签、供应商分级管理、安全库存准备的决策参考。预测类输出是风险模型从“监控现状”走向“预判未来”的标志。

第五类是解释信息。这是模型输出的一个重要但容易被忽视的组成部分。尤其在规则模型中，系统需要解释“为什么判定这是一个风险”。例如，一条预警信息除了告知“围标串标嫌疑”之外，还应附带具体的证据链：“投标人A与投标人B的机器制作码相同；投标人A与投标人B的投标文件作者均为‘张三’；投标人A与投标人B的报价呈等差数列”。解释信息既便于业务人员快速理解问题、高效核查，也为后续的审计和责任追溯提供了依据。对于风险分析模型（尤其是黑箱模型），可解释性是一个技术挑战，目前业界正在探索通过SHAP值、LIME等工具提供局部的特征重要性解释。

（三）输入与输出之间的桥梁：模型的决策逻辑

输入是“事实”，输出是“判断”，两者之间的桥梁就是模型的决策逻辑。

对于规则模型，这个决策逻辑是显式的、由人预先定义的：IF条件A AND条件B THEN结论C。

对于风险分析模型，这个决策逻辑是隐式的、从数据中学习得到的。模型内部有成千上万个参数，输入数据经过层层变换后产生输出，人无法直接阅读和理解这些参数的含义，但可以通过测试和验证来信任模型的整体效果。

理解输入与输出的关系，对于模型设计者和管理者都至关重要。

设计者需要确保输入数据能够支撑预期的输出——如果希望模型能够识别围标串标，就必须能够采集到投标人的机器码、作者信息、报价明细等关键字段；如果这些数据不存在或质量太差，模型就无法实现预期功能。

管理者则需要理解模型的输出信号意味着什么——一个红色预警不代表“一定有问题”，而代表“根据模型判断，这个交易的风险程度很高，需要人工核查”。管理者的责任不是完全信赖模型，而是建立配套的复核和处置机制。

三、风险模型的设计思路与方法

风险模型的设计，是将业务语言转化为技术语言的过程。

业务人员描述的是管理要求和风险痛点，开发人员需要的是可执行的代码逻辑和算法模型。

两者之间存在一道鸿沟，需要一套标准化的设计方法来跨越。

（一）设计起点：从业务场景出发，而非从数据出发

风险模型设计最常见的误区是“从数据出发”——IT部门查看数据表中有哪些字段，然后琢磨“这些数据可以用来做什么模型”。这种思路的问题是：模型可能与实际业务需求脱节，建出来的模型风险管理人员不用，或者用不上。因为数据存在的目的不是为了让模型跑起来，而是为了支撑业务决策。

正确的设计起点是从业务场景出发。业务场景是指企业在特定业务领域、特定业务环节中面临的具体风险问题。

例如：采购环节：如何识别围标串标行为；供应商管理：如何评估供应商的履约风险；合同管理：如何预测合同违约概率；付款环节：如何发现异常的资金流动模式？

选择业务场景时，需要遵循这几个原则。一是风险确实存在且已有真实案例，而不是想象出来的风险。二是数据条件相对成熟——相关数据可以在DRP中获取，质量基本可用。三是业务部门和风控部门都有意愿和动力解决这个问题，有人愿意用模型、愿意配合测试和反馈。四是有比较明确的“好坏”标准——能够区分什么是正常、什么是异常，有标注数据可用于模型训练（对于分析模型而言）。

对于初次建设风险模型体系的企业，建议从规则模型入手，选择1-2个风险集中、数据条件较好的领域进行试点。规则模型逻辑简单、见效快、可解释性强，容易获得业务部门的信任。

在规则模型运行成熟、数据治理达到一定水平后，再逐步引入风险分析模型，处理更复杂的风险场景。

（二）设计过程：六步递进法

无论规则模型还是风险分析模型，其设计过程都可以遵循一个通用的六步递进框架。每个步骤解决一个特定问题，前一步的输出是后一步的输入。

第一步：风险场景定义。

这一步骤的任务是用简洁、准确的语言描述风险发生的场景、表现形式、可能造成的后果。

不要泛泛地说“采购风险”，而要具体到“某业务单元在招标采购过程中，出现不同投标人的投标文件高度雷同、报价呈规律性差异、投标人之间存在隐性关联关系，导致中标价格高于市场均价20%以上的围标串标风险”。

场景定义越具体，后续的数据梳理和模型设计就越有方向。

在这一步还需要界定：该风险场景归属于哪个业务领域、哪个业务流程环节、涉及哪些部门和角色。这有助于后续的职责分配和处置流程设计。

第二步：数据来源梳理与可获取性评估。

针对定义好的风险场景，梳理判断该风险所需的所有数据。包括：数据存放在哪个业务系统（采购系统、合同系统、财务系统、供应商主数据系统）、数据字段是什么、数据的更新频率（实时、每日、每月）、数据的质量状况（缺失率、准确率）。

这一步需要业务专家和IT专家共同完成。业务专家知道需要什么信息来判断风险，IT专家知道这些信息在哪个系统、能不能取出来、取出来之后质量如何。如果发现关键数据无法获取或数据质量太差（例如缺失率超过30%），就需要决定：是先进行数据治理再推进模型，还是暂时放弃该场景、选择其他数据条件更好的场景先行试点。

这一步的输出是一份“数据清单”，每一条数据都标注了来源系统、获取方式（API、数据库直连、文件导入）、更新频率、质量评估结果。

第三步：特征提炼与模型类型选择。

对于规则模型，这一步是将风险判断逻辑转化为系统可执行的条件表达式。规则的基本结构是IF-THEN。

例如，“IF【同一招标项目】AND【两家以上投标人的机器制作码相同】THEN【判定为串通投标嫌疑】”。规则可以是单层条件，也可以是多层嵌套的复合条件。这一步需要业务专家将隐含在经验中的判断逻辑显性化、结构化。

对于风险分析模型，这一步是特征工程——将业务风险描述转化为可量化的数值特征。

例如，围标串标风险可以转化为以下特征：投标报价的离散程度（标准差/均值）、投标报价的规律性（是否呈等差数列）、不同投标人之间法人代表的关联度、不同投标人之间历史投标行为的相似度等。特征工程是机器学习模型成功的关键，好的特征可以让简单的算法产生优秀的效果，而差的特征即使使用复杂的深度学习也难以奏效。

在特征提炼之后，需要根据问题的性质选择合适的模型类型。二分类问题（正常/异常）可以选择逻辑回归、XGBoost；异常检测问题（从大量正常数据中发现少量异常）可以选择孤立森林；关联分析问题（发现实体之间的隐性关系）可以选择知识图谱、图神经网络。

第四步：模型训练与验证（仅针对风险分析模型）。

对于风险分析模型，特征提炼完成后，进入模型训练阶段。这一步骤需要历史标注数据——已经确认为正常或异常的业务案例。具体流程包括：

数据划分：将历史数据按时间或随机方式划分为训练集、验证集和测试集，通常比例为7:1.5:1.5。

模型训练：在训练集上使用选定的算法训练模型，调整超参数。

模型验证：在验证集上评估模型效果，主要指标包括准确率（整体判断正确的比例）、精确率（预警中有多少是真正的异常）、召回率（真正的异常中有多少被成功发现）、F1分数（精确率和召回率的调和平均）。

模型测试：在测试集上最终评估模型效果，确保没有过拟合。

需要特别注意的是，在风控场景中，“召回率”往往比“精确率”更重要——漏掉一个真实风险可能造成巨大损失，而多发几条误报警报的代价相对较小。但也不能走向极端，如果误报率太高，业务部门会产生“狼来了”效应，不再重视预警。阈值的选择需要在漏报和误报之间找到平衡点，这个平衡点因风险类型而异，高风险低容忍的场景倾向于高召回，低风险高容忍的场景可以更关注精确率。

第五步：阈值设定与分级。

模型训练完成后，会产生一个数值输出（风险评分），需要设定阈值来决定什么情况下触发预警以及触发什么级别的预警。阈值设定通常参考两个维度：模型输出的风险评分分布，以及业务上对风险容忍度的判断。

一般设定三级阈值：黄色预警（低风险，需要关注）、橙色预警（中风险，需要核查）、红色预警（高风险，需要立即处置）。阈值不是一成不变的，需要在模型上线后的运行过程中持续调整。一个实用的方法是：初期采用较宽松的阈值（宁可多报、不要漏报），收集一段时间的人工复核结果后，根据误报率逐步收紧阈值。

第六步：部署与持续迭代。

模型通过验证后，部署到RCB的规则与模型层。部署时需要配置：数据输入源（从DRP订阅哪些数据流）、模型调用方式（实时调用还是批量计算）、输出目标（预警推送至哪个模块、哪些责任人）。

模型上线不是终点，而是持续优化的起点。需要建立模型运行监控机制，定期（如每月）统计模型的命中率、准确率、误报率、处置时效等指标。当模型效果下降时（例如准确率连续两个月低于阈值），触发模型再训练流程。对于规则模型，需要根据业务变化和监管更新及时调整规则逻辑。

小结一下：风险模型是风险管控数智化升级的核心引擎。它将风险判断从人的经验转移到数据和算法，从定性描述转变为定量计算，从定期评估进化为实时监控。

规则模型和风险分析模型各有其位。规则模型处理已知的、边界清晰的风险，执行效率高、可解释性强；风险分析模型探索未知的、隐蔽复杂的风险，挖掘深度大、适应能力强。两者配合使用，共同构成企业数智化风控的智能内核。