mcpField
P
pre-trade-compliance

pre-trade-compliance

github.com/joellewis其他218673 次安装15 周前更新
代码仓库

关于 pre-trade-compliance

讲解金融机构如何在订单路由或执行前进行筛查的合规技能。内容涵盖规则评估、拦截决策、受限名单和集中度控制,面向合规与交易团队。

主要功能

  1. 01顺序、并行及混合规则评估
  2. 02路由前与执行前检查
  3. 03硬拦截与软拦截处理
  4. 04区分受限、观察及灰名单
  5. 05证券与投资组合集中度检查

适用场景

  1. 01在订单路由至执行场所前进行筛查
  2. 02拦截涉及受限证券的交易
  3. 03提交订单前查看全部规则违规项
  4. 04检查拟议交易是否符合集中度限制

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/joellewis/finance_skills --skill pre-trade-compliance

安装后在 Claude Code 中输入/pre-trade-compliance确认已加载。

附带文件references/examples.md

详细介绍

交易前合规

核心概念

交易前合规架构

交易前合规系统会在投资组合管理系统或订单录入界面生成订单后、将订单路由至托管机构或执行场所前拦截订单。系统会根据一组规则评估每笔订单,然后允许订单继续处理、完全阻止订单(硬性拦截),或将其标记为待审核(软性拦截)。

规则引擎设计——顺序评估与并行评估:

  • 顺序评估: 按照既定顺序评估规则,并在首次失败时停止处理。如果靠前的规则很可能发现大多数违规情况(例如,在评估集中度限制前检查账户是否被冻结),这种方法效率较高。顺序评估可降低早期失败订单的延迟,但提供的诊断信息不完整——交易员只能看到首个违规情况,而不是全部违规情况。
  • 并行评估: 同时评估所有规则,并返回完整的结果集。这种方法可提供全面的诊断结果——交易员一次即可看到订单违反的所有规则。对于提交前会审核订单、且合规团队需要了解全貌的顾问工作流,优先采用并行评估。其代价是每笔订单的计算成本较高,不过对于典型的顾问订单量而言,这种成本可以忽略不计。
  • 混合方式: 首先评估关键规则(账户状态、限制名单),作为快速失败关卡。如果订单通过这些检查,则并行评估其余规则。这种方式兼顾了延迟与诊断完整性。

订单拦截点:

  • 路由前: 在订单传输至托管机构或执行场所之前进行合规检查。这是主要拦截点,可在订单与市场发生任何交互前发现违规情况。在此阶段,订单仅存在于公司系统中。
  • 执行前: 对于可直接进入市场或具备算法执行能力的公司,订单路由后、释放执行前可能还会进行第二次合规检查。此举可发现路由与执行之间因市场状况变化而产生的问题(例如,仓位快速变化,现已超过限额)。
  • 汇总后、路由前: 对于大宗交易,应同时在单个账户层面(该账户是否违反其集中度限额?)和大宗交易汇总层面(大宗交易总量是否超过该证券的平均每日成交量阈值?)进行合规检查。

硬性拦截与软性拦截:

  • 硬性拦截:在未解决根本原因的情况下,无论如何都不允许订单继续处理。无法绕过订单拦截——必须修改或取消订单,或移除拦截条件(例如,将证券从限制名单中移除、解除账户冻结)。硬性拦截仅用于不允许例外的监管要求和公司政策:违反限制名单规定、在冻结或暂停的账户中交易、超过监管仓位限额,以及交易受法律限制的证券。
  • 软性拦截:生成警告,要求在订单继续处理前确认并提供书面理由。对于专业判断可能足以证明例外合理的指导原则,适合采用软性拦截:内部集中度指导原则(而非监管限额)、命中观察名单、与模型配置存在轻微偏差,以及触发顾问提醒的交易(例如,接近但未超过限额)。每次覆盖软性拦截都必须记录授权人的身份、时间戳和所述理由。

合规检查延迟要求: 交易前合规检查必须在不会实质性损害执行质量的时间范围内完成。对于市场价格不断变化的股票和 ETF 订单,合规延迟会直接影响执行价格风险。目标延迟基准:实时交易工作流中的单笔订单合规检查应在 100 毫秒内完成;模型驱动交易的批量合规检查(数百或数千笔订单)应在几秒内完成,而非几分钟。需要实时查询数据库的规则引擎(例如,检查存储在外部系统中的受限名单)必须采用缓存策略,以达到延迟目标。缓存策略包括:在系统启动时将受限名单和集中度阈值加载到内存中,并在变更事件发生时增量刷新;预先计算投资组合指标(行业权重、发行人敞口),并在持仓变化时增量更新,而不是每次合规检查都从头计算;维护账户级合规状态的内存快照,并在每笔交易后更新,而不是每次检查都查询数据库。

