风险引擎设计方法

1. 设计目标

在策略图系统中，风险引擎不建议只设计成一个简单的配置对象。更合理的方式是按照交易生命周期和账户状态，将风险控制明确拆分为四类规则：

1. pre_trade：交易前风控
2. in_flight：订单执行中风控
3. post_trade：成交后校验
4. state_events：状态事件风控

这种拆分方式可以让每类规则拥有清晰的触发时机、职责边界和处理动作，避免把下单限制、订单监控、成交校验和止损逻辑混在同一个配置对象中。

2. 总体配置结构

{
  "risk": {
    "pre_trade": {},
    "in_flight": {},
    "post_trade": {},
    "state_events": {}
  }
}

四类规则分别覆盖以下风险控制阶段：

3. pre_trade：交易前风控

3.1 作用

pre_trade 负责在订单提交前进行风险检查和订单约束，决定：

• 订单是否允许提交；
• 订单最大允许规模；
• 是否需要裁剪订单数量；
• 是否需要直接拒绝订单；
• 下单后是否会突破仓位、杠杆或敞口限制。

3.2 示例配置

{
  "pre_trade": {
    "max_position_weight": 0.5,
    "max_leverage": 1.0,
    "max_order_weight": 0.1,
    "max_gross_exposure": 1.0,
    "max_net_exposure": 0.8,
    "allow_short": false
  }
}

3.3 字段说明

3.4 建议处理流程

1. 接收策略生成的目标订单；
2. 读取当前账户、持仓、挂单和风险状态；
3. 计算订单执行后的预期仓位、杠杆和敞口；
4. 按风险规则判断订单是否合规；
5. 根据结果执行以下动作之一：
   • 允许提交：按原始数量下单；
   • 裁剪后提交：将订单调整到允许的最大规模；
   • 拒绝提交：不发送订单并记录原因。

pre_trade 的核心是控制“订单进入市场之前的最大风险”。

4. in_flight：订单执行中风控

4.1 作用

in_flight 负责监控已经提交但尚未完全成交的订单，处理订单执行期间风险额度的占用和风险条件变化。

它主要回答以下问题：

• 未成交订单是否占用风险额度；
• 订单挂单时间过长是否应自动撤销；
• 风险条件变化后，是否停止或撤销剩余订单；
• 账户进入暂停或限制状态后，未成交订单如何处理。

4.2 示例配置

{
  "in_flight": {
    "reserve_pending_orders": true,
    "cancel_on_limit_breach": true,
    "max_order_age_seconds": 60,
    "cancel_unfilled_on_halt": true
  }
}

4.3 字段说明

4.4 建议处理流程

1. 订单提交成功后登记订单状态；
2. 根据配置预留订单可能占用的仓位和敞口；
3. 持续监听订单成交、撤单、拒单和超时事件；
4. 定期重新计算账户风险状态；
5. 当订单超时或风险条件突破时，执行撤单、停止追加订单等动作；
6. 订单完全成交或终止后，释放相应的预留额度。

in_flight 的核心是控制“订单已经发出，但风险尚未完全落地期间的中间状态”。

5. post_trade：成交后校验

5.1 作用

post_trade 负责在订单成交后，对真实成交结果、持仓状态和风险限制进行再次校验。

它主要回答以下问题：

• 实际成交后是否突破仓位、杠杆或敞口限制；
• 本地记录的持仓是否与经纪商或交易所持仓一致；
• 成交回报是否及时到达；
• 发生超限或状态不一致时，应停止交易、告警还是自动减仓。

5.2 示例配置

{
  "post_trade": {
    "breach_action": "reduce_only",
    "reconcile_position": true,
    "max_reconciliation_delay_seconds": 5
  }
}

5.3 字段说明

5.4 建议处理流程

1. 接收成交回报；
2. 更新本地订单、成交和持仓状态；
3. 重新计算账户仓位、杠杆和总敞口；
4. 与经纪商或交易所返回的实际持仓进行对账；
5. 若发现超限或状态不一致，根据 breach_action 执行：
   • 停止交易：禁止继续提交新的风险订单；
   • 告警：记录并通知人工处理；
   • 只减仓：禁止增加风险，只允许降低现有仓位；
   • 自动减仓：通过反向订单将风险恢复到限制以内。

