大规模 AML 监管报告架构设计

为什么 AML 报告是银行最棘手的数据问题

表面上看，AML 监管报告似乎只是一个数据问题。监管机构——加拿大的 FINTRAC、美国的 FinCEN——要求报告特定交易模式：超过阈值的电子资金转账（EFTR）、超过阈值的现金交易（CTR）、可疑行为（STR）和异常交易（UTR）。获取数据、整理格式、提交即可。

实际难点在于，监管机构需要的是 相互关联的 全貌：谁发起资金转移、谁收到资金、谁控制账户、各方处于何种 KYC 等级、哪个外汇环节经过了哪家中介，以及会话期间触发了哪些网络安全信号。这些背景信息分散在 数百个源系统中 ——零售核心银行、资本市场、商业贷款、电汇、外汇、资金管理、客户中心、身份系统——各自有不同的数据结构、刷新频率和责任主体。

FINTRAC 第二套监管要求明确体现了这一点：约30个不同用例，每个都将金融交易与外汇、客户/账户及网络安全数据关联，覆盖私人银行、零售、资本市场和商业业务。从架构角度看，这不是一个报表项目，而是一个企业集成平台。

端到端参考架构

我们为一线银行设计的平台拥有相同的整体结构——五个逻辑层，每层均可独立扩展和独立审计：

• 源数据摄取。 从核心银行、Workday HR、客户中心、外汇引擎和网络安全信号捕获变更数据。有些系统发布事件；旧系统提供批量导出，我们用经过模式验证的加载器加以封装。
• 流式数据主干。 Kafka 式事件流承载金融交易、KYC 更新、制裁命中及账户生命周期事件。主题按客户或账户分区，以保持每个实体内的事件顺序。
• 关联与数据丰富。 流处理作业将交易事件与客户主数据、账户层级、外汇环节、KYC 档案和历史行为关联。输出为符合监管格式、关联完整的可报告记录。
• 检测与规则。 Actimize 承载 STR/UTR 的 AML 检测场景；确定性阈值规则与参考数据驱动 EFTR/CTR。输出为候选申报及其证据组成的数据流。
• 申报与数据血缘。 申报服务按照 FINTRAC 的模式格式化 EFTR/STR/CTR/UTR 载荷，签名后通过安全通道发送。每条记录都携带可追溯到源事件的血缘 ID。

该平台基于 Azure ——AKS 用于容器化服务， PostgreSQL 用于监管申报存储，Azure Storage 用于原始事件，Azure Monitor / Sentinel 用于安全与可观测性。在加拿大五大银行的部署中，我们增强了 AKS 上的 Actimize ，搭配 PostgreSQL，专门支持大规模 CTR 功能。

为什么采用事件流，而非夜间批处理

过去，AML 报告依靠夜间批处理。当报告义务以天为单位衡量时，这种方式有效。如今，FINTRAC 的期望——坦率地说，也包括银行自身的风险偏好——更接近 近实时。无论底层电汇何时结算，EFTR 都需要可靠触发。将实时行为信号与交易关联，也有助于 STR。

事件流提供了批处理无法实现的三项能力。第一， 感知背压的数据摄取：上游变慢不会导致监管数据管道瘫痪。第二， 重放：规则变化时，我们可以重新处理受影响的时间窗口，无需触碰源系统。第三， 按实体保证顺序：通过按客户或账户分区，即使每秒有一万个事件流过，也能保证交易修订在原始交易之后处理。

成本方面，AKS 提供随业务量扩展的弹性计算——月末、年末以及外汇波动高峰都无需长期预置额外容量。

将威胁模型视为核心架构成果

AML 报告处于充满对抗的环境中。不法分子不断试图规避阈值、拆分交易或污染 KYC 数据。优秀的 AML 平台不仅合规，还能应对对抗行为。

我们在这一领域交付的每个架构都附带明确的威胁模型：对每个组件边界开展 STRIDE 分析，对每个存储进行数据分类，并为服务间调用配置最小权限身份。机密存储在 Azure Key Vault 中；服务身份采用托管身份，而非静态凭证。KYC 文档、客户个人身份信息等敏感载荷，采用按业务线配置的信封密钥加密。

监管申报方面，每份载荷均有签名，签名密钥由硬件保护。这意味着，无论是被篡改还是被重放的申报，不仅 FINTRAC 能发现，我们自己的审计管道也能检测到。

KYC 与货币服务企业准入

AML 报告位于以下环节的下游： KYC。KYC 出错，报告就会出错。我们参与过的一项颇有意思的战术性工作，是为以下客户设计准入流程： 货币服务企业 （MSB）——这类客户确实具有高风险，KYC 尽职调查要求也相当严格。

架构模式如下：筛查管道将 MSB 注册、制裁名单和受益所有权数据引入客户信息增强图谱；为 AML 调查团队提供战术性案件管理界面；建立审计轨迹，将每个准入决策关联到支撑证据。战术方案为战略性客户中心的完善争取时间，而两者输出格式相同，因此战略平台无需返工即可接收数据。

在两家一线银行交付的经验

• 将监管机构的数据模式视为契约。 从第一天起就按其构建。不要让内部数据结构渗入申报层。
• 关联才是工作的核心。 EFTR/STR 规则相对容易。正确关联30个用例中的客户、账户、外汇和网络安全数据，占据了80%的工程投入。
• 数据血缘不可或缺。 当监管机构质疑一份申报时，你需要在几分钟内展示构成该申报的所有事件，而不是花上几天。
• 架构评审委员会的批准不是走过场。 应将其作为推动严格落实的机制。我们经历的评审曾发现数据驻留和密钥管理问题，如果留到后期解决，代价会非常高。
• 云原生 ≠ 仅限云端。 部分上游系统还会在本地运行多年。架构必须正视混合集成的现实。

您的银行或金融科技企业也有此需求？

SEYSO 曾为加拿大和美国多家一线银行设计 AML 和监管报告平台，涵盖 LCTR、EFTR、STR、UTR、CTR、KYC 及 CFT 义务。如果您正在推进金融犯罪防范技术现代化、迁移 Actimize 平台或规划新的监管项目，我们期待与您交流。您带来监管义务和错综复杂的源系统，我们提供架构。