风险热点：最容易出问题的地方

不是每个环节都会出问题，但以下这些是事故高发区——盯住它们。

flowchart TB
    subgraph 风险生命周期
        A[风险事件<br/>行情波动 / 操作失误] --> B[检测]
        B --> C[预警]
        C --> D{自动处理?}
        D -->|是| E[自动执行]
        D -->|否| F[人工干预]
        F --> G[处理完毕]
        E --> G
        G --> H[事后复盘]
    end

---

一、时效类风险（Time-sensitive）

1. Margin Call 时效

节点	典型窗口	出问题的后果
日终估值完成	15:00-16:00	无法计算当日保证金
Margin Call 发出	估值后 30 分钟内	客户收不到通知→无法追保→穿仓
客户追保截止	通常次日上午 10:00	逾期→强制平仓→客户纠纷
强制平仓执行	截止后 1 小时内	平仓延迟→亏损扩大

根本原因：

• 估值引擎性能不足：市场波动大时交易量大增，批处理跑不完
• 依赖人工触发 Margin Call：运营忘记点”发送”或审批流程卡住
• 客户联系方式失效：联系人邮箱/手机变了但系统未更新
• 依赖次日人工追保：客户未在截止前入金，没人盯
• 平仓需多部门审批：交易员等风控批→等领导批→行情已变

检测方法：

• 估值完成时间监控：15:30 未完成则告警
• Margin Call 发出确认：运营 Terminal 弹出”今日 Call 是否已发？”
• 追保截止倒计时：截止前 30 分钟未入金→预警
• 强制平仓 SLA 超时：平仓指令发出后 30 分钟未成交→升级

预防措施：

• 全流程自动化：估值完成→自动计算→自动触发→自动发送
• 客户联系方式年检：每年至少一次确认联系人信息
• 银期转账对接：客户可系统内直接划款，系统自动确认到账
• 自动平仓授权：客户在协议中预先授权，到期未补→系统自动平

应急预案：

• 估值超时→切换到简化估值模型（用昨收+当日主要变动估算）
• 系统发不出→运营手工从备份系统导出数据，通过邮件/电话发出
• 客户未追保→运营必须在截止后 15 分钟内电话联系客户
• 无法平仓→交易员手工下单（走电话/彭博聊天）

2. 确认书时效

节点	要求	未完成的后果
交易确认书发出	交易当日（T+0）	监管通报
客户签回确认书	T+5 以内	交易可能被认定为无效
确认书归档	签回后立即	审计不合格

根本原因：

• 确认书生成依赖手工操作：交易员录入→运营审核→运营发送
• 客户盖章流程长：客户内部审批慢、印章不在公司
• 签回确认书遗失：客户签了但扫描件丢失/邮件被过滤
• 法规意识不足：新人不知道 T+5 红线

检测方法：

• 确认书发出监控：系统自动计时，T+0 下班前未发出→告警
• 签回倒计时面板：按剩余天数排序（还剩 4 天/3 天/2 天…）
• 超时升级：T+4 未签回→自动升级给销售总监
• 签回自动校验：系统识别扫描件文件名/邮件主题，自动匹配

预防措施：

• 自动生成确认书：交易录入完成后系统自动生成 PDF
• 电子签章对接：支持客户线上签回（e签宝/法大大）
• 自动提醒链：第 1 天→邮件提醒 第 3 天→电话提醒 第 4 天→升级
• 确认书模板管理：标准品（互换/期权）使用标准化模板，减少人工介入

应急预案：

• T+4 仍未签回→暂停该客户新交易
• 客户反映没收到→从系统重新发送（检查邮箱地址后）
• 纸质签回来不及→先收扫描件，原件后补

3. 监管报送截止时间

报送项	截止时间	错过后果
日报	次日上午 10:00	监管通报
月报	次月 5 个工作日内	监管处罚
季报	季后 10 个工作日内	暂停业务资格（严重）
年报	次年 4 月底	吊销业务资格

根本原因：

• 数据源分散：日报数据来自交易系统，月报需合并财务数据，跨系统取数易出错
• 报送规则变化：监管不定期更新报送模板，系统未同步更新
• 依赖专人报送：报送员请假/离职→无人替补
• 节假日算错：工作日计算规则不同（自然日 vs 工作日）导致误判截止日

