AI Financial Crime Typology / Scenario Coverage / SAR Evidence Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_FINANCIAL_CRIME_TYPOLOGY_SCENARIO_COVERAGE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

重要说明: 本文用于 AI 金融犯罪控制架构分析，不构成法律意见、合规结论、SAR filing decision、监管解释或模型验证报告。是否调查、升级、关闭 case 或提交 SAR，必须由具备权限的人类 Compliance / BSA / AML owner 根据机构政策、司法辖区规则、事实证据和适用监管要求决定。AI 可以辅助识别、汇总、检索、解释和质检，不能替代 SAR 决策责任。

---

Source Anchors

核心导读

AI financial crime architecture 的成熟度不取决于“模型找出更多 alerts”或“SAR narrative 写得更快”，而取决于机构能否证明 typology、scenario、red flag、data signal、alert、case evidence、human decision 和 SAR narrative 之间存在可追溯控制链。

金融犯罪风险不是一个统一标签。structuring、mule account、elder exploitation、romance scam、trade-based money laundering、sanctions evasion、terrorist financing、cyber-enabled fraud、check fraud、funnel account 等 typology 对数据、场景、证据和调查路径的要求不同。AI 如果只优化全局 precision，会把低覆盖、弱证据、不可解释和责任不清的问题隐藏在平均指标里。

可用的架构目标是 typology-driven control system：先定义覆盖范围和风险假设，再把场景、规则、模型、调查证据和人类判断串起来。AI 是调查增强和证据组织能力，不是合规责任转移机制。

问题定义

金融犯罪 AI 常见误区是把问题压缩成“减少 false positives”。这当然重要，但不是核心控制问题。真正需要回答的是：

• 哪些 typologies 在当前产品、客户、渠道和地区范围内被覆盖？
• 每个 typology 由哪些 scenarios 表达，哪些 red flags 触发？
• 数据是否足以支撑这些 red flags，还是存在 blind spot？
• alert 如何进入 case，case 如何积累证据，SAR consideration 如何记录？
• AI 生成的摘要、解释或 narrative 是否能被人类 investigator 独立验证？
• 规则、模型、prompt、检索语料、case disposition 的版本是否可回放？

如果缺少 typology/scenario architecture，AI 系统会出现三类结构性失败：

因此，目标不是“让 AI 替 AML 做判断”，而是让金融犯罪控制系统能够在复杂数据和不断变化的 typology 下保持覆盖、证据、责任和改进闭环。

核心原理/方法

Typology library 是控制语义层

Typology library 应维护风险类别、行为模式、相关产品、客户类型、地区、渠道、red flags、数据需求、调查路径和来源锚点。它不是文档库，而是 scenario、rule、model、case template 和 eval dataset 的上游语义层。

Scenario inventory 是执行层

每个 typology 应拆成可监控 scenario。Scenario 要说明：触发条件、时间窗口、数据字段、阈值逻辑、模型特征、预期证据、排除条件、调查提示和版本。AI 可以帮助发现相似 case、提炼行为链，但 scenario owner 需要确认逻辑和风险假设。

Red flag 到 data signal 必须可追溯

Red flag 是监管、行业和机构政策语言；data signal 是系统可以计算或检索的字段。两者之间需要 mapping：哪些交易、账户、客户、设备、渠道、IP、payee、merchant、note、case history、external feed 支撑哪个 red flag。

Alert-case-SAR traceability 不能被 narrative 替代

LLM 生成 narrative 只是表达层。真正证据链应包含 alert reason、scenario version、source events、investigator actions、supporting documents、customer information、transaction timeline、disposition rationale、SAR consideration 和 human approval。

评测按 typology 分层

全局 precision/recall 不足以治理金融犯罪 AI。评测应按 typology、scenario、产品、渠道、客户分层、地区、数据质量、case disposition 进行切片，重点关注 coverage gap、false negative proxy、alert aging、investigator override 和 drift。

人类合规责任不可外包

AI 可以排序、摘要、聚类、补充证据清单、检查 narrative completeness，但不能拥有 SAR 决策。架构必须记录人类调查者和审批者的判断依据、覆盖哪些事实、排除了哪些解释，以及 AI 输出是否被采纳或修改。

系统/架构模型

推荐架构把 typology control plane 放在 alert engine 和 case management 之上。

threat intelligence / advisories / internal loss cases
  -> typology library
  -> scenario inventory and red flag mapping
  -> data signal catalog and lineage
  -> rules / models / graph analytics / AI triage
  -> alert generation and prioritization
  -> case investigation workspace
  -> evidence bundle and narrative assist
  -> human SAR consideration / disposition
  -> QA / audit / model evaluation
  -> typology and scenario update

关键组件：

AI 的位置应被限制为增强层：entity resolution、case clustering、anomaly explanation、evidence retrieval、narrative completeness check、investigator assist、QA sampling。它不应成为没有 typology grounding 的黑箱 alert generator。

关键机制与取舍

覆盖率 vs 噪音

提高 typology 覆盖通常会增加 alert volume。成熟取舍不是简单调低阈值，而是使用 risk-based prioritization、case batching、entity aggregation、scenario suppression rules、QA sampling 和 investigator capacity planning。覆盖缺口要显性接受或补数据，不能被 volume 压力掩盖。

规则场景 vs 机器学习

