📚 课程目录第3章实时风险限额概述

3. 实时风险限额概述

实时风险限额是交易与风控系统之间的“硬约束层”。它把策略意图、账户资金、市场流动性和合规要求，翻译成系统在毫秒级可以判断的数值边界。没有实时限额，风控只能做事后统计；有了实时限额，系统才能在订单发出前、成交回报后、行情跳变时立即做出拦截、降档或强平决策。本节聚焦四类核心限额——头寸限额、损失限额、集中度限额、杠杆限额，并说明它们如何按层级组织，以及如何映射到具体业务。

一、核心原理：四类限额分别约束什么

限额的本质是“在不确定市场中预先承诺风险边界”。不同限额约束的风险维度不同，必须组合使用，否则会出现“单看每个指标都合规，整体风险却失控”的情况。

头寸限额（Position Limit）：约束某一标的、某一方向或某一合约的持仓数量或名义价值。它防止单边敞口过大，是最基础、最直观的限额。例如“BTC-USDT 永续合约净头寸不超过 500 万美元名义价值”。
损失限额（Loss Limit）：约束已实现亏损、未实现亏损或当日累计亏损。它直接对应“还能亏多少”，通常分为日内损失限额、滚动窗口损失限额和最大回撤限额。触发后往往要求降仓或停止开新仓。
集中度限额（Concentration Limit）：约束资金或风险敞口在单一标的、单一行业、单一交易对手或单一策略上的占比。它防止“把鸡蛋放在一个篮子里”，尤其适用于多策略、多账户组合。
杠杆限额（Leverage Limit）：约束总名义敞口与净权益的比值，或保证金占用与可用资金的比例。它控制资金放大倍数，避免在极端行情下因保证金不足被强制平仓。

关键关系：头寸限额管“方向与规模”，损失限额管“亏损速度与深度”，集中度限额管“分散程度”，杠杆限额管“资金放大倍数”。四者共同构成实时风控的约束空间。

二、限额层级与业务映射

限额不能只挂在最底层账户上，否则无法支持多层级业务管理。典型做法是按“集团—业务线—策略—账户—标的”五层组织，每层设置独立限额，并遵循“下层限额之和不超过上层”的约束。这样既能做全局风险预算，又能把责任落到具体交易单元。

层级	典型对象	主要限额类型	业务映射示例
集团层	整个公司或基金	总损失限额、总杠杆限额	全公司当日最大亏损 200 万美元，总杠杆不超过 5 倍
业务线层	现货、合约、期权、做市	损失限额、集中度限额	合约业务线日内亏损不超过 80 万美元，单币种集中度不超过 30%
策略层	趋势、套利、高频、中性	头寸限额、损失限额	趋势策略单标的净头寸不超过 100 万美元，滚动 1 小时亏损不超过 20 万美元
账户层	子账户、交易员账户	杠杆限额、头寸限额	子账户杠杆不超过 3 倍，单笔下单不超过 50 万美元
标的层	BTC、ETH、特定合约	头寸限额、集中度限额	BTC 永续净头寸不超过 500 万美元，占组合名义价值不超过 25%

业务映射的关键是“限额跟着业务责任走”。例如做市业务需要高频双边报价，头寸限额可以放宽，但集中度和杠杆限额必须收紧；趋势策略允许较高头寸限额，但损失限额要更敏感。限额不是一套固定数字，而是随业务目标动态调整的风险预算。

三、方法流程：实时限额如何落地

实时限额不是静态配置，而是一条从“定义—计算—校验—触发—恢复”的闭环链路。以下流程是工程实现的核心骨架：

限额定义：在配置中心按层级、业务线、策略、账户、标的定义限额值、时间窗口和触发动作。配置需版本化，支持热更新。
实时计算：行情、成交、持仓、资金数据流入流计算引擎，持续计算当前头寸、累计亏损、集中度比例和杠杆倍数。
订单校验：新订单进入风控网关时，先做“预校验”：假设该订单成交后，各项指标是否突破限额。若突破则拦截或降量。
触发动作：根据突破程度执行不同动作：警告、禁止开仓、强制减仓、全部平仓。动作需可配置、可审计。
恢复与复盘：当指标回到限额内并满足冷却时间后，自动或手动恢复交易权限，同时记录触发日志用于复盘。

# 限额配置示例（YAML）
limits:
  - level: strategy
    name: trend_btc
    position_limit: 1000000   # 名义价值 USD
    loss_limit_1h: 200000
    leverage_limit: 3.0
    action: block_open
  - level: account
    name: sub_acc_01
    position_limit: 500000
    leverage_limit: 2.5
    action: reduce_only

工程提示：预校验必须与成交后校验使用同一套计算逻辑，否则会出现“下单时通过、成交后超限”的漏洞。建议将限额计算封装为无状态服务，输入订单和当前快照，输出是否允许及允许的最大数量。

四、案例与误区复盘

案例场景：某量化团队在 BTC 永续合约上运行趋势策略，设置了单策略头寸限额 100 万美元、日内损失限额 20 万美元、杠杆限额 3 倍。某日行情剧烈波动，策略在 10 分钟内连续开仓，头寸达到 95 万美元，未实现亏损迅速扩大到 18 万美元。此时系统检测到：若继续开仓 10 万美元，头寸将突破 100 万，且杠杆将达到 3.2 倍。风控网关立即拦截新开仓订单，并触发“只减仓”模式。随后行情继续恶化，累计亏损达到 20 万美元，系统自动平掉 30% 头寸，将风险敞口降至限额内。整个过程在 200 毫秒内完成，避免了更大回撤。

常见误区：

只设头寸限额，不设损失限额：头寸没超，但亏损已经失控。头寸和损失必须成对出现。
限额层级扁平化：所有限额都挂在账户上，导致业务线无法做整体风险预算，也无法定位责任。
忽略时间窗口：损失限额只算当日，不算滚动 1 小时，导致短时间连续亏损无法被及时拦截。
预校验与成交后校验不一致：下单时用简化公式，成交后用完整公式，造成“漏网之鱼”。
恢复条件过于宽松：触发后立即恢复，没有冷却时间，导致反复触发、反复恢复，系统震荡。

复盘要点：每次限额触发都应记录“触发层级、触发指标、当前值、限额值、订单快照、市场行情、执行动作”。这些数据是优化限额参数、调整业务映射的直接依据。没有日志的限额系统，无法迭代。

实时风险限额的设计，本质是在“业务效率”和“风险控制”之间寻找动态平衡。四类限额从不同维度约束风险，五层结构把风险责任映射到具体业务单元，而实时计算与预校验则保证约束在毫秒级生效。只有把类型、层级和业务映射三者打通，Kill Switch 才有可靠的触发依据，整个风控体系才能真正闭环。