operational-risk

操作风险

核心概念

操作风险框架

操作风险是指因内部流程、人员和系统不充分或失效，或因外部事件而造成损失的风险。巴塞尔委员会的七类事件类型在交易运营中的对应情况如下：

巴塞尔事件类型	交易运营示例
1. 内部欺诈	未经授权的交易、故意错误标记持仓、虚构交易录入、抢先交易
2. 外部欺诈	账户接管、通过网络钓鱼窃取交易凭证、结算指令中的电汇欺诈、交易对手操纵
3. 雇佣做法与工作场所安全	运营培训不足、关键人员依赖、易导致错误的工作负荷
4. 客户、产品与业务实践	适当性管理失误、不当执行、违反最佳执行要求、未遵循客户指令
5. 有形资产损坏	自然灾害或社会动乱导致数据中心或交易大厅受损
6. 业务中断与系统故障	OMS 中断、市场数据源故障、连接中断、交易所网关和清算系统停机
7. 执行、交付与流程管理	交易错误、结算失败、对账差异、公司行动处理失败、保证金计算错误（通常是损失金额最大的类别）

风险识别通过流程映射、风险与控制自我评估（RCSAs）、损失事件分析、情景分析和审计发现，梳理所有操作风险敞口。风险评估从可能性和影响两个维度为每项风险评分，通常使用 5x5 热力图。风险监控跟踪 KRI、损失事件和控制有效性。风险缓释采用控制措施（预防性和侦测性）、流程再设计、技术解决方案、保险和业务连续性规划。

交易错误

交易错误是指由于人为失误、系统故障或沟通不畅，导致交易执行不正确。常见的交易错误类型包括：

• 证券错误。 输入了错误的 CUSIP、ISIN 或股票代码，导致买入或卖出非预期证券。这通常是由相似的股票代码导致的（例如，输入 “AAPL” 而不是 “APLE”），或是在下拉菜单中选错项目。
• 数量错误。 股票、债券或合约的数量有误。一种常见的细分类别是“手滑”错误，即多输入了一位数字（例如，买入 10,000 股而不是 1,000 股）。
• 方向错误。 将买入录入为卖出，或反之，导致持仓方向与预期相反。净敞口偏差是预期交易规模的两倍。
• 账户错误。 交易在错误的客户账户中执行，或在公司的自营账户中执行，而非客户账户。这会引发适当性、分配和潜在利益冲突问题。
• 重复订单。 由于系统超时后重新提交、双击，或去重逻辑失效，同一订单被提交多次。最终公司的持仓达到预期的两倍。
• 价格类型或限价错误。 下达了市价单而非限价单，或限价设置错误，导致以非预期价格成交。
• 过期或已取消订单被执行。 本应取消的订单因取消未能及时处理或在传输过程中丢失而被执行。

错误检测方法。 可通过以下方式检测错误：实时监控持仓（非预期的持仓变化会触发警报）、交易前校验规则（数量限制、证券限制、账户资格检查）、交易后对账（比较预期持仓与实际持仓）、客户投诉、清算公司或交易对手方的拒绝通知，以及损益归因（无法解释的损益往往意味着存在错误）。

错误更正流程。 发现错误后，必须及时更正：

• 撤销并重新记账。 撤销错误交易，并为正确交易记账。如果在结算前发现错误，可以在同一交易日撤销并重新记账。如果在结算后发现，则使用追溯交易对持仓进行追溯调整。
• 错误账户。 大多数经纪交易商会设立一个或多个错误账户（也称差额账户），用于在问题解决前转入错误交易。错误账户将错误持仓与客户账户隔离，并跟踪由此产生的损益。错误账户活动须接受主管审查并形成记录。
• 错误损益分配。 交易错误造成的损失由公司承担，不得转嫁给客户。交易错误产生的收益则涉及更复杂的情况——收益是返还至客户账户还是留在错误账户，由监管指引和公司政策决定。FINRA 曾表示，公司不应系统性地以牺牲客户利益为代价从交易错误中获利。
• 根本原因分析。 每次交易错误都应触发根本原因分析，以确定错误是由流程缺陷、技术问题、培训不足还是个人失误造成的。根本原因分析结果将纳入运营风险框架的风险识别与缓解周期。

交易差异与对账

当同一笔交易的两条记录不匹配时，就会产生交易差异。交易生命周期中的多个环节都可能出现差异：