检测方法：

• 截止日倒计时仪表盘：首页固定展示各报送项剩余天数
• 数据完整性预检：报送前自动检查必填字段是否完整
• 监管模板版本管理：模板变更时系统自动告警
• 节假日日历自动更新：系统维护交易所+银行间+监管日历

预防措施：

• 报送自动化：从交易系统/风控系统自动取数，自动生成 XML 报送文件
• 报送审批流：系统生成→主管复核→合规确认→自动上报
• 模板变更应对：监管发新模板→系统在沙箱中运行对比→标记差异
• 双人报送制：至少两人掌握报送操作，AB 角
• 试报送机制：正式报送前先试运行，确认格式正确

应急预案：

• 日报来不及→先报关键数据（交易量/持仓量/风险指标），明细后补
• 系统故障→手工通过监管报送系统页面录入
• 截止前 1 小时仍未准备好→立即电话联系监管员说明情况

4. 公司行动处理时限

事件	必须完成时间	错过后果
分红调整	除权除息日开盘前	客户纠纷、赔偿
配股调整	配股登记日前	客户损失索赔
并购调整	生效日前	法律诉讼

根本原因：

• 信息来源分散：公司行动公告来自多家交易所/信息商，可能遗漏
• 人工扫描公告：运营每天手工扫描几十份公告，漏掉或读错
• 调整规则复杂：不同产品类型（互换/期权/雪球）对同一公司行动的处理方式不同
• 截止时间被忽略：调整必须在某个时间点之前完成，但日历没有标注

检测方法：

• 公司行动日历：自动抓取上市公司公告，生成待处理清单
• 影响分析报告：判断每笔持仓是否受公司行动影响
• 处理截止倒计时：每项公司行动标注处理截止时间
• 遗漏告警：已登记的公司行动在截止时间前 1 天未处理→告警

预防措施：

• 信息商订阅：通过 Bloomberg/路透/万得自动获取公司行动数据
• 调整模板化：分红→自动计算调整因子；配股→自动生成新合约
• 批量调整引擎：一键对所有受影响合约执行调整
• 差异报告：系统调整后的结果与对手方调整结果交叉比对

应急预案：

• 错过除权除息日调整→与客户协商追溯调整（计算现金补偿）
• 调整金额存疑→运营手工计算并双方确认后入账
• 系统不支持特殊调整→交易员手工修改合约条款，法律确认

---

二、数据类风险（Data Integrity）

5. 跨系统数据不一致

最容易出现差异的地方：

• 交易系统 vs 风险系统的 PnL 不一致
• 交易系统 vs 运营系统的持仓不一致
• 内部系统 vs 对手方系统的估值不一致

典型场景：

销售在 CRM 里录了客户，但交易系统没同步
→ 交易员报价时查不到客户信息
→ 客户等了 30 分钟还没报价
→ 客户走了，去别家了

根本原因：

• 系统间没有实时同步机制，依赖定时批处理（如每 15 分钟/每小时同步一次）
• 数据标准不统一：两个系统对”客户名称”的长度、格式定义不同
• 接口异常无人监控：ESB/API 调用失败后静默丢弃，没有重试机制
• 主数据没有唯一源：CRM、交易系统、风控系统各自维护同一份数据

检测方法：

• 对账报告：每天日终自动比对交易系统 vs 风控系统 vs 运营系统的持仓/PnL
• 同步延迟监控：监控每次同步任务的开始时间、完成时间、处理条数
• 异常交易标记：同一笔交易在不同系统间差异超过阈值→自动标记
• 对账失败告警：对账不平→自动通知运营和 IT 负责人

预防措施：

• 主数据管理（MDM）：客户、产品等基础数据只在一个系统中维护，其他系统通过 API 实时获取
• 实时同步优先：关键数据（交易、持仓、保证金）使用消息队列实时同步，不依赖批处理
• 对账自动化：日终自动全量对账，差异生成工单自动分派
• 接口熔断机制：第三方接口连续失败 N 次→告警并暂停该接口，避免数据污染

应急预案：

• 对账不平→运营手工核查差异来源，优先在交易系统中修正
• 同步中断→运营导出 CSV 通过 SFTP 手工同步
• 紧急情况→以交易系统数据为准，其他系统事后补录

