"风控系统"这个词在券商语境里是个集合名词。真正落地的不是一个大而全的系统，而是三道按时间轴排开的防线，每道防线的检查时机、延迟预算、数据视角完全不同。理解券商风控的第一步是放弃"一个系统管住所有风险"的想象——这篇按时间轴讲三道防线各自在干什么、为什么只能在那里干。
三道防线的时间轴位置
时间轴的原点是委托。一笔委托从客户发出到最终交收，风控检查分布在三个时点：
事前：委托进入撮合前。这是唯一一道能"拦住"委托的防线——检查不通过，委托根本不进订单簿。所有硬性限制都在这里：可用资金够不够、持仓是否超限、账户状态是否正常、是否在黑名单上。它的延迟预算是最苛刻的：整个检查链路要压在亚毫秒到毫秒级，因为柜台每多耗 1 毫秒，就是在和客户体验、和极速对手的延迟竞赛中退一步。
事中：交易进行中。委托已经在撮合，防线退而求其次：不再拦单笔委托（拦不起，拦了就是改交易结果），而是监控行为模式——这个账户是不是在对倒、是不是在拉抬打压、撤单率是不是异常。发现的是"模式异常"，处置手段是冻结、限制、上报，而不是拒单。
事后：收盘之后。所有能慢下来的检查都在这里：日终对账、持仓集中度复核、异常交易的批量分析、风控报表。事后防线的数据视角最全——开盘时不知道收盘价，收盘后什么都知道了——代价是处置已经滞后，它的价值在于发现和追责，以及给前两道防线反哺规则。
预算与精度：为什么防线不能错位
三道防线的差异可以用一个二维坐标看清楚：延迟预算和数据精度。事前防线延迟预算亚毫秒、精度受限（行情用的是缓存快照，账户余额用的是预估值）；事后防线延迟预算是小时级、精度最高（收盘价、最终成交、全量数据）。这两个维度的约束决定了检查项目只能长在自己负担得起的那道防线上。
一个典型的错位例子：把"持仓集中度"检查放在事前链路。集中度 = 单一证券市值 / 总资产，分子分母都要实时市值，而事前链路拿到的行情是快照、总资产是上一刻的预估值——算出来的集中度本身就有误差，为这个有误差的数字去拒客户的单，业务上无法接受。所以集中度的硬限制通常放在开户/授信的准事前环节（低频、允许分钟级延迟），盘中只做软提示或放到事后复核。反过来，把"可用资金校验"放到事后，等于允许透支交易发生——那是结算风险，不是风控了。
所以设计上的结论是：先给每类检查定"必须在哪道防线"，再谈怎么做。判据就是两个：这笔检查拦不住会怎样（决定必须在事前还是可以在事后），以及这个检查的计算代价和数据新鲜度要求（决定它塞不塞得进事前链路）。《事前风控检查链路》那篇专门展开事前侧的实现，这里只需要知道这个总图的分配逻辑。
风险类型 vs 防线：一张错配的映射表
另一个容易混淆的维度是风险类型。教科书把风险分成信用风险、市场风险、操作风险、合规风险，但落到系统上，每种风险的防线归属是错配的：
- 信用风险（客户欠的钱收不回来）：主战场在事前（融资融券的保证金比例、平仓线）和事后（负债账户的每日盯市复核）；
- 市场风险（持仓随行情贬值）：防线几乎全在事后——风险价值（VaR）计算用日频数据，盘中只能靠限额类的事前规则近似；
- 操作风险（内部流程出错）：事前防不了自己不知道的规则，主战场是事后的事后监督、双人复核和审计日志；
- 合规风险（违反交易规则）：三道防线分摊——事前挡黑名单，事中监控异常交易，事后生成合规报表和可疑交易报告。
系统形态：三道防线的物理长相
落到物理部署上，三道防线的系统形态也很不一样。事前防线是柜台内嵌模块——和委托处理同一个进程（至少同一个机房、同一条网络路径），任何跨进程的调用都会吃掉宝贵的微秒；事中防线是旁路系统——行情和回报数据通过消息队列复制一份出来，监控规则在独立集群上跑，挂了不影响交易主链路，这是它和事前防线的本质区别：事前必须在内，事中必须在外；事后防线是数据仓库式的批处理平台——接清算数据、行情数据、账户数据，跑分析和报表，性能要求最低、数据最全。
这个"内-外-仓"的三段式结构，本质是把"不能慢"和"不能错"和"要全"三个互相冲突的目标拆给三个系统，各自在自己的约束里做到最好。后面几篇按防线逐个展开实现细节。