规则可解释、便于审计，适合已知 red flags；模型适合复杂行为组合、网络关系和弱信号聚类。金融犯罪 AI 不应二选一：规则定义可解释锚点，模型用于排序、扩展和发现异常，LLM 用于证据组织和质量检查。

SAR narrative automation vs confidentiality

SAR 相关内容高度敏感。LLM assist 必须限制访问、避免不必要外传、保留输入输出、支持 redaction、记录人工修改，并确保 narrative 中每个关键事实可回源。不能让外部通用模型接触未授权 SAR-sensitive 内容。

外部 typology feed vs 内部案例学习

FinCEN、FFIEC、FATF、执法趋势和同业信息提供外部锚点；内部损失、case disposition、客户投诉、fraud ops 和 branch intelligence 提供本地模式。架构应支持两类来源进入 typology backlog，并区分来源可信度和适用范围。

实时拦截 vs 事后监控

不是所有金融犯罪场景都适合实时阻断。账户开立、支付、check deposit、wire、P2P、card、digital onboarding 的 latency 和客户摩擦不同。控制设计应区分 real-time interdiction、near-real-time alert、batch surveillance、periodic review，并记录为什么选择某种时效。

AI 解释 vs 调查证据

模型解释可以帮助 investigator 理解排序理由，但不能替代交易、客户、账户、文件和外部信息等证据。架构上必须避免把 SHAP、LLM rationale 或 risk score 当作事实证据。

证据与控制

金融犯罪 AI 的证据包应支持从 scenario 到 case disposition 的 replay。

建议监控指标：

• Typology 到 scenario 的覆盖率和未覆盖理由。
• Scenario 到 data signal 的完整度、数据延迟和字段缺失率。
• 按 typology 的 alert volume、case conversion、SAR consideration、closure rationale。
• Investigator override、AI summary correction、narrative completeness defect。
• Alert aging、case backlog、重复 alert suppression 效果。
• 外部 advisory 发布到 typology/scenario 更新的周期。
• QA 发现的 evidence gap、unsupported conclusion、confidentiality exception。

金融零售/AI产品场景

数字账户开户与 synthetic / mule 风险

AI 可用于关联设备、身份、地址、payee、行为序列和历史 case，但 scenario 必须明确哪些 red flags 指向 synthetic identity、mule recruitment 或 account farming。证据应覆盖 identity proofing 结果、资金进入/流出模式、设备关系、账户网络和人工判断。

老人金融剥削与 romance scam

这类场景不能只看交易金额异常。需要结合客户年龄、历史行为变化、新 payee、通信渠道、分支机构记录、客服备注和客户 vulnerability signals。AI 可帮助生成 investigator checklist，但应谨慎处理敏感属性和解释边界。

现金和转账 structuring

规则窗口、账户聚合、branch / ATM / wire / ACH 渠道组合和历史行为基线都很关键。AI 可用于发现跨账户和跨渠道模式，但每个 alert 应能回放时间线、金额拆分、主体关系和排除因素。

Check fraud 与 deposit risk

场景覆盖应连接 check image analysis、账户 tenure、deposit channel、funds availability、return history、payee network 和 downstream transfer。AI 可辅助图像/文本特征识别与风险排序，但拦截策略必须平衡客户可用性、误伤和资金损失。

小企业和商户交易异常

需要区分正常季节性波动、经营模式变化、merchant category mismatch、pass-through activity 和潜在洗钱。AI 的价值在于行为聚类和 peer comparison，但 case evidence 不能只依赖同群异常分数。

跨境汇款与制裁相关风险

金融犯罪 AI 需要和 sanctions screening、customer due diligence、transaction monitoring、adverse media、geography risk 保持边界清晰。AI 可以组织证据和提示风险点，但 sanction match disposition 和 SAR consideration 需要独立责任链。

反模式

• 只汇报 alert precision，却没有 typology coverage matrix。
• 把监管 red flags 写进文档，未映射到数据字段、scenario 和 evidence。
• LLM 生成 SAR narrative 后，关键事实无法点击回源。
• 使用 AI summary 关闭 case，但没有记录人工核验和关闭理由。
• 用一个全局阈值管理所有产品、渠道、客户和 typology。
• 场景版本变化后，历史 case 无法按当时规则 replay。
• 把 false positive reduction 当作唯一目标，导致高风险低频 typology 被削弱。
• Vendor 模型输出只有 score，没有 scenario grounding、data lineage 和 QA evidence。
• 外部 advisory 更新后，只发邮件通知，没有进入 typology backlog、scenario update 和 eval dataset。
• 忽视 SAR confidentiality，把敏感调查内容送入未授权 AI 工具。

最终心智模型

金融犯罪 AI 的根本架构不是“模型替人抓坏交易”，而是“用可治理的 typology 系统把风险假设、场景覆盖、数据证据、调查行动和人类判断连接起来”。

可用一个控制链检验方案：

typology -> scenario -> red flag -> data signal -> alert
  -> case evidence -> human disposition -> SAR consideration
  -> QA / audit -> typology update

如果某个环节只能依靠模型解释或人工记忆补齐，系统就不具备可审计性。成熟金融犯罪 AI 应让 investigator 更快看见事实、让合规 owner 更清楚承担决定、让 audit 能回放证据、让 typology 变化能持续进入检测和评测。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。