为什么风控模块必须独立于交易执行之外
在金边做软件开发的第12年，我们团队28个人每年交付大约100个项目，其中金融/交易类系统占比不小，客户分布在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚这几个市场。交易类系统里，股票交易系统对稳定性要求最高。原因不复杂：策略可以慢慢迭代，但风控只要在极端行情下失效一次，账户就可能直接归零。我们经手过的故障案例里，高频场景下的滑点、量化策略的连续回撤、交易所API突然断连，这三类占了绝大多数。
早期我们也尝试过把风控逻辑直接写进交易执行代码里。功能测试能过，但问题出在压力场景下：行情波动一大，并发订单量上来，风控判断本身开始消耗执行线程的CPU时间，下单延迟明显增加，甚至出现过风控规则因为线程被占满而没来得及执行的情况。后来我们把风控模块拆出来独立部署，与交易执行引擎之间通过消息队列异步通信。执行引擎只负责把订单请求写入队列，风控服务消费队列消息并返回通过或拒绝。这样风控服务即使出现延迟，队列会堆积，但交易主链路不会被阻塞，订单要么等待要么被降级处理。这套架构在金边和胡志明市的两个交易类项目里跑过之后，订单链路的稳定性改善是显著的——不是说延迟降到了某个绝对值，而是极端行情下不会再出现“执行线程被风控拖死”这种最坏情况。
还有一个边界条件必须提前定好：如果风控服务完全不可用，系统强制进入只读模式——只允许平仓，禁止开仓。这个逻辑要在设计阶段就写进状态机，不能等到故障发生时才临时决定。主备冗余切换可以解决大部分可用性问题，但切换本身也有时间窗口，在这个窗口期内只读模式是最后一道防线。我们在给菲律宾一个客户做系统时，主备切换的窗口期设的是【此处待填：主备切换时间窗口的具体设计值】，这个值需要根据客户对可用性的要求单独调整。
订单进入系统前的第一道闸：事前校验
事前风控的目标是把不合规的订单挡在系统之外。我们用责任链模式串联多个校验器，每个校验器独立返回通过或拒绝，拒绝时附带原因码，后续校验器不再执行。校验器的执行顺序是固定的，资金校验在前，因为资金不足是最基础的硬性拦截条件，先拦下来能省掉后面所有校验的开销。
- 资金校验：检查可用余额是否覆盖订单金额和手续费。余额不足直接返回拒绝，不进入后续链路。
- 持仓限制校验：防止对同一标的重复下单，以及单只股票仓位超过总资产设定的比例上限。配置值由客户根据策略确定，系统里作为参数下发。
- 价格偏离校验：订单价格与最新成交价偏离超过阈值时自动拦截。这个阈值需要根据标的的流动性和波动特征来设，不能所有标的用同一个值。我们在柬埔寨本地做的一批交易系统里，不同标的的偏离阈值是分开配置的，高波动标的的阈值明显放宽。
- 交易时段校验：只在连续竞价时段放行订单，集合竞价和休市期间的请求直接拒绝。不同市场的时段规则不一样，A股是9:30–11:30和13:00–15:00，东南亚各市场的时段需要单独配置。越南胡志明交易所和河内交易所的时段就与柬埔寨证交所不同，这些差异在配置层解决，不写死在代码里。
量化策略还需要一层动态参数控制，比如同时持有的股票品种数上限、单笔交易最大可接受亏损绝对值、账户净值从峰值回撤超过设定比例时自动降低杠杆或暂停新开仓。这些参数必须支持运行时热更新，通过配置中心下发，不需要重启系统。策略调整时改参数而不是改代码，这是我们在多个交易类项目里反复验证过的做法——一个参数从下发到生效的延迟通常在秒级以内，具体值取决于配置中心的推送机制，但足够应对策略调整的节奏。
订单执行中的安全气囊：实时监控与自动熔断
事前校验只能挡住静态风险，真正的考验在事中。行情是实时变化的，持仓盈亏每一秒都在波动，系统必须在极短时间内做出响应。我们采用事件驱动架构：行情推送事件触发风控评估函数，评估结果再驱动后续操作，比如撤单、报警或触发熔断。在金边给东南亚客户做这套架构时，网络质量确实参差不齐——柬埔寨本地到越南、印尼的跨境链路延迟波动比国内大得多，事件链路里对延迟的容忍度必须单独设计，不能假设行情永远准时到达。
事中监控的核心指标有几个：
- 盯市盈亏：每笔持仓的浮动盈亏是否触及预设止损线。止损线作为可配置参数，不同策略可以设不同值。
- 成交量异常：监控单位时间内的成交量变化，异常放量时触发预警并暂停该标的的交易。判定阈值需要结合标的的历史成交分布来设定，我们在印尼一个项目里用过去30个交易日的分时成交量分布作为基准线，偏离超过一定倍数即触发预警。
- 流动性风险：监控买卖盘口深度，当盘口深度不足以承接当前订单规模时，标记为低流动性资产，限制大额交易。
当监控指标触发时，系统需要自动执行几类操作：
- 全局熔断：账户当日总亏损达到预设阈值时，立即取消所有未成交订单，禁止新订单提交，直到人工介入解锁。
- 局部撤单：单个标的短时间内价格波动异常，自动撤销该标的所有在途订单，并挂出限价止损单。
- 滑点保护：市价单实际成交价与预期价格偏离超过阈值时，取消剩余未成交部分，避免继续扩大损失。
熔断指令的优先级必须最高，不能因为网络延迟或队列阻塞导致熔断指令发不出去。实现上用独立的线程池来处理熔断相关操作，与常规订单处理线程池隔离。主备切换的时序也要提前设计好：主风控服务延迟超过阈值时，备用节点接管，接管期间的新订单默认进入只读模式，直到状态同步完成。这里有一个工程细节值得强调：熔断指令走的通信通道要和普通订单通道分开，否则高峰期通道拥堵时，熔断指令可能排在普通订单后面出不去。我们在架构评审时把这一点作为硬性检查项。
事后风控：日志怎么记才有用
很多系统有日志，但出了问题查不出来。原因在于日志记得太随意。股票交易系统的事后审计对日志有明确要求：每条订单、撤单、成交、风控事件都要记录结构化日志，字段至少包括时间戳（精确到微秒）、订单ID、标的代码、买卖方向、触发风控规则、执行动作、结果状态。另外还要记录系统资源快照——CPU、内存、网络延迟——用于排查是不是系统瓶颈导致风控失效。
日志写入独立的磁盘分区，保留至少90天。这是为了满足监管检查和策略回溯的需要。我们给东南亚客户做系统时，越南、菲律宾的金融监管对日志保留时长有明确要求，90天是一个比较通用的底线。柬埔寨本地【此处待填：柬埔寨金融监管对交易系统日志保留的具体要求】，不同客户会按监管口径调整保留周期。日志量本身也是要考虑的问题：一个中等活跃度的股票交易账户，每天产生的结构化日志条目在数万到数十万条级别，磁盘规划时要按这个量级预留空间，否则90天保留期都撑不满。
风控策略本身也需要验证
风控规则不是写完了就一劳永逸。每轮策略更新后，我们建议客户做三类验证：
- 历史回测：把风控规则应用到过去1年的行情数据上，看是否过度触发（误杀正常交易）或触发不足（该拦的没拦住）。
- 压力测试：模拟极端行情，比如2015年股灾、2020年熔断那种级别，观察风控系统在超高并发下的响应延迟和判断正确性。
- 故障注入测试：人为制造API断连、行情延迟、数据库写入失败等异常，验证熔断机制是否按预期执行。这类测试我们通常建议每个季度做一次。
回测数据的选择有讲究。东南亚市场和A股的相关性并不完全一致，直接用A股的历史极端行情来验证东南亚标的的风控规则，结论可能偏差很大。我们给越南客户做回测时，用的是胡志明交易所的历史数据，而不是拿A股数据代替。这个细节容易被忽略，但直接影响风控参数的有效性。
从设计到落地的一些实际考虑
我们在东南亚多个市场交付过交易类系统，不同市场的交易规则、监管要求差异很大，但风控架构的核心逻辑是相通的。有几点经验可以分享：
一是风控模块和交易执行引擎之间保持低耦合。消息队列异步交互，风控逻辑永远不阻塞交易通道。二是主备冗余。部署主备两套风控服务，主服务延迟超过阈值自动切换到备用节点。三是保留人工干预接口。管理员可以手动触发熔断或覆盖风控规则，但所有人工操作必须记录日志并双人复核，防止单人误操作或恶意操作。
关于开发周期，我们团队的实际经验是：小项目几天可以交付，大项目从需求确认到上线大约2个月。电商类系统我们有成品可以直接部署，开箱即用，交付很快，部分成品系统在柬埔寨本地已有几十家客户在运营使用。但股票交易系统因为涉及交易所接口、行情源接入和复杂的风控规则，通常需要按具体需求定制，开发周期一般在2个月这个量级，具体取决于交易所接口的复杂度和风控规则的精细程度。报价方面，我们根据功能清单逐项评估，面谈或通过Telegram详谈都可以。付款方式是先付30%启动，验收后结清尾款。系统上线后，Telegram分钟级响应，有AI运维辅助日常监控；bug修复免费，新增功能按实际工作量计费。支付通道由客户自己提供资源，我们负责技术对接，不提供支付通道本身。服务语言是中文，柬语和英语沟通【此处待填：是否需要本地语言支持的具体说明】。