规则优先级和顺序:

规则应按优先级组织,以确保首先评估最关键的检查,并正确处理规则间的交互。典型的优先级顺序为:(1)账户状态检查(冻结、暂停、关闭),(2)受限名单筛查,(3)监管持仓限额,(4)监管合规规则(洗售、无资金交易),(5)客户特定限制,(6)公司层面的集中度限额,(7)模型和投资指南合规。如果多条规则对同一订单触发,以限制最严格的结果为准——任何规则产生的硬性拦截都会覆盖其他规则产生的软性拦截。

受限名单和观察名单

受限名单和观察名单是核心合规工具,用于管控涉及公司或其人员存在利益冲突、信息优势或监管义务的证券交易。

公司受限名单(由 MNPI 驱动):

公司受限名单包含公司或其关联方持有重大非公开信息(MNPI)的证券。对于拥有投资银行关联机构的经纪交易商,当公司参与涉及上市公司的顾问业务(并购、承销、重组)时,该公司会将相关证券列入受限名单。所有公司账户均禁止交易受限名单中的证券,包括自营、顾问和个人账户。受限名单由合规部门维护,通常会征求法务部门和信息隔离(中国墙)小组的意见。名单的添加和移除都具有时效性:必须在 MNPI 于公司内部传播之前将证券列入名单,且只有在信息公开或业务委托结束后才能将其移出。

个人交易受限名单:

关联人员——可接触客户交易、投资组合持仓或投资建议等非公开信息的员工——须遵守个人交易限制。个人交易受限名单可能包括公司正在为客户交易的证券(以防止抢先交易)、正在进行主动研究覆盖的证券,以及需要依据 SEC Rule 204A-1 事先审批的 IPO 和有限发行证券。个人交易限制独立于公司受限名单运作,并可能根据员工职责而更严格或更宽松。

客户特定受限证券: 个人客户账户可能因法律限制(例如客户在某家公司拥有内幕人士身份,或离婚判决禁止出售某些持仓)、合同义务(锁定协议)或客户偏好(客户要求公司不要购买某家特定公司的证券)而设有各自的受限证券名单。这些限制在账户层级维护,并在针对该账户进行交易前合规检查时核验。

发行人限制的传导(母公司/子公司):

将证券加入受限名单后,限制必须传导至相关证券。如果母公司受到限制,其所有子公司、关联公司及相关实体也应受到限制。这需要维护一份映射公司关系的发行人层级结构。传导范围应涵盖:普通股、优先股、可转换证券、期权、认股权证、债务证券,以及由受限发行人发行或与其相关的任何其他工具。未能将限制传导至整个企业集团,是常见的合规漏洞,也是监管机构重点检查的事项。

观察名单与受限名单(采取不同措施):

观察名单包含受到加强监控、但并未被全面禁止交易的证券。观察名单上的证券可以交易,但交易会触发警报,供合规部门审查。当公司有理由监控某证券的交易,但相关信息或情况尚未严重到需要全面限制时,就会使用观察名单。例如,公司正处于潜在业务委托的初步洽谈阶段;市场上流传着关于公司所覆盖企业的传闻;或员工报告了潜在利益冲突。命中观察名单会触发软拦截;命中受限名单则会触发硬拦截。

灰名单(额外监控层级):

除受限名单和观察名单外,有些公司还会维护灰名单。灰名单用于列出公司可能很快会收到重大非公开信息(MNPI)、但尚未收到此类信息的证券,例如投资银行推介正在进行,但尚未签署委托函的情况。灰名单上的证券不受交易限制,但所有交易都会被标记,供合规监控团队进行事后审查。灰名单可提供预警机制,并有助于证明公司在收到重大非公开信息之前已落实监控程序,这一点对于应对内幕交易指控可能十分重要。

名单维护与更新:

