3. 风控体系设计原则：分层防御、实时监控、可追溯性、自动化与人工干预结合
做暗池交易这些年，我最大的体会就是：风控不是一道锁，而是一整套防御体系。你想想看，暗池里没有公开订单簿，信息不对称程度比交易所高得多。一旦风控出问题，损失往往不是小数目。
我个人习惯把风控体系拆成四个维度来设计。说白了，就是分层防御、实时监控、可追溯性、自动化与人工干预结合。这四条原则，缺一不可。
3.1 分层防御：别把鸡蛋放在一个篮子里
为什么强调分层？我在项目中遇到过一件事：某家机构只设了一道风控阈值，结果行情剧烈波动时，阈值被瞬间击穿，订单直接冲到交易所去了。嗯，那笔损失够买好几台服务器了。
分层防御的核心思路是：每一层只解决一个特定问题。我一般分四层：
| 层级 | 名称 | 作用 | 响应时间 |
|---|---|---|---|
| L1 | 订单级风控 | 检查单笔订单的合法性（价格、数量、符号） | < 1ms |
| L2 | 账户级风控 | 监控账户总敞口、日内交易次数、净头寸 | < 10ms |
| L3 | 策略级风控 | 检测策略行为异常（如高频撤单、自成交） | < 100ms |
| L4 | 系统级风控 | 全局熔断、连接状态、数据延迟监控 | < 1s |
每一层都有独立的规则引擎和告警通道。L1 出问题，直接拒单；L2 出问题，限制交易；L3 出问题，暂停策略；L4 出问题，整个系统停机。互不干扰，互不依赖。
3.2 实时监控：别等出事了再看日志
实时监控这件事，说起来简单，做起来坑很多。我见过太多团队把监控做成「事后诸葛亮」——数据延迟 5 分钟，等告警出来，行情都变了三波了。
我个人对实时监控的要求是：端到端延迟不超过 50ms。怎么做到？
- 数据管道用流式处理：别用批处理，别用数据库轮询。Kafka + Flink 是标配，延迟能压到 10ms 以内。
- 指标要精简：别什么都监控。我一般只盯 5 个核心指标——订单拒绝率、成交率、撤单率、净敞口、延迟抖动。多了反而看不清。
- 告警要分级：P0 级（系统崩溃）直接打电话；P1 级（阈值超限）发短信；P2 级（趋势异常）发邮件。别把所有告警都搞成「红色警报」，否则没人看。
3.3 可追溯性：每一笔交易都要能「翻旧账」
可追溯性，说白了就是出了问题能查得清。暗池交易的特殊性在于，很多订单是匿名的，一旦发生纠纷，没有完整的日志根本说不清楚。
我要求系统记录以下信息：
- 订单全生命周期：从创建、修改、取消到成交，每一步都要打时间戳。
- 风控决策日志：每条规则触发了什么动作，为什么触发，参数是什么。
- 系统状态快照：每 1 秒记录一次系统状态（CPU、内存、网络、队列长度）。
- 外部数据源：行情数据、参考价格、市场状态，全部归档。
我曾经遇到过一个 case：某笔交易在暗池里成交了，但对手方不认账。我们花了 3 天时间，从日志里还原了当时的订单流、风控决策、行情快照，最终证明是对方系统的问题。如果没有完整的可追溯性，这 3 天根本不可能做到。
3.4 自动化与人工干预结合：机器做判断，人做决策
这个原则我花了好几年才真正理解。一开始我追求全自动化，觉得人太慢、太容易出错。后来发现，有些场景机器根本处理不了——比如市场出现极端行情，或者监管政策突然变化。
我的做法是：自动化处理 95% 的常规情况，人工处理 5% 的异常情况。具体来说：
- 自动化负责执行：规则触发后，自动拒单、自动限流、自动熔断。这些不需要人参与，机器比人快得多。
- 人工负责决策：当系统检测到「未知模式」或「多规则冲突」时，自动暂停交易，并通知风控人员。由人来判断是继续、调整还是停机。
- 人机交互要简洁：我给风控人员设计了一个「一键操作」面板——暂停、恢复、调整阈值、查看日志。所有操作不超过 3 次点击。
3.5 核心逻辑框架图
下面这张图是我自己画的风控体系核心逻辑。你可以看到，四个原则是相互咬合的：
你看，分层防御是骨架，实时监控是眼睛，可追溯性是记忆，自动化与人工结合是大脑。四者缺一不可，互相支撑。