第二十七章：监管与合规技术：交易报告、市场监察、反洗钱、数据保留
做结构化产品做市，说白了就是在刀尖上跳舞。你不仅要赚钱，还得让监管爸爸满意。我见过不少团队，策略牛逼，系统牛逼，最后栽在合规上——罚款罚到破产。
这一章，咱们聊聊合规系统的四个核心模块：交易报告、市场监察、反洗钱、数据保留。每个都是硬骨头，但必须啃下来。
27.1 交易报告：别让数据漏报
交易报告这事儿，我刚开始做的时候觉得特简单——不就是把成交记录发出去吗？后来发现，坑多着呢。
监管要求你报什么？
- 交易时间（精确到微秒）
- 产品标识（ISIN、CFI码）
- 交易对手信息
- 价格、数量、货币
- 交易场所
- 做市商标识
嗯，这里要注意：不同监管机构格式不一样。ESMA用ISO 20022，SEC用EDGAR，FCA用TRS。你想想看，一个做市商可能同时报给三家，格式转换就是个噩梦。
核心原则：交易报告系统必须支持多格式输出，且具备实时校验能力。我建议用模板模式+策略模式来解耦。
代码示例（伪代码）：
class TradeReporter:
def __init__(self):
self.validators = []
self.formatters = {}
def register_validator(self, validator):
self.validators.append(validator)
def register_formatter(self, jurisdiction, formatter):
self.formatters[jurisdiction] = formatter
def report(self, trade, jurisdiction):
# 先校验
for v in self.validators:
if not v.validate(trade):
raise ValidationError(f"校验失败: {v.error_msg}")
# 再格式化
formatter = self.formatters.get(jurisdiction)
if not formatter:
raise UnsupportedJurisdictionError(jurisdiction)
message = formatter.format(trade)
self.send(message)
我在项目中遇到过一个问题：某次系统升级后，时间戳精度从毫秒降到了微秒，结果监管报告全部被拒。后来我加了个时间戳精度校验器，低于微秒的直接报警。
避坑指南：我曾经因为时区问题导致报告时间偏差。记住：所有时间戳必须用UTC，且带时区标识。别问我怎么知道的。
27.2 市场监察：抓异常，防操纵
市场监察说白了就是盯着你的交易行为，别搞出什么幺蛾子。监管最怕什么？操纵市场、虚假交易、幌骗。
常见的监察规则：
- 报价撤销率：短时间内大量撤单，超过阈值就报警
- 自成交：自己买自己卖，制造虚假流动性
- 分层报价：在多个价位挂单，诱导市场
- 闪电交易：利用速度优势抢跑
我建议用事件驱动架构来做监察。每个交易事件进来，触发一系列规则检查。规则可以热加载，不用重启系统。
为什么？因为监管规则经常变。今天这个阈值是5%，明天可能改成3%。你总不能每次改规则都停机部署吧？
个人经验：规则引擎我推荐用Drools或者自己写一个轻量级的。别用太重的框架，监察系统对延迟敏感，每多1毫秒，你的做市策略就多一分风险。
代码示例（规则定义）：
rule "自成交检测"
when
$t1: Trade(account == $t2.account)
$t2: Trade(account == $t1.account,
symbol == $t1.symbol,
side != $t1.side,
price == $t1.price,
time - $t1.time < 100ms)
then
alert("自成交嫌疑", $t1, $t2)
end
嗯，这里要注意：规则不能太死板。做市商本身就会频繁报价和撤单，这是正常行为。你得区分「正常做市」和「异常操纵」。我一般用统计方法——看偏离均值多少个标准差。
27.3 反洗钱：AML 系统的三把刀
反洗钱（AML）是合规里最头疼的。为什么？因为洗钱手法千奇百怪，而且做市商交易量大，很容易被利用。
AML系统的核心模块：
| 模块 | 功能 | 我踩过的坑 |
|---|---|---|
| KYC | 客户身份识别 | 证件过期没更新，被罚过 |
| 交易监控 | 大额交易、可疑交易 | 阈值设太低，报警太多 |
| 名单筛查 | 制裁名单、政治人物 | 名字匹配太宽松，误报率高 |
我个人习惯用三层过滤：
- 第一层：规则过滤——金额、频率、对手方
- 第二层：行为分析——交易模式、资金流向
- 第三层：人工审核——只有前两层都报警，才转人工
这样做的好处是：减少误报，提高效率。你想想看，如果每笔交易都转人工，那得多少人？
关键点：AML系统必须支持实时和批量两种模式。实时用于拦截可疑交易，批量用于事后回溯。我建议用流处理框架（比如Flink）来做实时部分，用Spark做批量分析。
我曾经遇到一个案例：某个客户通过结构化产品做市，把大额资金拆成小额交易，分散到多个账户。表面看每笔都合规，但聚合起来就超标了。后来我加了个「关联账户聚合」规则，才抓住他。
27.4 数据保留：存多久？怎么存？
数据保留这事儿，监管要求很明确：交易记录至少保留5-7年，有些地方甚至要求10年。但问题来了——数据量太大。
一个做市商每天产生多少数据？
- 报价数据：几百万条
- 成交数据：几十万条
- 日志数据：上亿条
- 监控数据：几千万条
你算算，一年下来多少TB？
我建议用分层存储策略：
| 层级 | 存储介质 | 保留时间 | 访问频率 |
|---|---|---|---|
| 热数据 | SSD/内存 | 30天 | 高 |
| 温数据 | HDD | 1年 | 中 |
| 冷数据 | 磁带/云归档 | 5-10年 | 低 |
嗯，这里要注意：冷数据不是存了就不管了。监管随时可能要求你提供某笔交易的历史记录。你得保证能快速检索。
技巧：我习惯在数据入库时就做好索引。按时间、产品、账户三个维度建索引。这样查询时不用全表扫描，效率高很多。
代码示例（数据归档策略）：
class DataRetentionManager:
def __init__(self):
self.policies = {
"trade": {"hot": 30, "warm": 365, "cold": 3650},
"log": {"hot": 7, "warm": 90, "cold": 1825},
"monitor": {"hot": 14, "warm": 180, "cold": 3650}
}
def archive(self, data_type, data):
policy = self.policies[data_type]
age = data.age_in_days()
if age < policy["hot"]:
self.store_hot(data)
elif age < policy["warm"]:
self.store_warm(data)
else:
self.store_cold(data)
def retrieve(self, query):
# 先查热数据，再查温数据，最后查冷数据
for layer in ["hot", "warm", "cold"]:
result = self.query_layer(layer, query)
if result:
return result
return None
警告：我曾经因为冷数据存储格式不兼容，导致5年前的数据读不出来。后来我强制规定：所有归档数据必须附带元数据，包括格式版本、编码方式、压缩算法。不然5年后你根本不知道这堆二进制是什么玩意儿。
27.5 架构总览：合规系统的四层结构
说了这么多，咱们画个图总结一下。合规系统我一般分四层：
这四层各司其职。数据接入层负责采集和标准化，处理层负责规则引擎和计算，存储层解决数据保留问题，报告层输出给监管和内部审计。
我个人习惯在每层之间加个消息队列（Kafka），这样解耦。万一哪层挂了，不会影响其他层。你想想看，如果监察引擎宕机了，交易报告还能正常发，这才是高可用。
最后说一句：合规系统不是一次性项目，是持续迭代的。监管规则在变，交易品种在变，你的系统也得跟着变。我建议每季度做一次合规系统压力测试，看看能不能扛住监管的突击检查。
好了，这一章就到这儿。记住：合规不是成本，是护身符。没有合规，你的做市系统再牛逼也是空中楼阁。