随着情况变化,必须及时更新受限名单和观察名单。过时的名单会带来两种风险:(1)应受限的证券未被限制,使公司面临内幕交易责任;(2)本应移除的证券仍受限制,导致合法交易遭到不必要的拦截。最佳实践包括:实时或每日更新名单;接入交易管理系统的自动数据源(用于由投资银行业务触发的限制);定期审查,以确认所有条目仍然有效;以及保留审计追踪,记录每次新增、移除和修改的原因及授权人员。

集中度限额

集中度限额旨在防止对单一证券、发行人、行业或资产类别的敞口过高。这些限额既用于风险管理,也用于遵守监管规定。

证券层面的集中度:

最常见的集中度限额是限制投资组合中单一证券的最高投资比例。单只股票持仓的常见阈值为账户价值的 5% 至 10%。合规系统必须计算交易后的持仓价值(当前持仓加上拟议订单)占账户总价值的比例,并将其与限额进行比较。买入订单的检查很直接:这笔买入是否会导致该持仓超过投资组合的 X%?对于其他证券的卖出订单,检查时必须考虑卖出是否会改变分母(投资组合总价值),从而导致剩余持仓超过其集中度限额。

行业和产业限额:

行业限额用于限制对单一 GICS 行业(例如,科技行业不超过 25%)或产业(例如,半导体产业不超过 10%)的总敞口。实施行业限额需要将投资组合中的每种证券映射到其行业和产业分类,因此需要依赖可靠且分类数据最新的证券主数据数据库。行业限额检查必须汇总该行业内的所有持仓,包括拟议交易,并将总额与限额进行比较。

资产类别限额:

资产类别限额用于限制对各大类资产的敞口,包括股票、固定收益、另类投资和现金。这些限额通常根据投资政策声明(IPS)设定,并以范围表示(例如,股票 40% 至 70%、固定收益 20% 至 50%、另类投资 0% 至 15%、现金 1% 至 5%)。交易前合规检查会验证拟议交易是否会导致任何资产类别的配置超出允许范围。

发行人限额:

发行人限额用于限制对单一发行人的各类证券的总敞口。客户可能持有同一发行人的普通股、公司债券和可转换票据——发行人限额会汇总所有这些敞口。这对信用风险管理尤为重要:如果发行人违约,无论证券类型如何,所有证券都会受到影响。

监管限额(注册基金):

《1940 年投资公司法》对注册投资公司(共同基金)规定了具体的多元化要求。多元化基金必须满足 75-5-10 测试:基金至少 75% 的资产必须进行多元化配置,即投资于任何单一发行人的资产不得超过总资产的 5%,且持有该发行人未偿付有表决权证券的比例不得超过 10%。其余 25% 的资产不受这些限额约束。这些属于硬性监管限额,超限会触发强制拦截。

跨账户和家庭汇总:

有些集中度限额不仅适用于单个账户,还适用于相关账户的汇总,例如一个家庭、一个家族群组,或由同一策略管理的所有账户。家庭层面的集中度限额要求合规系统在评估限额前汇总家庭内所有账户的持仓。这可以避免出现每个单独账户都符合限额,但家庭对单一证券或行业的总敞口过高的情况。汇总会增加复杂性,因为账户可能由不同托管机构持有,属于不同账户类型(应税账户、IRA、信托),并采用不同的投资政策。

持仓规模和敞口限制

持仓规模和敞口限制用于控制持仓的绝对规模及风险敞口,与基于百分比的集中度限制相辅相成。

最大持仓规模:

对单一证券持仓的股数或名义价值设定绝对上限。这些限制可按账户、策略或公司层级设置。公司层级的持仓限制可防止公司对单一证券的合计持仓大到触发监管申报门槛(例如,持有流通股的 5% 时需提交 Schedule 13D/13G),或造成市场冲击和流动性问题。

名义敞口限制:

对于衍生品和杠杆工具,名义敞口限制会对总经济敞口设定上限,而不考虑现金支出。若一个资产规模为 100 万美元的投资组合持有名义价值 500 万美元的期货敞口,其杠杆为 5 倍。对于使用衍生品的策略,名义敞口限制至关重要,因为少量现金投资可能产生不成比例的市场敞口。合规系统必须将合约数量乘以合约乘数和标的资产价格,计算名义敞口。

期权持仓限制(交易所规定):

