3、系统架构概览：智能报销系统的模块划分、规则引擎与风控引擎的定位与协作关系

智能报销系统并非简单的“填单+审批”工具，而是一个由多个专业模块协同工作的业务中台。在实施规则配置与风控策略之前，我们必须先理解系统的“骨架”与“血脉”——即模块如何划分、规则引擎与风控引擎各自承担什么职责，以及它们如何通过数据流与事件机制实现联动。本章将拆解智能报销系统的整体架构，重点剖析规则引擎与风控引擎的定位、协作模式及配置切入点，为后续章节的实战配置打下坚实的架构基础。

3.1 系统模块划分：从接入到归档的全链路视图

3.1.1 核心原理：分层解耦与模块职责边界

智能报销系统的架构设计遵循“高内聚、低耦合”原则，整体划分为四层：接入层、业务核心层、引擎层、数据层。每一层只对上层提供明确的服务接口，下层不反向依赖。这种分层设计使得规则配置与风控策略可以在引擎层独立调整，而不影响前端页面和业务流程代码。

业务核心层是模块划分的重点，通常包含以下功能模块：

3.1.2 判断方法：如何识别模块边界与数据流

在实际配置中，判断一个功能应归属哪个模块，可遵循以下三步：

1. 数据归属判断：该操作主要读写哪类数据？如发票信息归发票管理模块，预算余额归预算控制模块。
2. 生命周期判断：该操作发生在报销流程的哪个阶段？申请阶段归费用申请模块，审批阶段归审批流模块。
3. 异常处理判断：如果校验失败，应该由哪个模块负责拦截和提示？规则引擎负责逻辑拦截，风控引擎负责风险拦截。

3.1.3 案例拆解：差旅报销场景的模块协作

以“员工提交一笔差旅报销单”为例，观察模块间的协作链路：

• 接入层：员工通过手机App拍照上传发票，OCR自动识别。
• 发票管理模块：调用风控引擎进行发票验真与查重，返回“发票真实且未重复报销”。
• 报销单模块：员工填写费用明细（交通费、住宿费），提交时触发规则引擎。
• 规则引擎：校验住宿费是否超标准（如一线城市500元/晚），校验交通费是否在申请范围内。
• 预算控制模块：检查部门差旅预算余额，若充足则占用预算。
• 审批流模块：根据规则引擎结果，若超标则自动加签部门总监；若正常则直接流转至财务初审。
• 支付模块：财务审批通过后，风控引擎再次校验收款账户，确认无风险后发起银企直连支付。

该案例清晰展示了模块间的“接力式”协作，任何一环的规则配置缺失都可能导致流程漏洞。

3.2 规则引擎：业务逻辑的“交通警察”

3.2.1 核心原理：规则引擎的定位与执行机制

规则引擎的核心定位是将业务逻辑从代码中解耦出来，通过可视化配置或脚本方式动态管理。它负责处理“确定性”的业务规则——即条件明确、结果可预期的判断。例如：“差旅住宿标准”“餐补标准”“报销时限”等。

规则引擎通常包含以下核心组件：

• 规则集（Rule Set）：一组相关规则的集合，按业务场景分组。
• 事实（Fact）：参与规则判断的数据对象，如报销单对象、员工对象、预算对象。
• 条件（Condition）：IF-THEN结构中的IF部分，支持比较、逻辑、算术运算。
• 动作（Action）：规则命中后执行的操作，如“通过”“拒绝”“转人工”“修改金额”。
• 优先级（Priority）：规则冲突时的执行顺序。

3.2.2 操作流程：规则配置的标准步骤

1. 需求分析：明确业务规则的具体内容、适用范围、生效时间。
2. 规则建模：将业务语言转化为条件表达式，例如“住宿费 > 500元/晚” → accommodationFee > 500。
3. 规则编排：在规则引擎中创建规则集，设置优先级和关联动作。
4. 测试验证：使用历史数据或模拟数据验证规则正确性。
5. 灰度发布：先对部分组织或人员生效，观察效果后再全量发布。

3.3 风控引擎：风险识别的“安全哨兵”

3.3.1 核心原理：风控引擎的定位与能力边界

风控引擎的定位是识别“不确定性”的风险，包括欺诈、虚假报销、重复报销、异常行为、合规风险等。与规则引擎的“硬性判断”不同，风控引擎更强调概率评估、行为分析和模式识别。

风控引擎的核心能力包括：