6. 参考数据维护错误

数据项	维护不好会怎样
客户主数据	合规报送出错、额度查不到
产品参数	交易录入错误、估值出错
利率曲线	全市场定价偏离
汇率	跨境交易亏损
波动率曲面	期权定价全错

根本原因：

• 数据维护分散：不同部门各自维护自己的”小数据库”，没有统一入口
• 依赖手工录入：利率曲线、汇率等市场数据需手工从信息商抄录
• 缺乏版本管理：参数更新后没有变更记录，回滚困难
• 无人负责校验：数据录入了但没有人验证是否准确

检测方法：

• 参考数据对比：将内部数据与信息商（Wind/Bloomberg）数据每周自动比对
• 异常值检测：利率曲线出现超过 3σ 变动→自动标记
• 参数变更审计日志：谁、什么时间、改了哪个参数、改前改后值
• 数据质量评分：为每类参考数据计算完整率/准确率/及时率

预防措施：

• 单一维护入口：所有参考数据通过统一平台维护，分发到各下游系统
• 信息商直连：市场数据（利率/汇率/波动率）直接从 Wind/Bloomberg 自动获取
• 数据变更审批流：核心参数修改必须经主管审批才能生效
• 自动校验规则：录入时检查格式、范围、合理值（如汇率波动 > 5% 则拒绝保存）
• 定期审计：每月对参考数据进行抽样审计

应急预案：

• 参考数据出错→运营回滚到上一版正确数据
• 信息商数据缺失→手工从备用信息商获取并录入
• 无法确认正确数据→暂停依赖该参数的新交易，排查后再恢复

---

三、合规类风险（Compliance）

7. 适当性匹配遗漏

客户风险等级 C2（保守型）
产品风险等级 R4（高风险）
系统没有阻断 → 客户买了雪球
市场下跌 → 客户亏损 → 投诉 → 监管处罚

根本原因：

• 客户风险等级未及时更新：客户的财务状况变化了，但系统存的是旧等级
• 产品风险评级有歧义：同一个产品在不同渠道的风险评级不一致
• 系统检查可绕过：适当性检查是”建议性”的，交易员可以勾选”已确认风险”跳过
• 新产品没有评级：新品上架时忘记设置风险等级，系统默认通过

检测方法：

• 适当性命中率统计：每周查看被阻断的交易比例，异常低→可能检查已失效
• 客户等级过期告警：客户风险等级超过 1 年未更新→提醒重新评估
• 绕过操作审计：检查”强制通过”操作的使用频率和使用人
• 新产品合规检查：新产品上线时必须填写风险评级字段，否则无法上架

预防措施：

• 硬阻断机制：适当性不匹配→交易无法录入，没有任何人可跳过
• 等级自动更新：客户资产变化超过一定幅度→自动触发重新评估
• 产品-客户匹配矩阵：预设好每类产品适配的客户等级范围
• 适当时效性管理：客户等级到期后自动冻结其新交易权限

应急预案：

• 错配交易被发现→立即暂停该交易，联系法务评估赔偿风险
• 客户投诉适当性→收集完整销售录音、问卷、双录记录备查
• 系统误判→运营核查客户最新资料后人工调整

8. 额度超限未阻断

客户额度 5000 万
销售做了 8000 万的交易
系统没有检查 → 超额交易完成
风控发现时为时已晚

根本原因：

• 额度计算滞后：额度是基于日终持仓算的，交易时显示的是昨日额度
• 额度类型复杂：授信额度 vs 担保品额度 vs 单笔额度，系统只检查了其中一种
• 额度未实时扣减：一笔交易录入后额度未即时占用，同一客户可同时录多笔超额
• 例外审批泛滥：领导可以手动调额度，调了之后系统不再阻拦
• 跨产品额度未合并：客户在互换上用 3000 万，期权上用 3000 万，系统分开统计但总敞口已超

检测方法：

• 成交后实时检查：每笔交易成交后实时计算客户总敞口，超限立即告警
• 例外审批报告：每周审计所有手工调额度的记录
• 额度使用率仪表盘：按客户/产品线展示已用额度/剩余额度
• 批量超限扫描：日终批量跑所有客户的额度使用情况

