合规是量化交易里唯一没有技术上限、但有硬性下限的领域。技术做得再好,一次合规事故就可能让整个业务停摆。程序化交易报备、异常交易监控、信息隔离、审计留痕——这些要求不是「建议」,而是「不做就不能交易」的前置条件。
真正难的地方在于合规要求是「结果导向」的:监管不会规定你必须用什么技术,只会检查「你有没有做到」。这意味着工程实现有很大的自由度,但也意味着你需要自己证明合规性。留痕、可回溯、可举证,是合规系统的三个核心能力。
本文按「框架 → 报备 → 异常交易 → 公平交易 → 反洗钱 → 留痕 → 跨境 → 实现 → 自查」的顺序展开。风控层面的实时限额在 交易风控与实时限额 中讨论,本文聚焦监管要求的落地。
目录
- 监管框架与适用范围
- 程序化交易报备
- 异常交易行为认定
- 公平交易与信息隔离
- 反洗钱与投资者适当性
- 审计留痕要求
- 跨境与多市场合规
- 合规系统的技术实现
- 内部自查与检查应对
1. 监管框架与适用范围
不同市场的监管框架差异很大,同一套系统在不同市场要满足不同要求:
| 市场 | 主要监管 | 程序化交易要求 |
|---|---|---|
| A 股 | 证监会、交易所 | 报备 + 报告 + 监控 |
| 期货 | 证监会、期货交易所 | 报备 + 限额 + 报告 |
| 港股 | SFC | 算法交易申报 |
| 美股 | SEC、FINRA | 算法交易报告、市场准入规则 |
| 欧洲 | ESMA、MiFID II | 算法交易授权、RTS 6 |
监管的适用性判断是第一件事:你的策略属于「程序化交易」还是「高频交易」?两者的要求不同。
程序化交易:通过计算机程序自动生成或下达交易指令
高频交易:程序化交易中,具备以下特征之一的
1. 报单速率、撤单速率达到较高水平
2. 单账户每秒申报、撤单笔数达到一定标准
3. 日内报单、撤单笔数达到一定标准
不同交易所的具体门槛不同(如每秒 300 笔、日内 2 万笔),但只要触及门槛就必须按高频交易报备,要求更严格。
2. 程序化交易报备
报备是准入条件,不是事后补办。报备内容通常包括:
1. 交易者信息:账户、身份、联系方式
2. 交易策略类型:套利、做市、趋势等
3. 交易软件信息:名称、版本、开发商
4. 接入方式:柜台、API、托管
5. 风控措施:限额、熔断、异常处置
6. 负责人员:交易负责人、技术负责人
报备信息变更时必须及时更新,尤其是策略类型和交易软件的变更。未报备或报备不实是常见的处罚事由。
技术系统的支撑:报备信息应该从系统配置中自动生成,而不是人工填写。人工填写容易与实际情况脱节。
def generate_filing_info(config, software_info, accounts):
return {
'accounts': [a.id for a in accounts],
'strategies': [{
'name': s.name,
'type': s.type, # 套利/做市/趋势
'max_order_rate': s.max_rate,
'symbols': s.universe,
} for s in config.strategies],
'software': {
'name': software_info.name,
'version': software_info.version,
'vendor': software_info.vendor,
},
'risk_controls': {
'order_limit': config.limits.max_order_amount,
'daily_loss_limit': config.limits.max_daily_loss,
'circuit_breaker': config.circuit_breaker.enabled,
},
}
3. 异常交易行为认定
异常交易是监管监控的重点。交易所会从多个维度识别,你的系统也应该自查:
| 行为 | 特征 | 认定标准(示例) |
|---|---|---|
| 频繁撤单 | 撤单率极高 | 撤单率 > 80%,日均撤单 > 5000 笔 |
| 大额申报 | 单笔申报量巨大 | 超过市场同期均量的 N 倍 |
| 涨跌幅异常 | 拉抬或打压价格 | 短时间内价格波动超阈值 |
| 自成交 | 同账户对敲 | 同账户买卖成交 |
| 关联账户 | 多账户协同 | 账户间存在关联关系 |
| 尾市交易 | 收盘前异常报单 | 14:57 后的异常行为 |
监控指标要持续计算并留存:
class AbnormalTradeMonitor:
def __init__(self, limits):
self.limits = limits
self.stats = defaultdict(int)
def on_order(self, order):
self.stats['order_count'] += 1
if order.qty > self.limits['big_order_qty']:
self.record('big_order', order)
def on_cancel(self, order):
self.stats['cancel_count'] += 1
ratio = self.stats['cancel_count'] / max(self.stats['order_count'], 1)
if ratio > self.limits['cancel_ratio']:
self.record('high_cancel_ratio', {'ratio': ratio})
def record(self, kind, detail):
self.alerts.append({'ts': time.time(), 'kind': kind, 'detail': detail})
撤单率是最高频的触发点。做市策略天然撤单率高,必须在报备时说明,并在系统里做限速(如每笔报单至少存活 N 毫秒)。
4. 公平交易与信息隔离
如果你同时管理自营资金和客户资金,信息隔离墙(Chinese Wall) 是硬要求:
自营部门 ─╳─ 客户部门
│ │
└── 隔离 ────┘
禁止信息流动、禁止同向交易
技术上的隔离手段:
| 手段 | 说明 |
|---|---|
| 系统隔离 | 自营与客户用完全独立的系统 |
| 账户隔离 | 不同的交易账户与资金账户 |
| 网络隔离 | 不同的网络域与访问控制 |
| 权限隔离 | 人员权限不交叉 |
| 日志隔离 | 日志存储与访问独立 |
同向交易与反向交易的检查是信息隔离的核心:
def check_self_dealing(order, other_orders, min_interval_ms=1000):
for o in other_orders: # 同标的短时间同向交易可能构成不公平交易
if o.symbol != order.symbol or o.account == order.account:
continue
if same_direction(o, order) and abs(o.ts - order.ts) < min_interval_ms:
return {'violation': 'same_direction', 'conflict_order': o.id}
return None
抢先交易(Front Running) 是明确的违规行为:利用客户订单信息为自己谋利。技术上要保证订单信息在到达执行之前不被自营策略看到。
5. 反洗钱与投资者适当性
反洗钱(AML)要求识别异常资金流动:
| 监控项 | 触发条件 |
|---|---|
| 大额交易 | 单笔或当日累计超过阈值 |
| 频繁交易 | 短期内高频进出 |
| 异常时段 | 非正常交易时段的操作 |
| 资金快进快出 | 资金到账后立即转出 |
| 关联账户 | 多账户之间频繁划转 |
适当性管理要求产品与投资者匹配:高风险产品只能卖给风险承受能力匹配的投资者。技术系统需要在开户和交易环节做校验。
RISK_LEVELS = {'R1': 1, 'R2': 2, 'R3': 3, 'R4': 4, 'R5': 5}
def check_suitability(investor, product):
if RISK_LEVELS[product.risk_level] > RISK_LEVELS[investor.risk_tolerance]:
return {'allowed': False,
'reason': f'产品风险 {product.risk_level} 超出投资者承受能力 '
f'{investor.risk_tolerance}'}
return {'allowed': True}
量化产品通常被归为 R4/R5,对投资者的资金规模、投资经验、风险测评结果都有要求。
6. 审计留痕要求
留痕是合规的技术核心。监管检查时,你需要能提供完整的证据链。留痕的范围:
1. 交易留痕:每一笔报单、撤单、成交的完整信息
2. 决策留痕:策略产生信号的过程与依据
3. 系统留痕:配置变更、部署记录、故障记录
4. 人员留痕:谁在什么时候做了什么操作
5. 数据留痕:行情数据的来源与处理过程
留痕的技术要求:
| 要求 | 实现 |
|---|---|
| 完整性 | 不可遗漏任何一笔交易 |
| 不可篡改 | 只追加(append-only)或 WORM 存储 |
| 可检索 | 按时间/账户/标的快速查询 |
| 保留期 | 通常 5~20 年(各市场不同) |
| 可导出 | 能生成监管要求的格式 |
class AuditLog:
def __init__(self, path):
self.fp = open(path, 'ab') # 只追加,不修改,不删除
def append(self, event):
record = {
'ts': time.time_ns(),
'type': event.type, # ORDER / CANCEL / FILL / CONFIG
'actor': event.actor, # 用户或系统
'payload': event.payload,
'prev_hash': self.last_hash, # 链式哈希,防篡改
}
record['hash'] = sha256(json.dumps(record, sort_keys=True).encode()).hexdigest()
self.last_hash = record['hash']
self.fp.write((json.dumps(record) + '\n').encode())
self.fp.flush() # 立即落盘,不缓存
链式哈希让日志具备防篡改能力:每一条记录包含前一条的哈希,修改任何一条都会导致后续所有哈希不匹配。这与区块链的思路一致,但不需要分布式共识。
留痕数据的存储与备份是长期工程。日志量随交易量线性增长,需要分层归档与定期恢复演练,参考 数据备份与恢复 。
7. 跨境与多市场合规
多市场交易要同时满足各市场的监管要求,冲突时取严:
| 维度 | A 股 | 港股 | 美股 |
|---|---|---|---|
| 报备 | 事前报备 | 算法交易申报 | 算法交易报告 |
| 留痕期限 | 20 年 | 7 年 | 6 年 |
| 撤单限制 | 有阈值 | 有阈值 | 无硬性阈值 |
| 做空限制 | 严格 | 有限制 | 相对宽松 |
| 结算周期 | T+1 | T+2 | T+1 |
数据出境是跨境业务的敏感点。客户信息、交易数据出境需要满足数据安全法的要求,通常需要在境内存储或做脱敏处理。
def export_check(data_type, destination):
sensitive = {'client_info', 'trade_detail', 'position'}
if data_type in sensitive and destination == 'overseas':
return {'allowed': False,
'reason': '敏感数据出境需安全评估',
'alternative': '境内存储 + 聚合脱敏后输出'}
return {'allowed': True}
8. 合规系统的技术实现
合规系统的最佳实践是与交易系统解耦:合规检查不应该拖慢交易,但必须能拦截违规。
交易系统 ──订单──► [合规检查] ──通过──► 交易所
│
└──拒绝──► 告警 + 留痕
三种集成方式:
| 方式 | 延迟影响 | 拦截能力 | 适用 |
|---|---|---|---|
| 前置同步检查 | 高 | 强 | 硬性规则 |
| 异步旁路检查 | 无 | 弱 | 统计分析 |
| 混合(前置 + 旁路) | 中 | 强 | 推荐 |
混合方式的分工:硬性规则(自成交、限额)前置同步,行为模式(撤单率、异常申报)异步旁路。前置检查只做 O(1) 的判断,复杂分析放到旁路。
合规系统的日志要与交易日志独立存储,避免交易系统故障时合规日志也丢失。同时要保证两者能通过唯一订单号关联,形成完整证据链。跨系统的关联查询靠的是这个统一订单号,而不是运行时链路。
9. 内部自查与检查应对
监管检查前的自查是降低风险的有效手段。自查清单:
□ 报备信息是否与实际一致(策略、软件、账户)
□ 异常交易监控是否覆盖所有认定的行为类型
□ 留痕是否完整、可检索、不可篡改
□ 信息隔离措施是否落实(自营 vs 客户)
□ 风控制度是否有效执行(限额、熔断)
□ 人员权限是否符合最小必要原则
□ 应急预案是否演练过
□ 历史违规是否整改到位
检查应对的关键是「举证能力」。监管问「你为什么在某时刻下了这笔单」,你需要能提供:
1. 当时的行情快照(数据来源)
2. 策略产生的信号(决策依据)
3. 订单的执行路径(OMS 日志)
4. 风控的校验结果(风控日志)
5. 成交与结算记录(账务日志)
这五份记录必须能通过订单号串联起来,形成完整的时间线。做不到这一点,即使你确实合规,也无法证明。
权衡取舍
| 维度 | 严格合规 | 宽松合规 |
|---|---|---|
| 监管风险 | 低 | 高 |
| 交易自由度 | 低 | 高 |
| 系统复杂度 | 高 | 低 |
| 运维成本 | 高 | 低 |
合规投入的取舍不能按成本算。合规不是「性价比」问题,而是「准入门槛」问题。一次违规的处罚可能远超多年的合规投入,更不用说业务停摆的损失。
留痕粒度的取舍是实际的问题:留痕越细,存储成本越高、系统越慢;留痕越粗,举证能力越弱。实践中的折中是交易相关全部留痕(不可省略),系统运行日志按级别采样(异常必留,正常可采样)。
常见坑清单
- 报备信息与实际不符:策略或软件变更后未更新报备,构成报备不实。
- 高频交易未按高频报备:触及门槛仍按普通程序化交易报备,要求不同。
- 撤单率超限未限速:做市策略未做报单存活时间限制,触发异常交易。
- 自成交未防范:同账户对敲,直接违规。
- 留痕不完整:只留成交不留报单撤单,无法还原决策过程。
- 留痕可篡改:日志文件可写可删,举证时无法自证。
- 信息隔离形同虚设:自营与客户共用一个系统,权限不隔离。
- 数据出境未评估:客户信息直接传到境外服务器,违反数据安全要求。
- 合规检查拖慢交易:所有规则都前置同步,延迟大幅上升。
- 检查时无法举证:各系统日志无法通过订单号关联,证据链断裂。
小结
合规的核心是可举证。监管不会要求你用特定技术,但会要求你在被问到时能拿出完整、可信、可追溯的证据。留痕、隔离、监控,本质上都是在为「举证」做准备。
工程上的关键是三点:留痕完整且不可篡改(链式哈希 + 只追加)、检查高效且不拖慢交易(前置 + 旁路混合)、证据链可串联(唯一订单号贯穿全链路)。
判断合规体系是否合格,最快的检验是模拟检查:随机挑一笔历史订单,看能否在 10 分钟内还原它的完整决策与执行过程。做不到,就说明留痕体系有缺口。
本专题到此结束。建议回到 量化交易系统全景 重新审视整体架构,或者针对你最关心的环节深入:从 行情数据接入 到清结算与对账,每一篇都可以独立阅读。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。