一、风控体系总览:做市商风控的核心目标、架构图与系统关系

做市商这行,说白了就是在刀尖上跳舞。我做了这么多年风控系统,见过太多团队因为风控没搭好,一夜回到解放前。今天咱们就聊聊风控体系的总览,把骨架先立起来。

1.1 做市商风控的核心目标

风控不是用来限制交易的,而是用来保命的。我个人习惯把核心目标归纳为三点:

  • 防止爆仓:这是底线。仓位管理不当、杠杆过高、黑天鹅事件,任何一个都能让你归零。我见过一个团队,策略收益很好,但一次极端行情下风控没触发,直接穿仓。
  • 控制回撤:盈利可以慢慢来,但回撤必须管住。日内回撤超过5%,我建议立即停下来检查。
  • 合规与审计:交易所、监管机构的要求越来越严。你的风控日志、交易记录,必须能随时拿出来说清楚。

核心公式:风控 = 生存概率 × 盈利稳定性

没有生存,一切归零。

1.2 风控体系架构图

下面这张图是我自己画的风控体系架构,用了很多年,一直在迭代。你想想看,一个完整的做市商风控系统,应该长什么样?

做市商风控体系架构图 交易层(Trading Layer) 订单管理 | 报价引擎 | 策略执行 | 交易所接口 风控层(Risk Control Layer) 仓位风控 净头寸/敞口限制 资金风控 保证金/杠杆监控 订单风控 频率/价格偏离检查 市场风控 波动率/流动性 监控与告警层(Monitoring & Alerting) 实时指标看板 | 多级告警(短信/邮件/钉钉) | 日志审计 数据层(Data Layer):行情数据 | 交易数据 | 风控规则配置

嗯,这张图我建议你保存下来。每一层都有它的职责,层与层之间通过API或消息队列通信。我在搭建第一个版本时,把风控逻辑直接写在交易引擎里,结果改个规则要重启整个系统,太痛苦了。

1.3 风控与交易系统的关系

很多人以为风控是交易系统的附属品,其实不是。它们应该是松耦合的关系。我举个例子:

我的经验:风控系统应该独立部署,有自己的数据库和计算资源。交易系统发订单前,先问风控系统“这个单子能不能发?”风控系统说“行”,交易系统才发。这叫“前置风控”。

为什么会这样?因为如果风控和交易耦合太紧,一旦风控模块出问题,交易也跟着挂。我曾经遇到过,风控规则里有个死循环,直接把交易进程拖死了,那叫一个惨。

具体来说,风控与交易系统的关系可以总结为:

维度 交易系统 风控系统
职责 执行策略、赚取利润 限制风险、保障安全
响应速度 微秒级(高频场景) 毫秒级(可接受延迟)
部署方式 与交易所同机房 可独立部署
数据流向 订单 → 交易所 拦截/放行 → 交易系统
故障影响 交易中断 风控失效(需降级处理)

避坑指南:我曾经把风控系统的数据库和交易系统的数据库放在同一个实例上。结果风控跑一个复杂查询,把CPU占满了,交易延迟飙升。后来我强制要求:风控和交易必须物理隔离。

1.4 风控规则的执行顺序

你想想看,一个订单进来,风控系统要检查哪些东西?顺序很重要。我个人习惯按这个顺序来:

  1. 前置检查:账户状态是否正常?交易对是否在白名单?
  2. 资金检查:保证金够不够?杠杆是否超限?
  3. 仓位检查:净头寸是否超过限制?多空比例是否合理?
  4. 订单检查:价格是否偏离市场太远?频率是否过高?
  5. 市场检查:当前波动率是否异常?流动性是否充足?

这个顺序不是随便定的。前置检查最快,能快速过滤掉明显不合规的订单。越往后检查越重,但命中率也越低。说白了,就是先做轻量级过滤,再做重量级分析。

核心原则:风控规则要分层,每层都有独立的超时机制。如果某层检查超时,默认拒绝订单,并触发告警。这叫“fail closed”,宁可错杀,不可放过。

1.5 一个简单的风控检查代码示例

下面是一个伪代码示例,展示风控系统如何与交易系统交互:

// 交易系统发起订单请求
function placeOrder(order) {
    // 1. 调用风控系统进行前置检查
    riskResult = riskControl.check(order);
    
    // 2. 根据风控结果决定是否执行
    if (riskResult.passed) {
        return exchange.sendOrder(order);
    } else {
        log.warn("订单被风控拦截: " + riskResult.reason);
        alert.send("风控告警: " + riskResult.reason);
        return null;
    }
}

// 风控系统核心检查逻辑
function check(order) {
    // 资金检查
    if (order.amount > getAvailableBalance(order.account)) {
        return {passed: false, reason: "资金不足"};
    }
    
    // 仓位检查
    if (getNetPosition(order.symbol) + order.side * order.amount > maxPosition) {
        return {passed: false, reason: "仓位超限"};
    }
    
    // 价格偏离检查
    if (Math.abs(order.price - getMidPrice(order.symbol)) / getMidPrice(order.symbol) > 0.01) {
        return {passed: false, reason: "价格偏离过大"};
    }
    
    return {passed: true};
}

这段代码看着简单,但实际生产环境要复杂得多。比如要考虑并发、缓存、熔断等。我建议你从简单开始,逐步迭代。

1.6 总结

风控体系总览,说白了就是三件事:目标、架构、关系。目标决定了你要做什么,架构决定了你怎么做,关系决定了系统能不能稳定运行。

我个人觉得,做市商风控最忌讳的就是“事后诸葛亮”。等出事了再补风控,代价太大了。一定要在系统设计之初就把风控考虑进去,哪怕一开始简单点,也比没有强。

嗯,这一章就到这里。记住:风控不是成本,是保险。你永远不知道黑天鹅什么时候来,但你可以确保自己活着看到明天的太阳。


公众号:蓝海资料掘金营,微信deep3321