预防措施：

• 交易前检查：交易录入时即时校验额度，超额则硬阻断
• 实时额度扣减：交易确认后立即从可用额度中扣减，防止并发超限
• 额度分层管理：总授信额度→产品线额度→单笔额度，逐层校验
• 自动调额审批流：超限时自动触发升级审批，按金额分层（部门主管→风控总监→CEO）
• 担保品动态折算：担保品市值波动导致折算后额度变化→系统实时更新

应急预案：

• 超额交易已完成→立即通知风控和法务，评估是否需紧急平仓
• 客户无法追加担保品→协商分期降低敞口
• 系统额度计算错误→运营手工核定正确额度，调整系统记录

9. AML 筛查遗漏

新客户准入时 AML 系统接口超时
运营跳过等待直接开通 → 客户是制裁名单
→ 监管重罚

根本原因：

• AML 系统是外部系统，接口不稳定导致超时
• 运营人员没有”筛查不通过不开户”的意识，超时后直接跳过
• 缺乏绕过操作的审批机制：运营自己就可以决定跳过，无人复核
• AML 名单更新滞后：制裁名单更新了，但内部系统未同步
• 只查了客户本身没查受益所有人（UBO）：客户本人不在名单上，但背后的实际控制人在

检测方法：

• AML 接口健康监控：接口连续 3 次超时→自动告警
• 跳过操作审计日志：记录谁跳过了 AML 检查、原因、审批人
• 客户全量回溯扫描：新制裁名单发布后，回溯扫描所有已通过客户的名单命中情况
• UBO 穿透检查：检查客户股权结构，确保受益所有人也通过筛查

预防措施：

• 硬阻断设计：AML 未通过或接口超时→客户无法创建，任何人均无法绕过
• 双人复核制度：如确需手工放行，必须运营主管 + 合规主管双签
• 名单自动同步：制裁名单 / 黑名单通过接口自动更新，无需手工维护
• 姓名拼音匹配：中文名和拼音同时检查，防止用拼音名绕过
• 批量回溯机制：制裁名单更新后自动触发存量客户重新筛查

应急预案：

• 已开户的客户命中制裁名单→立即冻结其交易权限，向合规总监报告
• AML 接口长时间不可用→启用备用筛查通道（手动录入制裁名单比对）
• 潜在漏筛客户列表→按风险等级排序，优先处理高净值/高风险客户

10. 黑名单/限制名单未检查

内部限制清单刚更新了某只股票
交易员下单时系统查的是旧清单
→ 违规交易完成 → 内幕交易嫌疑

根本原因：

• 限制名单维护在静态文件/Excel 中，更新后未及时导入系统
• 交易系统缓存了老名单，数据库已更新但缓存未刷新
• 限制来源多：监管黑名单、公司内部限制名单、客户指定限制名单——只检查了其中一部分
• 名单适用范围不清：某只股票被限制，但不知道是”禁交易”还是”禁做市”还是”需审批”
• 检查时点错误：下单时通过了检查，但持仓期间该股票被加入限制名单，系统未自动告警

检测方法：

• 名单版本号检查：每次交易前确认系统使用的名单版本号与最新版一致
• 缓存刷新验证：限制名单更新后验证交易系统缓存是否同步刷新
• 存量持仓交叉检查：限制名单更新后自动扫描存量持仓是否命中新名单
• 限制类型分类：明确每项限制的适用范围和业务类型

预防措施：

• 限制名单统一管理：所有限制清单在一个平台维护，自动分发到各业务系统
• 多级限制机制：交易前检查→交易中监控→持仓后扫描（三个时点全覆盖）
• 名单更新推送：限制名单变更→实时推送到交易系统（不用等缓存过期）
• 限制自动分类：系统自动判断该限制影响哪些业务线（互换/期权/做市/自营）
• 过期名单清理：定期清理未更新的限制条目，防止名单膨胀后性能下降

应急预案：

• 违规交易已执行→立即冻结相关头寸，向合规和法务报告
• 限制名单冲突→以合规部最新发布的版本为准，手工核对
• 系统无法实时同步→运营导出最新名单，手工导入各系统

---

四、操作类风险（Operational）

11. 人为录入错误