证券交易所会对上市期权设定持仓限制,规定任何个人或协同行动的人员团体在市场同一方向上(所有看涨期权和空头看跌期权,或所有看跌期权和空头看涨期权)可持有或卖出的合约数量上限。持仓限制因标的证券而异,取决于其交易量和流通股数。OCC(期权清算公司)会公布当前持仓限制。超过交易所规定的持仓限制将导致监管行动,并可能被强制平仓。

卖空限制:

美国的 Regulation SHO 对卖空行为进行监管,并规定了若干交易前要求:

  • **借券确认要求:**执行卖空前,证券经纪交易商必须有合理依据相信该证券可以借入,并能在结算日之前交付。必须在提交卖空订单前记录此项借券确认。
  • **难借证券名单:**难以借入的证券会列入难借证券名单。卖空这些证券时,可能需要预先借入(即在执行卖出前实际借入股票),而非仅进行借券确认。
  • **阈值证券:**交付失败情况严重的证券会列入阈值证券名单。针对阈值证券的空头持仓,还需满足额外的平仓要求。
  • **替代性涨价规则(Rule 201):**当某证券价格较前一日收盘价下跌 10% 或以上时,当日剩余时间及次日将触发卖空价格限制。卖空只能以高于当前全美最佳买价的价格执行。

杠杆限制:

对于保证金账户,Regulation T 规定初始保证金要求(权益类证券通常为 50%),FINRA Rule 4210 规定维持保证金要求(多头持仓通常为 25%,空头持仓通常为 30%)。交易前合规系统必须验证拟议交易不会导致账户超出其保证金承受能力或低于维持保证金要求。对于投资组合保证金账户,计算更为复杂,采用基于风险的方法。

监管合规规则

交易前合规系统必须执行规范交易行为的具体监管规则。

洗售检测(30 天窗口): IRC 第 1091 条规定,如果纳税人在亏损出售证券前后 30 天内购买了「实质相同」的证券(61 天窗口期),则不得扣除该税务亏损。交易前合规系统应通过以下方式标记潜在的洗售: (1) 检查账户在过去 30 天内是否曾亏损出售相同或实质相同的证券(再次购买会触发洗售),以及 (2) 检查拟议的亏损出售之后 30 天内,是否有待处理或计划购买相同证券的交易。实质相同的证券包括同一股票、同一股票的期权,以及在某些解释中追踪同一指数的 ETF。跨关联账户(配偶、IRA)检测洗售会增加复杂性,因为 IRS 会将洗售规则应用于同一纳税人控制的所有账户。

防止违规搭便车(Regulation T):

在现金账户(非保证金账户)中,客户不得在全额付款前买入并卖出证券。客户买入证券后,必须在结算日(T+1)前完成付款。如果客户在付款前卖出该证券,则构成违规搭便车,账户将被冻结 90 天(90 天内所有购买都必须使用已结算资金)。交易前合规系统必须跟踪未结算的购买,并防止现金账户卖出尚未付款的证券。

模式日内交易者检测:

FINRA 规则 4210 将模式日内交易者定义为:在五个工作日内执行四笔或以上日内交易(同一天买入并卖出相同证券)的客户,前提是该期间的日内交易数量超过客户总交易活动的 6%。模式日内交易者的保证金账户必须至少持有 25,000 美元的权益。交易前合规系统应在滚动五日窗口内统计日内交易,并在接近阈值时发出警报或阻止交易。

共同基金择时交易限制:

共同基金份额的频繁交易(快速买入和赎回)会通过稀释资产和增加交易成本损害长期股东的利益。大多数共同基金招募说明书都包含择时交易政策,限制在指定期限内(通常为 30 至 90 天)进行往返交易。交易前合规系统应跟踪共同基金的购买和赎回活动,并标记违反基金所述择时交易政策的交易。SEC 规则 22c-2 要求基金与中介机构达成协议,共享股东交易数据,以监测择时交易。

防止内幕交易(Section 16、Rule 144):

《证券交易法》第 16 条要求公司内部人士(高管、董事和持有 10% 实益所有权的人)报告其交易,并交出短线交易利润(六个月窗口期内买卖所得的利润)。Rule 144 限制控制性证券和受限证券的转售,并规定持有期限要求和交易量限制。如果公司为公司内部人士管理账户,交易前合规系统必须执行:(1) 在交易内部人士所在公司的证券前取得预先批准;(2) 遵守禁售期限制(内部人士通常不得在财报公布前的一段时间内交易);(3) 遵守 Rule 144 交易量限制(任何三个月期间内的销售量不得超过已发行股份的 1% 或前四周平均每周交易量中的较大者);以及 (4) 协调提交 Form 4。