• 名单管理：黑名单、白名单、灰名单，如“虚假发票供应商黑名单”。
• 策略集：一组风控规则的组合，按风险等级配置不同处置动作。
• 模型引擎：支持机器学习模型（如异常检测模型、欺诈概率模型）。
• 实时/离线决策：实时拦截高风险操作，离线分析历史数据发现潜在风险。
• 案件管理：对触发风控的事件生成案件，支持人工调查与处置。

3.3.2 判断方法：规则引擎与风控引擎的职责区分

3.4 双引擎协作：从“各自为政”到“联防联控”

3.4.1 协作模式：串行与并行结合

在实际系统中，规则引擎与风控引擎并非独立运行，而是通过事件驱动机制实现协作。典型的协作模式如下：

1. 串行模式：先执行规则引擎，通过后再执行风控引擎。适用于“先合规、后风控”的场景。
2. 并行模式：两个引擎同时执行，汇总结果后统一决策。适用于需要同时考虑业务合规与风险控制的场景。
3. 嵌套模式：规则引擎的某个动作触发风控引擎的特定策略。例如规则引擎发现“报销金额超过部门平均值的3倍”，则触发风控引擎的“异常金额检测”策略。

3.4.2 协作流程：一次完整的双引擎决策链路

报销单提交
    ↓
[规则引擎] 执行基础校验
    ├─ 通过 → 进入下一步
    ├─ 拒绝 → 返回原因，流程终止
    └─ 转人工 → 进入人工审核队列
    ↓
[风控引擎] 执行风险检测
    ├─ 风险评分 < 60 → 放行
    ├─ 60 ≤ 评分 ≤ 80 → 加签风控专员
    └─ 评分 > 80 → 拦截并生成案件
    ↓
[审批流模块] 根据引擎结果路由至相应审批节点

3.4.3 案例拆解：重复报销风控的完整闭环

背景与约束：某企业年报销单量约12万笔，财务团队仅5人，每月发现重复报销约30笔，涉及金额约8万元。企业要求在不增加财务人手的前提下，将重复报销率降低80%。

初始现象与目标：重复报销主要发生在“同一张发票在不同月份被两次提交”或“电子发票被多次打印提交”。目标是将重复报销率从0.3%降至0.06%以下。

关键输入数据：发票代码、发票号码、开票日期、销售方名称、报销金额、报销人、报销日期。

分析判断过程：

1. 规则引擎先执行“发票必填项校验”和“金额合理性校验”，排除明显无效单据。
2. 风控引擎调用发票库，以“发票代码+发票号码”为唯一键进行精确查重。
3. 对于电子发票，增加“发票PDF文件Hash值”比对，防止同一文件被重复提交。
4. 对于“连号发票”场景，风控引擎分析同一报销人连续提交的发票号码是否在相邻区间内，若是则标记为“疑似拆分报销”。

实际操作步骤：

• 在风控引擎中配置“发票重复检测”策略集，包含精确查重、Hash查重、连号检测三条策略。
• 设置风险评分规则：精确查重命中 → 评分100，直接拦截；Hash命中 → 评分90，拦截并通知报销人；连号检测命中 → 评分70，加签财务复核。
• 配置案件管理流程：拦截的单据自动生成风控案件，风控专员在案件中心查看详情并确认。

结果对比：上线后首月，重复报销率从0.3%降至0.04%，月均拦截重复报销约25笔，节省金额约6.7万元/月。同时，由于风控引擎自动处理了大部分查重工作，财务人员无需再人工比对发票，每月节省约15人天的工作量。

风险与代价：初期存在误拦截情况（约2%），主要原因是连号检测策略过于敏感，将正常连续出差报销误判为拆分报销。通过调整连号检测的阈值（从“连续3张”改为“连续5张且金额相近”）后，误拦截率降至0.3%。

复盘经验：双引擎协作的关键在于“规则引擎做减法（过滤无效单据），风控引擎做乘法（识别复杂风险）”。配置风控策略时，应先用历史数据回测，确定合理的阈值和评分权重，避免“一刀切”导致误伤正常业务。

3.5 常见误区与总结复盘

3.5.1 常见误区清单

3.5.2 总结复盘：架构视角的配置要点

从架构视角看，规则配置与风控配置不仅是“写条件”的工作，更是对系统架构理解的体现。配置人员需要时刻保持“模块意识”——知道当前配置的规则在哪个模块生效、影响哪些下游环节、需要哪些数据支撑。同时，要建立“双引擎思维”——业务规则用规则引擎，风险识别用风控引擎，两者通过事件机制协作，形成完整的决策闭环。