错误类型	后果	系统防控
名义本金多一个零	10 倍风险暴露	自动校验 + 大额审批
期权方向选反	Call↔Put 盈亏反了	双人复核
敲入敲出价填反	结构完全变了	参数合理性校验

根本原因：

• 交易高峰期压力大：客户急着要成交，交易员手快出错
• 字段布局不合理：关键字段（方向/金额）在录入界面中靠近容易误触的位置
• 缺乏格式校验：金额字段不限制最大位数，“10000000”和”100000000”长得差不多
• 缺乏合理性校验：系统不知道”这笔交易的名义本金是该客户平时交易量的 10 倍”
• 历史遗留数据错误迁移：从旧系统迁移数据时，某些字段映射错误

检测方法：

• 大额交易告警：超过该客户历史交易规模 3 倍→标记待确认
• 字段变更跟踪：交易修改前后自动生成差异对比报告
• 交易特征分析：同一交易员短时间内的多笔交易有规律性差异→疑似批量错误
• 日终交叉验证：名义本金合计 vs 保证金合计 vs 客户额度使用率

预防措施：

• 录入界面防错设计：金额字段自动格式化显示（1,234,567），关键字段加粗高亮
• 自动校验规则库：格式校验、范围校验、合理性校验（与历史均值比较）
• 双人复核机制：大额/复杂交易录入后必须第二人确认才能生效
• 交易对比确认：交易录入后系统自动显示摘要（“一笔 1000 万的看涨期权，名义本金 1000 万”）待确认
• 标准模板预置：同类交易预先填好 90% 的参数，只需修改关键几项
• 撤销窗口期：交易录入后 5 分钟内允许交易员自己撤销（不经过审批）

应急预案：

• 错误交易已成交→立即联系对手方协商修改或反向平仓
• 金额多零导致风险敞口过大→立即做对冲交易缩小敞口
• 错误无法修改→通过补充协议修正条款，法务审核

12. 手工处理遗漏

运营每天要手工发送 20 封确认书
今天太忙 → 漏发了一封
→ 客户没收到 → 交易未确认
→ 到期结算纠纷

根本原因：

• 依赖”人记住去做”：没有系统驱动的任务列表，完全靠个人备忘录
• 工作量饱和：运营同时处理确认书、对账、公司行动、客户准入等任务，容易忘
• 没有超时检查：没有人检查”今天的确认书是不是都发完了”
• 离职/请假交接空档：平时某人一直在做，他请假了别人不知道要做
• 手工操作分散在多个系统：彭博发确认书、邮件发通知、Excel 记录状态——割裂

检测方法：

• 待办清单（Todo List）：系统自动生成每天/每项任务需完成的操作清单
• 超时升级机制：任务超过预定时间未完成→通知主管，再超过→通知总监
• 完成率看板：运营团队每人每天的任务完成率、超时率
• 操作留痕审计：所有手工操作需在系统中点击”完成”并记录操作人、时间

预防措施：

• 自动化优先：任何重复性手工操作优先考虑自动化（如确认书自动发送）
• 任务驱动型工作台：运营每日打开系统→看到今天要做的所有事→做完勾掉
• 替代人机制：关键任务指定 AB 角，A 不在→B 自动收到任务提醒
• 操作防漏清单：按业务类型预设标准操作流程（SOP），逐项勾选完成
• 超时自动补偿：X 分钟后超时→系统自动执行降级方案（如自动发送默认格式确认书）

应急预案：

• 遗漏已发现→立即补做，评估损失范围
• 客户因遗漏产生纠纷→法务介入协商赔偿方案
• 关键操作严重超时→营业部负责人启动业务连续性计划（BCP），加派人手补做

---

五、系统类风险（System）

13. 日终批处理超时

日终估值要处理 5000 笔交易
今天市场波动大 + 新加了 200 笔
批处理跑了 3 小时还没完
→ 15:00 收盘 → 18:00 都拿不到估值
→ Margin Call 发不出去 → 客户第二天没追保
→ 连锁反应

根本原因：