post_trade 的核心是校验“交易实际发生后，账户最终处于什么风险状态”。

6. state_events：状态事件风控

6.1 作用

state_events 用于处理由价格、账户净值、回撤或策略运行状态触发的事件型风控规则。

与前三类规则相比，state_events 不一定由某一笔订单直接触发，而可能由持续的市场数据和账户状态变化触发。

它主要覆盖：

• 价格触发的止损；
• 账户触发的最大回撤；
• 触发后减仓、平仓、暂停交易或进入冷却期；
• 风控事件解除后的恢复条件。

6.2 示例配置

{
  "state_events": {
    "stop_loss": {
      "type": "percentage",
      "value": 0.08,
      "action": "close_position"
    },
    "max_drawdown": {
      "value": 0.2,
      "action": "reduce_all_positions"
    },
    "cooldown_after_stop": {
      "bars": 10
    }
  }
}

6.3 字段说明

6.4 常见动作

• close_position：平掉触发事件的持仓；
• reduce_position：降低部分仓位；
• reduce_all_positions：降低全部策略或账户仓位；
• halt_strategy：暂停策略运行；
• halt_trading：暂停账户或交易通道下单；
• reduce_only：进入只减仓模式；
• cooldown：进入冷却期，冷却期内不允许重新开仓。

state_events 的核心是控制“账户或策略状态发生重大变化后的保护动作”。

7. 四类风控的协同关系

四类风控不是相互替代，而是共同构成完整的风险闭环：

策略产生目标订单
        |
        v
[pre_trade] 交易前检查、裁剪或拒绝
        |
        v
订单提交与执行
        |
        v
[in_flight] 监控挂单、预留额度、超时撤单
        |
        v
订单成交
        |
        v
[post_trade] 成交后校验、持仓对账、超限处理
        |
        v
[state_events] 监听止损、回撤、暂停和冷却事件
        |
        +------------------------------+
        |                              |
        +--> 触发减仓、平仓、暂停或冷却 --+

建议将风险判断设计成多层保护：

1. 提交前先拦截：避免明显违规的订单进入市场；
2. 执行中持续约束：防止挂单累积、订单超时或风险变化造成失控；
3. 成交后再次校验：以实际成交和真实持仓为准；
4. 状态事件兜底：在止损、回撤等重大事件发生时执行保护动作。

8. 建议的规则返回结果

为了方便策略图系统统一处理，风险引擎可以让每类规则返回结构化结果，而不是只返回布尔值。

{
  "allowed": false,
  "action": "reduce_only",
  "original_quantity": 100,
  "approved_quantity": 0,
  "reason_code": "MAX_NET_EXPOSURE_BREACH",
  "message": "订单将导致净敞口超过限制",
  "risk_snapshot": {
    "current_net_exposure": 0.75,
    "projected_net_exposure": 0.92,
    "max_net_exposure": 0.8
  }
}

建议至少包含以下信息：

这样可以同时满足策略执行、日志审计、监控告警和问题排查的需求。

9. 设计原则总结

1. 按交易生命周期拆分规则：将提交前、执行中、成交后和状态事件分开管理；
2. 风险判断与动作解耦：先计算是否违规，再决定拒绝、裁剪、撤单、减仓或暂停；
3. 以实际持仓为最终依据：成交后必须支持与经纪商或交易所对账；
4. 未成交订单也要纳入风险计算：避免多个挂单同时占用未来风险额度；
5. 所有风控动作都应可审计：保留规则版本、风险快照、触发原因和执行结果；
6. 重大事件需要状态机支持：止损、最大回撤和冷却期不应只作为一次性函数调用，而应有明确的进入、持续和退出状态；
7. 默认采用保守失败策略：风险状态不可确认、持仓对账超时或数据源异常时，优先停止增加风险。

通过以上四类规则，风险引擎可以从简单的参数校验，升级为覆盖订单生命周期、真实持仓和策略状态的完整风险控制系统。