• 前台与后台差异。 订单管理系统（OMS）记录与执行管理系统（EMS）的成交记录不匹配，或者前台系统中的交易记录与中台的记账记录不匹配。原因包括未正确汇总部分成交、手动记账错误以及系统集成故障。
• 公司与交易对手差异。 公司的交易记录与交易对手的记录不匹配。通过交易匹配和确认流程（例如 DTCC CTM、Omgeo、SWIFT 匹配）发现。常见原因包括数量差异、价格差异（尤其是议价的 OTC 交易）、结算日期不匹配，以及结算指令详情错误（SSI 不匹配）。
• 公司与托管机构差异。 公司的持仓记录与托管机构的记录不匹配。通过每日或日内持仓对账发现。原因包括未记账交易、公司行动处理差异、某个系统未反映结算失败，以及交易日与结算日会计处理之间的时间差异。
• 现金差异。 公司的现金分类账与银行或托管机构的现金对账单不匹配。原因包括未记账的现金变动、未记录的费用扣除、利息计提差异以及外汇换算差异。

对账流程。 公司主要进行三种对账：

1. 持仓对账。 将公司的证券持仓与托管机构、清算公司或存管机构的记录进行比较。对于活跃交易账户，每日执行。
2. 交易对账。 将公司记录与外部记录（交易对手确认书、清算对账单、托管机构对账单）中的单笔交易进行匹配。确保两个系统都记录了每笔交易。
3. 现金对账。 将公司的现金余额和变动与银行及托管机构的对账单进行比较。识别未记录的借项、贷项或费用。

差异解决工作流。 典型的差异解决流程包括：(1) 自动匹配并清除处于容差阈值内的差异（例如，价格差异低于 $0.01、因四舍五入导致的数量差异）；(2) 将未解决的差异分配给运营分析师；(3) 调查并找出根本原因；(4) 在相应系统中更正错误记录；(5) 与交易对手或托管机构确认差异已解决；(6) 记录解决情况和根本原因。

账龄与升级处理。 未解决的差异会按账龄跟踪。行业标准和监管要求规定，应根据账龄阈值进行升级处理：

账龄	状态	操作
T+0 至 T+1	正常	按常规流程调查并解决
T+2 至 T+3	需关注	升级至高级运营人员；提高优先级
T+4 至 T+5	警告	升级至运营管理层；直接联系交易对手
T+5+	紧急	升级至运营负责人和合规部门；评估财务风险敞口

容差阈值。 公司会设定容差水平，低于该水平的差异将自动解决。常见阈值包括：交易所交易证券每单位价格容差为 +/- $0.01，因四舍五入造成的数量容差为 +/- 1 单位，轻微舍入误差的现金容差为 +/- $1.00。必须定期审查容差，且不应设置得过宽，以免掩盖真实错误。

损失事件管理

损失事件是运营风险事件造成的实际损失。有效的损失事件管理需要：

损失事件识别。 来源包括交易错误损益、结算失败费用（强制买入成本、透支利息）、监管罚款和处罚、诉讼和解金、系统中断成本（错失交易、人工处理成本），以及因服务失误向客户支付的赔偿金。

损失事件分类。 每个损失事件按以下类别分类：

• Basel 事件类型（上述七个类别之一）
• 业务线（交易台、运营、技术、合规）
• 原因类别（人员、流程、系统、外部）
• 严重程度（轻微、中等、重大、严重、极严重——根据公司设定的金额阈值确定）

损失事件文档记录。 每条事件记录应包括：发生日期、发现日期、解决日期、事件描述、根本原因、Basel 类别、业务线、损失总额、追回金额（保险、交易对手赔偿）、净损失金额、已采取的纠正措施以及负责经理。

险些发生损失事件跟踪。 对于可能造成损失但最终未造成损失的事件（由于及时发现或有利的市场变动），应作为险些发生损失事件进行跟踪。险些发生损失事件是控制薄弱环节的先行指标，应与实际损失一并分析。例如：一个在执行前被交易数量上限拦截的误触交易属于险些发生损失事件。

损失事件数据库。 公司会维护内部损失事件数据库（通常属于 GRC——治理、风险与合规——平台的一部分），汇总组织内所有损失事件。该数据库有助于进行趋势分析、识别根本原因模式，以及向高级管理层和董事会报告。

阈值报告。 公司会设定报告阈值：

阈值	行动
> $10,000	24 小时内报告给部门主管
> $50,000	24 小时内报告给首席风险官
> $100,000	报告给高级管理层和风险委员会
> $500,000	通知董事会；评估监管报告义务

这些阈值仅供参考；各公司会根据自身规模、复杂程度和风险偏好进行调整。

监管通知。 某些损失事件会触发监管报告义务。FINRA Rule 4530 要求会员公司报告特定事件，包括重大运营事件。SEC Rule 17a-11 要求经纪交易商将某些财务和运营状况通知 SEC。公司必须维护一份矩阵，将损失事件类型和阈值对应到适用的监管通知要求。