ERISA 禁止交易规则: 对于受《雇员退休收入保障法案》(ERISA)约束的账户,计划与“利害关系方”(受托人、服务提供商、雇主、工会)之间的某些交易是被禁止的。交易前合规系统必须为每个 ERISA 计划账户维护利害关系方名单,并阻止构成禁止交易的交易,例如购买计划发起方或其关联方发行的证券,或与利害关系方进行借贷或租赁安排。美国劳工部发布的《禁止交易豁免》(PTE)中规定了豁免情形,系统应可配置为识别适用的豁免。

客户专属限制

除全公司范围和监管规则外,个别客户账户还可能有合规系统必须执行的特定限制。

投资政策约束:

每个账户的投资政策声明(IPS)可能规定基于行业(不投资烟草、枪支、赌博)、地域(不投资新兴市场或特定国家)、证券类型(不投资衍生品、结构性产品、私募证券)、质量(仅投资级债券,不投资低于 BBB 评级的债券)或其他标准的排除项。这些约束会映射到证券属性,并根据限制的严格程度执行硬拦截或软拦截。开户时应将 IPS 约束录入合规系统,并在 IPS 修订时更新。

税损收割协调:

积极进行税损收割的账户需要协调合规工作,以避免触发洗售规则。当某个账户为税务目的亏损卖出某项证券时,合规系统必须在 30 天的洗售期限内阻止买回相同或实质相同的证券;不仅限于同一账户,还包括同一纳税人的所有账户(包括配偶的账户和 IRA)。这需要进行跨账户洗售监控,并建立家庭层级的关联。

受法律限制的证券:

法院命令、离婚判决、信托条款和其他法律文件可能会限制特定证券的交易,或对交易施加条件。例如:离婚判决禁止在诉讼期间出售婚姻共同财产(包括证券);信托条款要求受托人在出售集中持仓前获得批准;法院命令在诉讼期间冻结资产;或监管机构的同意令施加的限制。这类限制通常由合规人员手动录入,并设置为硬拦截。

ESG/SRI 筛选:

环境、社会和治理(ESG)筛选及社会责任投资(SRI)标准会基于非财务因素排除证券。常见的筛选标准包括:排除化石燃料(从煤炭、石油或天然气开采中获得的收入超过指定比例的公司)、排除武器(争议性武器、民用枪支制造商)、排除烟草和酒精、排除动物实验,以及人权筛选。ESG 筛选需要将证券映射到 ESG 数据提供商(MSCI ESG、Sustainalytics、ISS ESG),并维护最新的分类数据。由于公司的发展变化可能导致 ESG 分类发生变化,筛选数据必须定期更新。

账户级交易限制:

某些账户级情况需要实施交易限制:被冻结的账户(正在接受监管行动、可疑活动调查或客户争议处理)、尚有待办文件的账户(开户文件不完整、IPS 未签署、缺少受益人指定)、处于遗产清算中的账户(在确认法律授权前冻结交易),以及受到扣押或征收的账户(可能禁止转出交易)。这些账户级标记会对所有或特定类型的交易活动实施硬拦截。

合规例外审批流程

软性拦截需要采用结构化的例外审批流程,在运营效率与严格合规之间取得平衡。

软性拦截审核流程:

触发软性拦截后,订单会被置于待合规审核状态。系统会向合规专员或授权审核人员展示:订单详情、触发拦截的规则、相关指标的当前状态(例如,“此次购买会使科技板块的配置比例达到 27%,超过 25% 的指导上限”)以及任何相关背景信息(例如,该账户的 IPS 允许在顾问批准的情况下战术性超配最多 5%)。审核人员会评估尽管违反了指导上限,该交易是否仍有正当理由,然后批准(豁免拦截)或驳回订单。

例外审批授权级别:

并非所有例外都应由同一级别的人员授权。分级授权结构可根据例外的严重程度匹配授权人员的资历:

  • 1 级(交易员/顾问): 在规定容差范围内的轻微指导偏差(例如,集中度超过指导上限不到 2 个百分点)。交易员或顾问可以自行授权,但必须留存文档记录。
  • 2 级(合规专员): 中度偏差或命中观察名单。必须由合规专员审核并批准。
  • 3 级(首席合规官或委员会): 重大偏差、同一账户多次豁免同一规则,或涉及较高监管风险的例外。必须获得 CCO 或合规委员会批准。