• 交易量线性增长但系统性能未同步扩容：存量 2000 笔时 1 小时跑完，涨到 5000 笔时可能需要 3 小时
• 单线程处理瓶颈：批处理程序是单线程的，无法充分利用多核 CPU
• 数据量波动无弹性：月末/季末交易量激增，但处理资源固定
• 前序任务阻塞：日终流水线包含估值→保证金→报送→归档，前一个卡住后面的全部延迟
• 无超时熔断机制：一个交易估值卡住了，整个批处理挂起等待

检测方法：

• 批处理进度仪表盘：实时显示每个步骤的完成百分比和预估剩余时间
• 超时分级告警：超过预计时间 15 分钟→黄色告警，30 分钟→红色告警
• 历史耗时趋势图：按周/月展示批处理耗时变化，提前发现性能恶化
• 前序任务依赖监控：如果估值未完成则自动推迟 Margin Call 发送时间预估

预防措施：

• 批处理优化：单线程→多线程并行处理，按产品类型/交易台拆分并行
• 弹性计算资源：交易量超过阈值时自动扩容计算资源（云环境或容器化）
• 流水线解耦：估值→保证金拆成独立模块，估值完成后立即开始保证金计算
• 超时熔断机制：某笔交易估值超过 5 分钟→跳过该笔（用昨收估值标记），继续处理剩余
• 日间预计算：交易录入时同步做增量估值预计算，日终只做汇总校准

应急预案：

• 估值超时→切换到快速估值模型（昨收 + 当日因子调整）
• 保证金来不及计算→沿用昨日保证金，次日补收差额
• 无法生成完整报表→先生成核心数据报表（持仓/保证金/PnL），明细后补
• 系统彻底挂掉→使用灾备系统（DR）重启批处理

14. 交易时段系统宕机

14:30 客户在线上等报价
交易系统挂了
→ 报不出价 → 客户走了
→ 10 分钟后恢复，但客户已经找别家了
→ 每天这种场景发生 = 每天损失收入

根本原因：

• 系统架构存在单点故障：所有交易请求经过一台服务器/一个数据库
• 交易时段无降级方案：系统挂了就是挂了，没有”只读模式”或”报价模式”降级选项
• 变更管理不当：白天做了系统升级/配置变更，引入不稳定因素
• 外部依赖故障：交易所接口、信息商行情、银行支付接口挂了
• 监控覆盖不全：告警阈值设置不合理，系统已经慢了好几分钟才触发告警

检测方法：

• 健康检查（Health Check）：每隔 30 秒做一次关键接口可用性检测
• 交易并发监控：当前在线用户数、每分钟交易请求数、响应时间 P99
• 外部依赖状态看板：实时显示各家交易所/信息商/银行接口的连通状态
• 自动故障定位：异常发生时自动分析是内部系统还是外部依赖导致

预防措施：

• 高可用架构：多活部署/N+1 冗余，单台机器故障不影响整体
• 交易时段降级策略：系统负载过高时自动进入”报价模式”（只报价不接受新交易）
• 变更冻结期：交易日 9:00-16:00 禁止任何生产环境变更
• 全链路监控：从客户端→API 网关→交易引擎→数据库→外部接口全链路追踪
• 故障演练：每季度至少一次交易系统宕机演练

应急预案：

• 主系统宕机→流量切换到灾备系统（切换时间 ≤ 5 分钟）
• 灾备也挂了→启动手工应急流程：彭博聊天报价→Excel 记录→事后补录
• 外部接口故障→切换到备用接口（如用彭博替代万得）
• 数据丢失→从最近一次快照恢复，丢失的交易人工补录
• 超过 15 分钟无法恢复→发布业务中断公告，通知客户和监管

---

六、风险热力图（优先级排序）

风险	发生概率	影响程度	优先级
监管报送超时	低	极高	🔴 P0
Margin Call 延迟	中	极高	🔴 P0
适当性检查遗漏	低	极高	🔴 P0
额度过超	中	高	🟠 P1
确认书超时	高	中	🟠 P1
跨系统数据不一致	高	中	🟠 P1
人工录入错误	高	中	🟡 P2
系统日终超时	中	高	🟡 P2
公司行动处理延迟	低	高	🟡 P2

---

PM 的黄金法则：所有标红色的风险点（P0）必须系统自动化 + 人工监控双保险。任何依赖”某人记住去做”的控制，在 OTC 业务中都是不可接受的。