关键风险指标（KRI）

KRI 是用于预警运营风险敞口上升的指标。与关键绩效指标（KPI）不同，KRI 专门用于提示风险，而非衡量绩效，不过有些指标兼具这两种用途。

前瞻性与滞后性指标。 前瞻性指标用于预测未来的风险事件（例如，系统延迟上升可能预示服务中断）。滞后性指标用于衡量已经发生的事件（例如，上个月的交易错误数量）。有效的 KRI 计划应同时包含这两类指标。

常见的交易运营 KRI：

KRI	定义	前瞻性/滞后性
NIGO 率	未按要求完成（Not-In-Good-Order）比率：收到的信息缺失或有误的交易指令所占百分比	前瞻性
交易差异率	未匹配交易数量占交易总数的百分比	滞后性
结算失败率	失败结算数量占结算总数的百分比	滞后性
交易错误率	每执行 1,000 笔交易中的交易错误数量	滞后性
错误账户余额	错误账户中持仓的美元总值	滞后性
STP 率	直通式处理（Straight-Through Processing）比率：无需人工干预即可处理的交易所占百分比	前瞻性
系统可用性	关键交易和运营系统的正常运行时间百分比	前瞻性
追加保证金通知量	发出或收到的追加保证金通知数量及金额	前瞻性
超期交易差异数量	超过升级处理时限的交易差异数量	前瞻性
撤销/更正比率	交易撤销和更正数量占交易总数的百分比	滞后性
对账完成率	在目标截止时间前完成的每日对账所占百分比	前瞻性
未解决事件数量	尚未解决的运营事件数量	前瞻性

KRI 阈值。 每个 KRI 都使用红绿灯模型设定阈值级别：

• 绿色。 处于正常运营范围内。除例行监控外，无需采取行动。
• 琥珀色。 接近风险容忍度。应加强监控并展开调查，可能需要管理层关注。开始进行根本原因分析。
• 红色。 超出风险容忍度。需要管理层立即采取行动，向高级管理层或风险委员会升级汇报，并制定包含目标日期的书面整改计划。

交易差异率阈值校准示例：

级别	阈值	行动
绿色	< 每日交易量的 2%	例行监控
琥珀色	每日交易量的 2% - 5%	调查根本原因；提高对账频率
红色	> 每日交易量的 5%	向运营负责人升级汇报；如有必要，暂停新增活动

KRI 趋势跟踪与报告。 持续跟踪 KRI 随时间的变化，以识别趋势。即使某项 KRI 仍处于绿色区域，如果其趋势正向琥珀色区域上升，也比单次读数更具参考价值。提交给管理层的月度 KRI 报告应包含当前值、阈值状态、趋势方向，以及对任何琥珀色或红色指标的说明。

事件管理

交易运营中的运营事件涵盖范围广泛，从轻微的系统故障到影响市场参与的重大服务中断。结构化的事件管理流程可确保响应和解决方式一致。

事件分类（严重程度级别）：

严重级别	定义	示例	响应时间
SEV-1（严重）	完全丧失交易能力或面临重大财务风险	订单管理系统停机；无法向任何交易所路由订单；结算系统故障导致无法完成交割	立即；全员响应
SEV-2（重大）	交易能力显著下降或面临重大财务风险	主要交易所的市场数据馈送故障；无法处理特定订单类型；部分连接中断	15 分钟内
SEV-3（中等）	对交易运营的影响有限；有可用的变通方案	系统性能缓慢；非关键报告功能故障；单一交易对手连接问题	1 小时内
SEV-4（轻微）	对运营的影响极小；无财务风险	UI 外观问题；非紧急报告延迟；不影响交易的轻微数据质量问题	4 小时内

事件响应流程。 标准事件生命周期包括：

1. 检测与报告。 通过监控警报、用户报告、交易对手通知或自动运行状况检查检测事件。
2. 分诊与分类。 评估事件的严重程度、范围和潜在财务影响，并指定严重级别。
3. 沟通。 根据沟通协议通知利益相关方。对于 SEV-1 和 SEV-2，还需通知交易部门负责人、运营管理层、技术领导、合规部门和高级管理层。指定的事件指挥官负责协调响应。
4. 遏制。 立即采取措施，防止事件扩大。这可能包括停止自动交易、切换到手动录入订单、启用备份系统，或通知交易所和交易对手。
5. 解决。 技术团队负责恢复正常运营。对于系统中断，这包括切换到备份系统、重启服务或部署紧急补丁。
6. 恢复。 根本原因解决后，恢复正常运营。对未完成的订单、交易和头寸进行核对。评估中断期间遗漏的交易对客户造成的影响。
7. 事后审查。 开展正式审查，记录根本原因、时间线、影响、响应效果和纠正措施。