例外审批的文档要求:

每项例外都必须记录以下内容:(1) 订单详情,(2) 触发的规则,(3) 违规的量化详情(指标超过阈值的幅度),(4) 申请例外人员的身份,(5) 授权例外人员的身份,(6) 授权时间戳,(7) 例外的理由说明,以及 (8) 批准附带的任何条件(例如,“批准条件是须在 30 天内降低超配比例”)。这些文档必须作为公司合规记录的一部分予以保存,并接受监管检查。

升级处理流程:

当审核人员无法确定是否应批准例外,或例外涉及特别敏感的情况时(例如,某笔交易可能引发内幕交易方面的疑虑),系统应提供明确的升级处理路径。例外可升级至 CCO、法务部门或合规委员会。升级路径及处理结果都必须留档。

例外后的审计:

合规部门应定期审计例外活动,以发现模式和系统性问题。审计应检查:例外的总量和频率、按规则类型划分的例外情况(哪些规则最常被豁免)、按账户或顾问划分的例外情况(是否有特定顾问持续触发并豁免相同规则)、已批准例外所附条件是否已履行(例如,是否按要求在 30 天内实际降低超配比例),以及任何例外是否导致不利后果(客户受损、监管问题)。

例外模式分析:

如果同一规则频繁被豁免,可能表明该规则的阈值设置不当(过于严格,导致大量误报)、某位顾问或某种策略系统性地偏离指导要求(需要调整指导要求或改变策略),或者鉴于当前市场状况或监管要求,该规则已不再适用。例外模式分析会直接为规则调优流程提供依据。

规则配置与维护

盘前合规系统的有效性取决于持续的规则管理——添加新规则、修改阈值、停用过时规则,并确保规则集反映当前的监管要求和公司政策。

添加和修改规则:

当法规发生变化、公司拓展新的业务线,或合规部门发现现有规则集中存在漏洞时,可能需要制定新规则。规则添加流程应包括:(1)定义规则逻辑(哪些条件会触发拦截,以及会产生哪种类型的拦截);(2)设置阈值或参数值;(3)确定规则适用的账户或账户类型;(4)使用历史订单数据测试规则,以评估其影响(会拦截多少订单);(5)获得 CCO 或合规委员会批准;(6)先以仅监控模式部署规则,再启用拦截(影子模式);(7)在影子期确认规则行为符合预期后,启用规则拦截功能。

使用历史订单对规则进行回测:

启用新规则或修改阈值之前,应使用有代表性的历史订单样本对规则进行回测。回测可以揭示:预期拦截率(会被拦截的订单占比)、误报率(会被拦截但实际上合规的订单占比),以及漏报率(应被拦截但未被发现的订单占比)。这些数据有助于校准阈值,并帮助合规团队预判新规则带来的运营影响。

误报分析:

误报率过高会损害合规系统的公信力,并增加运营摩擦。如果交易员和顾问经常因为认为软拦截无效而予以覆盖,就可能产生“警报疲劳”,进而开始不经适当评估便覆盖拦截——包括有效的拦截。合规团队应跟踪每条规则的覆盖率,并调查覆盖率超过既定阈值的规则(例如,覆盖率超过 50% 的规则)。补救措施可能包括调整阈值、完善规则逻辑,或将规则从软拦截重新归类为监控警报。

规则调优:

规则调优是持续调整阈值和参数的过程,旨在优化发现真实违规与尽量减少误拦截之间的平衡。调优应以数据为依据:合规团队分析拦截率、覆盖率以及被覆盖交易的结果,以判断阈值是否经过适当校准。调优决策应记录在案,并由 CCO 批准。

规则版本控制:

合规规则集应像软件代码一样进行版本控制。每次规则变更——新增、修改、阈值调整或停用——都应记录生效日期、变更人员、审批情况和变更原因。版本控制使合规团队能够重建任一历史日期生效的规则集;对于需要证明特定交易发生时采用了哪些控制措施的监管检查和调查,这一点至关重要。

监管变更管理:

