第二章 监管规则体系：国内外主要监管机构与核心法规解读
做交易合规系统，第一件事不是写代码，而是搞清楚——你到底要听谁的？
我刚开始接触这个领域时，觉得合规就是一堆条文，找个律师翻译成逻辑就行。后来发现，完全不是这么回事。监管规则不是死的，它是活的，而且不同国家的规则之间还有冲突。你想想看，一个跨国交易系统，同时要满足SEC、CSRC、FCA的要求，这本身就是个架构挑战。
这一章，我们就来拆解这个规则体系。我会结合我实际踩过的坑，帮你理清头绪。
2.1 全球主要监管机构概览
先看一张图，这是我个人习惯用的知识框架。它帮你快速定位：你的系统要对接谁？
这张图里，我特意把四个主要区域分开了。为什么？因为每个区域的监管哲学完全不同。
2.1.1 美国：SEC 与 FINRA
SEC（美国证券交易委员会）是老大。它管的是整个证券市场，从发行到交易到清算，全链条覆盖。我参与过一个美股交易系统，SEC的规则是最先要过的坎。
FINRA（金融业监管局）是行业自律组织，但它的权力很大。说白了，SEC定大方向，FINRA负责具体执行和检查。我在项目中遇到过FINRA的突击检查，他们真的会一条一条对交易日志。
2.1.2 中国：CSRC 与交易所
CSRC（中国证监会）是中国的SEC。但有个区别——中国的交易所（上交所、深交所）本身也承担了大量监管职能。比如异常交易监控，交易所直接出规则，券商必须执行。
我记得有一次做A股合规系统，CSRC出了一个关于程序化交易的新规。我们连夜改规则引擎，因为第二天就要生效。嗯，这种「突然袭击」在国内挺常见的。
2.1.3 欧洲：ESMA 与 FCA
ESMA（欧洲证券和市场管理局）负责制定统一标准，但具体执行由各国监管机构负责。比如英国的FCA、德国的BaFin。
欧洲的规则体系有个特点——特别喜欢用「原则性监管」。什么意思？就是它不告诉你具体怎么做，只告诉你「要达到什么效果」。这对系统设计来说，其实更难。因为你需要自己推导出实现路径。
2.2 核心法规深度解读
法规很多，但真正影响系统架构的，就那么几个。我挑三个最关键的讲。
2.2.1 MiFID II：欧洲的「合规圣经」
MiFID II（欧盟金融工具市场指令第二版）是2018年生效的。它有多重要？这么说吧，欧洲所有交易系统，如果不满足MiFID II，直接不能上线。
核心要求我列一下：
| 要求类别 | 具体内容 | 系统影响 |
|---|---|---|
| 交易报告 | 所有交易必须在T+1内报告，包含65个字段 | 需要实时数据采集和报告生成模块 |
| 最佳执行 | 券商必须证明为客户获得了最优价格 | 需要记录所有订单路由和成交数据 |
| 算法交易 | 算法必须经过测试和认证，有熔断机制 | 需要算法沙箱环境和实时监控 |
| 透明度 | 交易前和交易后的透明度要求 | 需要公开报价和成交数据接口 |
2.2.2 Reg BI：美国的「最佳利益」标准
Reg BI（Regulation Best Interest）是SEC在2019年推出的。它要求经纪商在推荐交易时，必须以客户的最佳利益为准，而不是自己的利益。
这个法规对系统的影响在哪？
- 记录留存：所有推荐理由必须记录。系统要能回溯：为什么推荐这只股票？
- 利益冲突披露：如果券商和某只股票有利益关系，必须自动标记。
- 成本分析：系统要能计算不同交易方案的成本差异。
我参与过一个美国券商的合规改造项目。Reg BI上线后，他们的交易系统增加了「推荐理由」模块。每个订单都要附带一个JSON对象，里面包含推荐逻辑、成本对比、利益冲突声明。嗯，这个模块后来成了他们合规审计的核心证据。
2.2.3 中国：程序化交易管理规定
中国对程序化交易的监管，这几年越来越严。2023年出的《程序化交易管理规定（征求意见稿）》，核心要求包括：
- 报备制度：所有程序化交易策略必须向交易所报备。
- 阈值管理：每秒订单数、撤单率等都有明确上限。
- 应急机制：系统必须有一键熔断功能。
2.3 规则分类与层级
监管规则不是平铺的，它有层级。理解这个层级，对系统设计至关重要。
我一般把规则分为三层：
2.3.1 第一层：法律与法规
这是最高层，由立法机构或最高监管机构发布。比如美国的《证券交易法》、中国的《证券法》。这些是原则性的，不会涉及具体技术细节。
2.3.2 第二层：监管细则与指引
由监管机构发布，是对法律的细化。比如SEC的规则、CSRC的部门规章。这一层开始有具体的技术要求了。
2.3.3 第三层：行业标准与最佳实践
由行业协会或交易所发布。比如FIX协议、交易所的交易规则。这一层最具体，直接决定你的系统怎么实现。
举个例子：
- 法律层：证券法规定「禁止市场操纵」
- 细则层：CSRC发布《程序化交易管理规定》，明确什么是操纵行为
- 标准层：上交所发布《程序化交易接口规范》，规定如何报备、如何监控
你的合规系统，最终要落到第三层。但设计时，必须向上兼容第一层和第二层。为什么？因为法规会变，但法律原则不会。我建议你采用「规则引擎+规则库」的架构，把第三层的具体规则做成可配置的。
2.4 规则冲突与优先级
做跨国系统时，最头疼的是规则冲突。比如：
- 美国要求交易数据保留6年，欧洲要求保留5年。你按哪个？
- 中国要求所有交易数据必须存储在中国境内，但全球系统需要统一访问。怎么办？
我的做法是：
- 属地优先：在哪个国家交易，就优先遵守哪个国家的规则。
- 就高不就低：如果两个规则有重叠，按更严格的那个执行。
- 数据隔离：敏感数据按国家分区存储，通过合规网关访问。
2.5 小结
这一章我们聊了全球主要监管机构、核心法规、规则层级和冲突处理。说白了，合规系统的地基就是这些规则。地基打不牢，后面全是坑。
我个人习惯是，每接入一个新市场，先花一周时间把当地监管规则梳理成表格。然后和法务、业务一起过一遍。这个投入很值得，因为后面改代码的成本高得多。
下一章，我们会进入具体的技术实现——规则引擎的设计。到时候我会展示一些代码，看看怎么把今天讲的这些规则，变成可执行的逻辑。