升级矩阵。 根据严重级别定义升级路径：

• SEV-1：事件指挥官、CTO/COO、交易主管、首席风险官、CEO（如影响整个市场）
• SEV-2：事件指挥官、技术副总裁、交易运营主管、首席风险官
• SEV-3：技术团队负责人、运营经理
• SEV-4：个人贡献者、主管

根本原因分析技术。 两种广泛使用的方法：

• 5 Whys。 反复追问“为什么”，直到找出根本原因。示例：为什么发生交易错误？因为选错了账户。为什么？因为账户下拉列表中的名称很相似。为什么？因为 UI 没有在名称旁显示账号。为什么？因为公司收购新客户后，从未更新账户显示格式。根本原因：UI 设计不充分，且收购后的系统集成存在不足。
• 鱼骨图（Ishikawa 图）。 将潜在原因分为六个分支：人员、流程、技术、数据、环境和外部因素。逐一检查各分支，找出促成因素。

纠正措施跟踪。 每次根本原因分析都会产生纠正措施。每项措施都会指定负责人、目标完成日期和状态（未开始、进行中、已完成、已验证）。维护纠正措施登记册，并在定期运营风险会议上审查。在独立验证措施有效之前，不得将纠正措施标记为已关闭。

业务连续性与灾难恢复

交易运营必须具备在突发事件期间继续执行关键职能的能力。监管要求（包括 FINRA Rule 4370）规定，经纪交易商必须制定业务连续性计划。

FINRA Rule 4370（业务连续性计划和紧急联系信息）。 每个 FINRA 成员都必须制定并维护书面业务连续性计划（BCP），至少涵盖：数据备份与恢复、所有关键任务系统、财务和运营评估、与客户及监管机构的备用通信方式、备用办公地点、对关键业务相关方的影响、监管报告，以及与监管机构的沟通。若公司的运营、结构、业务或所在地发生重大变化，必须更新该计划。

恢复时间目标（RTO）。 系统中断的最长可接受持续时间，超过该时间后，业务影响将无法接受。对于交易运营，RTO 通常以分钟到小时计：

系统	典型 RTO
订单管理系统	< 30 分钟
市场数据馈送	< 15 分钟
交易所连接	< 15 分钟
风险管理系统	< 1 小时
结算／清算接口	< 2 小时
客户报告系统	< 4 小时

恢复点目标（RPO）。 以时间衡量的最大可接受数据丢失量。RPO 为 5 分钟表示公司最多可以承受丢失 5 分钟的交易数据。对于交易系统，订单和执行数据的 RPO 通常接近零（同步复制），而较不重要的数据则为几分钟。

故障转移程序。 关键系统应具备自动或半自动故障转移能力，可切换到次要环境。包括：主动－被动数据库复制，并自动提升备用数据库；连接交易所和清算公司的冗余网络路径；地理位置分隔的数据中心；以及预先配置的灾难恢复交易环境。

远程交易能力。 公司必须确保交易员和运营人员能够从备用地点开展工作。包括：访问交易系统的 VPN；预先配置的远程交易工作站；经过测试的远程语音通信（交易电话台、录音电话线路）；以及启用远程交易的书面程序。

沟通计划。 发生中断时，公司必须与以下对象沟通：客户（说明订单状态、账户访问方式和备用联系方式）、监管机构（FINRA、SEC、交易所）、交易对手方和清算公司、员工以及关键供应商。应预先制定并测试联系树和沟通模板。

测试要求。 FINRA Rule 4370 要求至少每年审查和测试 BCP。行业最佳实践包括：桌面演练（逐步推演各种情景）、备份系统和故障转移的功能测试、全面模拟演练，以及与交易所和清算公司进行的第三方测试。应记录测试结果，并通过纠正措施解决发现的问题。

技术风险

技术风险是操作风险的一个子集。由于交易运营依赖自动化系统进行订单路由、执行、风险管理和结算处理，因此技术风险尤为突出。

系统可靠性。 交易系统必须达到高可用性标准。关键任务系统的常见目标是 99.95% 的正常运行时间（每年允许停机时间约为 4.4 小时）。可靠性可通过冗余架构、自动化监控、容量规划和定期性能测试来实现。

变更管理。 交易系统的软件和配置变更是导致操作事件的主要原因之一。严谨的变更管理流程包括：记录变更请求、评估影响、在非生产环境中测试、安排部署窗口（高风险变更应避开市场交易时段）、制定回滚程序，以及部署后验证。市场交易时段内的紧急变更需要加快审批，并提高风险意识。