法规发生变化时,合规团队必须评估其对盘前合规规则集的影响,并实施必要的修改。这要求团队监控监管动态(SEC 发布的信息、FINRA 监管通知、交易所规则变更),分析其对现有规则的影响,酌情修改或新增规则,对修改后的规则进行回测,并在法规生效日期前部署变更。监管变更管理日历应跟踪即将到来的生效日期以及规则修改的进度。

实例

references/examples.md 中提供了三个完整示例,展示端到端场景:(1)为多托管机构的 RIA 设计交易前合规规则引擎;(2)为拥有投行关联公司的经纪交易商实施受限名单管理;(3)围绕历史遗留的集中持仓配置家庭级集中度限额。

常见陷阱

  • 仅实施账户级集中度限额,却不汇总家庭级数据,导致相关账户的家庭整体风险敞口不断累积并过度集中
  • 未将受限名单条目同步到整个企业集团(母公司、子公司和关联公司),留下监管机构专门检查的漏洞
  • 将所有合规违规都设为硬性拦截,造成运营停滞;区分硬性拦截和软性拦截对于兼顾合规与交易效率至关重要
  • 未跟踪或分析覆盖规则的模式,错过阈值校准不当或顾问经常绕过准则等系统性问题
  • 未经回测或影子模式测试便将新规则直接部署到生产环境,导致意外拦截并干扰交易运营
  • 未及时更新受限名单或观察名单——本应移除的证券仍留在名单中,拦截了合法交易;本应添加的证券却被遗漏
  • 忽视合规检查延迟,导致缓慢的规则评估降低时效性订单的执行质量
  • 不考虑账户规模差异,对所有账户采用相同的集中度限额,未考虑小型账户因持仓规模限制而需要不同阈值
  • 未在同一家庭的多个账户之间协调洗售检测,削弱税损收割计划的效果
  • 未对合规规则进行版本控制,导致监管审查历史交易时无法还原当时生效的规则集
  • 将交易前合规视为一次性实施工作,而非需要定期回测、调整和管理法规变更的持续流程
  • 允许在缺乏规范文档记录的情况下覆盖合规规则;监管机构要求提供覆盖理由记录时,这会带来审查风险
  • 仅检查买单的集中度限额,却不考虑其他持仓的卖单可能改变分母(投资组合总价值),使剩余持仓超过其百分比阈值
  • 依赖单一 ESG 数据提供商,且不定期验证,导致公司分类随时间变化时筛查结果过时或不一致
  • 未区分监管持仓限额(必须设为硬性拦截)与内部风险准则(可设为软性拦截),导致拦截类型不当,造成不必要的僵化或控制不足

交叉引用

  • order-lifecycle(trading-operations 插件):交易前合规是订单生命周期中的关键阶段,会在订单生成后、路由前拦截订单;订单生命周期技能提供了更广泛的背景,说明合规检查在交易流程中的位置
  • post-trade-compliance(trading-operations 插件):交易后合规监控会检测交易前未发现的违规行为,包括执行后因市场波动而产生的违规行为;交易前合规与交易后合规共同构成完整的合规监控框架
  • order-management-advisor(advisory-practice 插件):OMS 执行合规检查工作流、管理硬性和软性拦截状态,并将覆盖操作的相关文档记录为交易审计追踪的一部分
  • investment-suitability(compliance 插件):在评估某项交易是否符合客户的风险状况、投资目标和财务状况时,适当性与最佳利益分析会与交易前合规有所重叠
  • conflicts-of-interest(compliance 插件):限制名单管理和个人交易限制是直接的利益冲突控制措施;利益冲突技能涵盖了识别和缓解利益冲突的更广泛框架
  • investment-policy(wealth-management 插件):投资政策声明(IPS)的约束条件——资产类别范围、质量最低标准、排除名单——均以交易前合规规则的形式编码;IPS 变更后,必须相应更新合规规则配置
  • portfolio-management-systems(advisory-practice 插件):PMS 会生成交易建议,供交易前合规引擎使用;合规检查结果会反馈至 PMS,以便通知投资组合经理哪些交易被拦截或标记
  • books-and-records(compliance 插件):覆盖操作文档、合规检查结果和规则变更记录均属于公司的账簿和记录,须遵守 SEC 和 FINRA 的保存要求
  • settlement-clearing(trading-operations 插件):结算时间会影响先卖后买违规检测和可用现金检查;T+1 结算周期决定了交易前合规必须在何时验证资金或证券是否可用

评论

支持 Markdown