11、记录保存与审计追踪:交易记录保存要求(时长、格式)、电子通讯监控(如Bloomberg聊天记录)、审计追踪的完整性与不可篡改性。

做市商这行,说白了就是跟数据打交道。你每一笔报价、每一次成交、甚至跟交易对手在聊天框里发的每一句话,都可能成为未来监管审查的关键证据。我个人习惯把记录保存和审计追踪看作是结构化产品做市商的「黑匣子」——平时你可能觉得它碍事,但真出了事,它就是保命符。

这一节,我们就来拆解一下这个「黑匣子」到底该怎么造。

11.1 交易记录保存要求:时长与格式

先聊聊最基础的东西——交易记录。嗯,这里要注意,监管对「交易记录」的定义其实很宽泛。不只是成交单,还包括报价、修改、撤销、以及相关的风控计算过程。

保存时长:不是越长越好,但短了肯定不行

不同地区的监管要求不一样。我遇到过最头疼的情况,就是跨市场做市,得同时满足好几套规则。

监管辖区 主要规则 最低保存时长
香港(SFC) 《证券及期货条例》 7年
新加坡(MAS) 《证券与期货法》 5年
欧洲(ESMA) MiFID II 5年(部分要求7年)
美国(SEC/FINRA) Rule 17a-4 6年(前2年需即时可访问)
我的经验: 别卡着最低线去设计系统。我曾经见过一家小做市商,严格按照5年标准来,结果第6年监管来查5年前的一笔争议交易,数据刚好被归档系统「优化」掉了。建议统一按7年设计,省心。

保存格式:可读、可检索、不可改

格式这块,监管其实没规定死你必须用PDF还是CSV。但有几个硬性要求:

  • 不可篡改格式: 说白了,就是存进去是什么样,读出来就得是什么样。WORM(Write Once, Read Many)是基本要求。
  • 可检索性: 你不能把数据往硬盘里一扔就完事。监管来查,你得能在合理时间内(比如24小时内)把特定日期的特定交易记录翻出来。
  • 标准化格式: 我个人建议用XML或JSON作为内部存储格式,导出时再转成PDF/A(长期存档标准)。
避坑指南: 我曾经遇到过一个案例,某做市商把交易记录存成了Excel文件,结果员工不小心改了公式,导致整列数据偏移。虽然最后查出来了,但合规部门被罚了款。所以,绝对不要用可编辑格式作为原始记录

11.2 电子通讯监控:Bloomberg聊天记录只是冰山一角

说到电子通讯监控,很多人第一反应就是Bloomberg聊天记录。没错,这是大头。但你想想看,现在做市商都用什么?Slack、微信、企业微信、甚至钉钉。

监管的逻辑很简单:只要是通过电子设备进行的、与业务相关的沟通,都得监控

监控范围清单

  • 即时通讯工具: Bloomberg IB、Refinitiv Messenger、Slack、Teams
  • 电子邮件: 公司邮箱、个人邮箱(如果用于业务)
  • 语音通话: 交易线路录音(这个很多做市商容易漏掉移动端)
  • 社交媒体: 微信、WhatsApp(部分地区监管已明确要求)
注意: 别以为用个人手机发微信就查不到。我记得2022年,美国SEC就罚了一家大型做市商,原因是交易员用个人WhatsApp讨论交易,公司没有监控。罚款金额是——嗯,够买好几套监控系统了。

监控系统的核心能力

一个好的监控系统,不能只是「录下来」。它得具备:

  1. 关键词抓取: 自动识别「内幕消息」、「操纵」、「拉高出货」等敏感词。
  2. 语音转文字: 把录音转成可检索的文本。
  3. 异常行为检测: 比如某交易员在重大消息公布前,突然大量删除聊天记录。

11.3 审计追踪的完整性与不可篡改性

这是整个合规框架的基石。你记录保存得再好,如果审计追踪是断裂的,或者可以被篡改,那等于零。

什么是「完整」的审计追踪?

我个人的定义是:从交易想法产生,到最终结算完成,中间每一个环节的每一次修改,都要被记录

举个例子:

  • 交易员A在系统里输入了一个报价(记录1)
  • 风控经理B觉得价格不对,修改了报价(记录2:谁改的、改了什么、为什么改)
  • 系统自动执行了修改后的报价(记录3:系统日志)
  • 成交后,结算部门手动调整了费用(记录4)

这4个记录,缺一个,审计追踪就不完整。

不可篡改性的技术实现

别被「区块链」之类的概念忽悠了。做市商系统里,实现不可篡改最成熟的方式是:

// 伪代码示例:基于哈希链的日志记录
public class AuditLogEntry {
    private long timestamp;
    private String userId;
    private String action;
    private String dataHash;  // 当前数据的哈希值
    private String previousHash; // 上一条日志的哈希值
    private String signature; // 数字签名

    public boolean verifyIntegrity() {
        // 1. 验证当前数据的哈希值是否匹配
        // 2. 验证previousHash是否等于上一条日志的哈希
        // 3. 验证数字签名是否有效
    }
}

说白了,就是每条日志都「记住」了上一条日志的指纹。你想改中间任何一条,后面的全得跟着改,而且数字签名会暴露你。

核心原则: 审计日志的写入权限必须严格限制。我建议设计成「只追加、不删除、不修改」的模式。连DBA(数据库管理员)都不能直接改表里的数据。要改?走审批流程,生成一条新的修正日志。

知识体系总览

下面这张图,是我自己梳理的本章节核心逻辑。你可以把它当作一个检查清单:

记录保存与审计追踪核心框架 交易记录保存 电子通讯监控 审计追踪 时长:5-7年(按最严标准) 格式:WORM、PDF/A、XML 可检索性:24小时内响应 Bloomberg、Slack、微信 语音通话录音(含移动端) 关键词抓取 + 异常行为检测 全生命周期记录 哈希链 + 数字签名 只追加、不删除、不修改 核心目标:可复现、可验证、不可抵赖 任何一笔交易,都能在7年后完整还原当时场景

你看,这三个支柱是互相支撑的。交易记录是「原料」,电子通讯监控是「过程证据」,审计追踪是「链条」。缺了任何一个,你的合规框架都是漏水的。

最后说一句: 别把合规系统当成成本中心。我见过最聪明的做市商,把审计日志用在了交易策略回测上——通过分析历史操作记录,优化了算法参数。合规数据,用好了也是资产。

交易系统化学习资料 微信Strategy888888