供应商风险管理。 交易运营依赖众多第三方供应商提供市场数据、订单路由、清算、结算和技术基础设施。供应商风险管理包括：在接入供应商前进行尽职调查；制定具有可衡量绩效标准的服务级别协议（SLA）；持续监控供应商的绩效和财务状况；制定供应商故障应急计划；评估集中度风险（避免关键职能过度依赖单一供应商）。

交易系统的网络安全。 交易系统是网络攻击的高价值目标。关键网络安全控制措施包括：通过网络分段隔离交易系统；对系统访问实施多因素身份验证；对传输中和静态存储的数据进行加密；部署入侵检测和防御系统；定期进行渗透测试；制定针对网络安全事件的响应计划。

市场数据系统故障。 市场数据（价格、报价、参考数据）丢失可能导致无法准确为订单定价、计算风险和进行合规检查。公司应当：通过多个供应商维护冗余市场数据源；设置备用定价机制（最近已知价格、带控制措施的手动价格录入）；针对数据过时或缺失设置警报。影响订单路由或执行质量的市场数据故障应归类为操作事件并进行管理。

订单路由系统故障。 无法向交易所或市场中心路由订单，对交易运营而言属于 SEV-1 事件。控制措施包括：与每个执行场所建立冗余 FIX 连接；设置备用订单路由路径；将交易所终端的手动订单录入能力作为最后手段；预先制定向客户告知执行延迟的流程。

示例

references/examples.md 中有三个示例——加载该文件可查看端到端场景：（1）为经纪交易商的交易台构建操作风险框架；（2）设计标准化的交易错误处理和更正流程；（3）为交易运营管理实施 KRI 仪表板。

常见陷阱

• 将操作风险管理视为合规事项，而非业务管理纪律——表格填完了，但风险并未得到积极管理或缓释。
• 未将未遂事件与实际损失一并跟踪，因此错过控制措施恶化的早期预警信号。
• 根据目标而非数据设定 KRI 阈值——阈值长期处于红色会失去公信力，管理层也会置之不理。
• 允许在未记录的情况下更正交易错误，造成隐性风险敞口，并妨碍根因分析。
• 对对账流程投入不足——长期未解决的差异是操作失误和潜在财务损失的先行指标，但相较于处理新交易，解决差异往往被排在次要位置。
• 仅依赖日终对账，而日内头寸监控可以提前数小时发现错误，降低对损益的影响。
• 将业务连续性计划测试当作走过场，而非通过逼真的场景进行测试，因此无法发现实际的恢复缺口。
• 忽视技术变更管理这一操作风险来源——重大事故中有不成比例的数量源自软件部署和配置变更。
• 未建立明确的升级矩阵，导致事故响应临时而为，且会因当班人员不同而有所差异。
• 将所有操作风险事件归为单一类别，而非采用 Basel 分类法，因此无法进行有意义的趋势分析和基准比较。
• 忽视供应商集中风险——单一供应商故障若影响市场数据、订单路由或清算，可能演变为影响全公司的操作风险事件。
• 未跟进整改措施——根因分析提出了建议，但若不跟踪并验证，同样的故障就会反复发生。

交叉引用

• order-lifecycle（trading-operations 插件）：从订单录入到执行的订单生命周期是许多操作风险事件的起源；每个阶段都嵌入了错误检测和预防措施。
• settlement-clearing（trading-operations 插件）：结算失败和清算差异是主要的操作风险类别；结算失败管理流程与操作风险框架密切相关。
• counterparty-risk（trading-operations 插件）：交易对手违约（未交付证券或未支付现金）是一种外部操作风险，与信用风险管理相交。
• trade-execution（trading-operations 插件）：执行质量不佳、路由错误和违反最佳执行要求均属于具有监管影响的操作风险事件。
• pre-trade-compliance（trading-operations 插件）：交易前检查是预防性控制措施，可防止交易错误、未经授权的交易以及违反账户限制。
• post-trade-compliance（trading-operations 插件）：交易后监控可检测逃过交易前控制的错误和异常。
• books-and-records（compliance 插件）：损失事件文档、事故记录和错误账户活动均属于受保留要求约束的监管账簿和记录。
• examination-readiness（compliance 插件）：操作风险框架、事故日志和 BCP 文档是 FINRA 和 SEC 检查人员常见的检查主题。
• privacy-data-security（compliance 插件）：影响交易系统的网络安全事故属于操作风险事件，同时也会触发数据保护和违规通知义务。