AI Day 33
AI Day 33: 金融AI(3)：合规科技与监管AI — Compliance as Code
合规科技(RegTech) = 利用AI/NLP/知识图谱等技术，将金融合规从劳动密集型的成本中心转变为自动化、智能化的效率引擎，在满足监管要求的同时降低合规成本60-80%。
2026-05-04
合规科技RegTechKYCAML监管报告合规AI模型治理Web3合规MiCATravelRule
日期: 2026-05-04 阶段: 第三阶段 — 金融零售AI应用 (Day 31-42) 标签: #合规科技 #RegTech #KYC #AML #监管报告 #合规AI #模型治理 #Web3合规 #MiCA #TravelRule
学习路径
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1-7: Transformer/量化/训练/Prompt/RAG/向量DB/FineTune ✅
│ ├── Day 8-11: 推理优化/长上下文/多模态/Reasoning ✅
│ └── Day 12-15: Agent/MCP/评估/阶段总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30) ✅
│ ├── Day 16-18: 应用架构/安全/可观测性 ✅
│ ├── Day 19-21: 生产级RAG三部曲 ✅
│ ├── Day 22-25: Agent工程化四部曲 ✅
│ └── Day 26-30: 成本/编排/测试/案例/总结 ✅
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31: 金融AI(1)：智能风控与反欺诈 ✅
│ ├── Day 32: 金融AI(2)：智能投顾与量化策略 ✅
│ ├── Day 33: 金融AI(3)：合规科技与监管AI ← 你在这里
│ ├── Day 34: 金融AI(4)：信贷全链路AI
│ ├── Day 35: 金融AI(5)：保险科技AI
│ ├── Day 36: 零售AI(1)：推荐系统架构
│ ├── Day 37: 零售AI(2)：智能客服与对话系统
│ ├── Day 38: 零售AI(3)：供应链预测与优化
│ ├── Day 39: 零售AI(4)：智能营销与用户增长
│ ├── Day 40: 零售AI(5)：全渠道数据中台
│ ├── Day 41: CeFi × DeFi × AI 融合架构(上)
│ └── Day 42: CeFi × DeFi × AI 融合架构(下)
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
一句话定义
合规科技(RegTech) = 利用AI/NLP/知识图谱等技术，将金融合规从劳动密集型的成本中心转变为自动化、智能化的效率引擎，在满足监管要求的同时降低合规成本60-80%。
范式转变：合规从成本中心到效率引擎
传统合规 (Cost Center) AI驱动合规 (Efficiency Engine)
───────────────────────────── ─────────────────────────────
├── 人海战术: 大量合规人员手工审查 ├── 自动化: AI处理90%的标准审查
├── 被动响应: 监管发文才去改流程 ├── 主动预警: 实时追踪法规变更
├── 规则滞后: 新规执行滞后3-6个月 ├── 快速适配: LLM解读新规1-2周落地
├── 一刀切: 统一审查标准效率低 ├── 风险分层: 智能分级差异化审查
├── 报告耗时: 季报/年报手工编写数周 ├── 自动生成: AI辅助报告数小时完成
└── 成本高企: 大型银行合规支出$1B+/年 └── 降本增效: 合规成本下降60-80%
关键数字 (2025-2026):
• 全球RegTech市场规模: $19.5B (2025) → $44.5B (2028), CAGR 31%
• 全球Top 50银行平均合规支出: $900M/年
• AI可自动化的合规任务比例: 70-80%
• KYC人工审查平均耗时: 24分钟/案件 → AI辅助: 3分钟/案件
合规科技全景图
┌─────────────────────────────┐
│ 金融合规科技 (RegTech) │
└──────────┬──────────────────┘
│
┌──────────┬───────────┼───────────┬──────────┐
▼ ▼ ▼ ▼ ▼
┌──────────┐┌──────────┐┌──────────┐┌──────────┐┌──────────┐
│ KYC/AML ││ 监管报告 ││ 合规知识 ││ 模型治理 ││ Web3合规 │
│ 自动化 ││ 自动化 ││ 管理 ││ MRM ││ 链上监控 │
└────┬─────┘└────┬─────┘└────┬─────┘└────┬─────┘└────┬─────┘
│ │ │ │ │
┌────┴────┐ ┌────┴────┐ ┌───┴─────┐ ┌───┴─────┐ ┌───┴─────┐
│身份验证 │ │XBRL提取 │ │法规RAG │ │SR 11-7 │ │Travel │
│制裁筛查 │ │LLM报告 │ │变更追踪 │ │EU AI Act│ │Rule │
│STR生成 │ │影响分析 │ │合规QA │ │可解释性 │ │MiCA │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
KYC/AML 自动化
KYC (Know Your Customer) 全流程AI
客户注册/入网 (Onboarding)
│
├─ Step 1: 身份验证 (Identity Verification)
│ ├── 文档OCR: 护照/身份证/驾照自动识别
│ │ ├── 技术: CNN + Transformer OCR (准确率 99.2%+)
│ │ ├── 防伪检测: 证件真伪鉴别(水印/微缩文字/紫外特征)
│ │ └── 活体检测: 3D人脸识别 + 动作指令防止照片/视频攻击
│ │
│ ├── 身份交叉验证:
│ │ ├── 政府数据库比对 (身份证号/社保号)
│ │ ├── 信用局数据验证 (征信报告基本信息)
│ │ └── 电信运营商验证 (手机号实名信息)
│ │
│ └── AI增强 (2025-2026新趋势):
│ ├── Deepfake检测: 防止AI生成假证件/假人脸
│ ├── 多模态验证: 证件 + 人脸 + 声纹 + 行为
│ └── 无感验证: 结合设备指纹/行为生物特征
│
├─ Step 2: 制裁名单筛查 (Sanctions Screening)
│ ├── 筛查数据源:
│ │ ├── OFAC (美国财政部外国资产控制办公室)
│ │ ├── EU Consolidated Sanctions List
│ │ ├── UN Security Council Sanctions
│ │ ├── PEP (政治公众人物) 数据库
│ │ └── 负面新闻/不利媒体 (Adverse Media)
│ │
│ ├── NLP核心挑战 — 名称匹配 (Name Matching):
│ │ ├── 模糊匹配: "Mohammed" vs "Muhammad" vs "Mohamad"
│ │ ├── 跨语言: "习近平" vs "Xi Jinping" vs "شي جين بينغ"
│ │ ├── 别名/化名: 同一人多个名字
│ │ └── 同名异人: 常见名字大量误报
│ │
│ ├── AI解决方案:
│ │ ├── 传统: 编辑距离(Levenshtein) + Soundex → 误报率30-40%
│ │ ├── ML时代: 训练专用Name Matching模型 → 误报率10-15%
│ │ └── LLM时代: 语义理解+上下文消歧 → 误报率3-5%
│ │
│ └── 关键指标:
│ ├── 召回率(Recall): 必须接近100% — 漏放一个制裁对象代价极高
│ ├── 精确率(Precision): 越高越好 — 减少人工审核负担
│ └── 审查效率: AI处理80%的明显非匹配，人工聚焦高风险20%
│
├─ Step 3: 客户风险评级 (Customer Risk Assessment)
│ ├── 维度:
│ │ ├── 客户类型: 个人/企业/PEP/高净值
│ │ ├── 地理风险: 高风险国家/地区(FATF灰名单)
│ │ ├── 业务性质: 现金密集/跨境/虚拟资产
│ │ └── 交易模式: 预期交易量/频率/金额
│ │
│ └── AI评级模型: ML分类器 → 低/中/高风险 → 差异化审查力度
│
└─ Step 4: 持续监控 (Ongoing Monitoring)
├── 交易监控: 实时对比客户行为 vs 预期模式
├── 定期复审: 根据风险等级定期重新KYC (1年/2年/5年)
└── 触发事件: 名单更新/负面新闻/异常交易 → 重新评估
AML (Anti-Money Laundering) — 反洗钱AI
反洗钱检测流水线 (AML Detection Pipeline)
│
├─ Layer 1: 规则引擎 (Rule-Based)
│ ├── 大额交易报告(CTR): 单笔超过阈值(中国: ¥50,000现金/¥200,000转账)
│ ├── 结构化交易(Structuring): 多笔刻意低于阈值
│ ├── 快进快出(Rapid Movement): 资金快速流入流出
│ └── 问题: 产生大量误报(False Positive率 95-99%)
│
├─ Layer 2: 机器学习模型 (ML-Based)
│ ├── 特征工程:
│ │ ├── 交易特征: 金额/频率/时间/对手方
│ │ ├── 网络特征: 转账图谱中心性/集群系数
│ │ ├── 行为特征: 与历史模式偏差度
│ │ └── 客户特征: 职业/收入/资产
│ │
│ ├── 模型类型:
│ │ ├── 异常检测: Isolation Forest / Autoencoder
│ │ ├── 分类模型: XGBoost / LightGBM (标注数据有限时)
│ │ └── 图神经网络: GNN检测洗钱网络(最前沿)
│ │
│ └── 效果: 误报率从95% → 50-60% (仍然较高，但已大幅改善)
│
├─ Layer 3: 知识图谱 (Knowledge Graph)
│ ├── 节点: 人/公司/账户/地址/设备
│ ├── 关系: 转账/持股/亲属/共用设备
│ ├── 推理: 发现隐性关联(A → B → C → D的间接洗钱链路)
│ └── 价值: 将单笔可疑交易升级为"洗钱网络"的全貌
│
└─ Layer 4: LLM增强 (LLM-Enhanced)
├── STR自动生成: 可疑交易报告(Suspicious Transaction Report)草稿
├── 案件摘要: 将复杂交易链路用自然语言描述
├── 调查辅助: 合规分析师向LLM提问，获取案件分析
└── 跨语言: 处理多语言交易备注/通信内容
STR(可疑交易报告)自动生成 — LLM实战
传统STR编写流程 (2-4小时/份):
合规分析师 → 手动查询交易记录 → 整理时间线
→ 撰写叙述性描述 → 填写监管表格 → 审核提交
AI辅助STR流程 (20-30分钟/份):
触发规则/模型告警 → AI自动收集相关数据
→ LLM生成STR草稿 → 分析师审核修改 → 提交
┌─────────────────────────────────────────────────────┐
│ STR Auto-Generation Pipeline │
│ │
│ Alert Triggered │
│ │ │
│ ▼ │
│ Data Aggregation │
│ ├── 客户基本信息(KYC档案) │
│ ├── 涉及交易清单(时间/金额/对手方) │
│ ├── 历史告警记录 │
│ ├── 制裁/PEP筛查结果 │
│ └── 负面新闻搜索结果 │
│ │ │
│ ▼ │
│ LLM Report Generation │
│ ├── Prompt: 结构化模板 + 监管要求 + 聚合数据 │
│ ├── Output: 叙述性报告(时间线/行为描述/风险评估) │
│ └── Format: 符合FinCEN/PBOC/FCA等各地监管格式 │
│ │ │
│ ▼ │
│ Human Review & Submission │
│ ├── 合规分析师审核/修改 │
│ ├── 高级合规官签批 │
│ └── 加密提交至监管机构 │
└─────────────────────────────────────────────────────┘
效果指标:
• 编写时间: 3小时 → 25分钟 (↓86%)
• 报告质量一致性: 人工差异大 → AI标准化输出
• 分析师产能: 5份/天 → 20份/天
• 关键风险: LLM幻觉 — 必须人工审核事实准确性
监管报告自动化
监管报告的痛点与AI机遇
金融机构面临的报告负担:
• 美国银行平均需遵守: 750+ 联邦/州法规
• 欧洲银行(MiFID II/CRD V/DORA等): 数百份定期报告
• 中国银行(1104报表体系): 70+张监管报表
传统流程的问题:
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 数据提取 │ → │ 手工整理 │ → │ 格式填报 │ → │ 审核提交 │
│ (3-5天) │ │ (3-5天) │ │ (2-3天) │ │ (1-2天) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
总耗时: 2-3周/次，人力: 10-20人
AI自动化后:
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 自动抽取 │ → │ AI校验 │ → │ 自动生成 │ → │ 人工审核 │
│ (自动) │ │ (自动) │ │ (自动) │ │ (1-2天) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
总耗时: 2-3天，人力: 2-3人(审核)
XBRL与监管数据提取
XBRL (eXtensible Business Reporting Language):
• 全球监管报告标准格式
• 将财务数据标记为机器可读的标签
• 挑战: 标签映射(Tagging)需要领域专家
AI在XBRL中的应用:
┌──────────────────────────────────────────────┐
│ 自动XBRL标签映射 (Auto-Tagging) │
│ │
│ 输入: 财务报表原始数据 │
│ "应收账款净额: ¥125,000,000" │
│ │
│ NLP处理: │
│ 1. 实体识别: "应收账款净额" → 会计科目 │
│ 2. 语义匹配: → XBRL标签 "AccountsReceivable │
│ NetCurrent" │
│ 3. 数值提取: ¥125,000,000 │
│ 4. 维度标注: 币种=CNY, 期间=2026Q1 │
│ │
│ 输出: 结构化XBRL实例文档 │
│ 准确率: 92-96% (仍需人工复核关键科目) │
└──────────────────────────────────────────────┘
LLM辅助监管报告生成
场景1: 定期监管报告 (Periodic Regulatory Reports)
────────────────────────────────────────────────
数据仓库 → ETL管道 → 监管数据集市
│
▼
LLM Report Generator
├── 定量部分: 自动填充数据表格(资本充足率/流动性覆盖率等)
├── 定性部分: LLM生成管理层讨论与分析(MD&A)
│ ├── 输入: 本期数据 + 上期数据 + 行业趋势
│ ├── 输出: "本报告期内，本行资本充足率为13.2%，
│ │ 较上期提升0.3个百分点，主要由于..."
│ └── 风控: 数据引用必须可追溯到源系统
└── 格式适配: 自动转换为监管机构要求的格式
场景2: 法规变更影响分析 (Regulatory Change Impact Analysis)
────────────────────────────────────────────────────────
新法规发布 (如: Basel III.1最终规则)
│
▼
LLM解读管道:
├── Step 1: 文档解析 — 提取新规关键条款
│ "新规将标准法下的风险权重调整为..."
│
├── Step 2: 差异分析 — 对比现行规则 vs 新规
│ "变更1: 住房抵押贷款风险权重从35% → 40% (LTV>80%)"
│ "变更2: 运营风险资本计算方法从AMA → 新标准法"
│
├── Step 3: 影响评估 — 量化对本机构的影响
│ "预估影响: 资本充足率下降0.5-0.8个百分点"
│ "受影响业务线: 零售信贷、运营风险"
│
└── Step 4: 行动建议 — 生成实施计划
"建议: 1) IT系统改造(3个月) 2) 压力测试(1个月)
3) 报表调整(2个月) 4) 培训(持续)"
价值: 从"新规发布→影响评估完成"的周期从 4-8周 → 1-2周
合规知识库
监管文件RAG系统
合规知识库架构 (Compliance Knowledge Base)
─────────────────────────────────────────
┌──────────────┐
│ 合规问答Agent │
│ (Compliance │
│ QA Agent) │
└──────┬───────┘
│ 用户提问
▼
┌────────────────┐
│ Query Router │
│ (问题分类路由) │
└───┬────────┬───┘
│ │
┌─────────▼──┐ ┌──▼─────────┐
│ 法规知识库 │ │ 案例知识库 │
│ (RAG) │ │ (RAG) │
└─────┬──────┘ └──────┬─────┘
│ │
┌────────▼────────────────▼────────┐
│ 向量数据库 │
│ ┌───────────┬────────────────┐ │
│ │ 法律法规 │ 监管问答/案例 │ │
│ │ 监管指引 │ 处罚决定书 │ │
│ │ 行业标准 │ 内部制度文件 │ │
│ │ 合规手册 │ 培训材料 │ │
│ └───────────┴────────────────┘ │
└──────────────────────────────────┘
数据源 (持续更新):
• 中国: 人民银行/银保监会/证监会公告
• 美国: Federal Register / SEC / OCC / CFPB
• 欧洲: EBA / ESMA / ECB Guidelines
• 国际: FATF / BIS / IOSCO
核心技术挑战:
1. 法律文本解析: 嵌套条款/交叉引用/定义术语
→ 需要法律领域专用Chunking策略
2. 版本管理: 法规频繁修订，需要时间点精确版本
→ 构建法规版本时间线图谱
3. 多法域冲突: 不同国家法规可能冲突
→ 明确法域标注 + 冲突检测
4. 答案准确性: 合规回答零容忍幻觉
→ 强制引用原文 + 置信度评分 + 人工审核
法规变更追踪系统
法规变更追踪管道 (Regulation Change Tracker)
──────────────────────────────────────────
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 数据采集 │ → │ 变更检测 │ → │ 影响分析 │ → │ 任务分发 │
└────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘
│ │ │ │
爬虫/API获取 NLP对比新旧文本 LLM评估影响 工单系统
监管官网更新 识别新增/修改/ 哪些业务线 分配给对应
行业新闻RSS 删除的条款 受影响 合规负责人
示例流程:
────────
[采集] 2026-05-01 银保监会发布《商业银行互联网贷款管理暂行办法修订》
[变更检测] NLP对比:
• 新增: 第15条 — AI模型用于信贷决策需满足可解释性要求
• 修改: 第8条 — 联合贷款出资比例从30%调整为25%
• 删除: 无
[影响分析] LLM评估:
• 影响等级: 高
• 受影响系统: 智能信贷审批系统、联合贷款管理系统
• 合规期限: 6个月
• 所需行动: 模型可解释性改造、出资比例参数调整
[任务分发]:
→ 信贷合规团队: 评估现有AI模型可解释性差距
→ IT部门: 系统参数调整排期
→ 法务部门: 合同条款修订
合规问答Agent
合规问答Agent架构 (Compliance QA Agent)
──────────────────────────────────────
用户: "我们要向美国客户提供加密货币交易服务，
需要满足哪些合规要求？"
Agent处理流程:
┌──────────────────────────────────────────────┐
│ Step 1: 意图识别 + 实体提取 │
│ 意图: 合规要求查询 │
│ 实体: {地域: 美国, 业务: 加密货币交易, │
│ 客户类型: 通用} │
│ │
│ Step 2: 多知识库检索 (Multi-source RAG) │
│ ├── 联邦法规: BSA/AML, SEC规则, CFTC规则 │
│ ├── 州法规: BitLicense(纽约), MTL(各州) │
│ ├── 行业指引: FinCEN加密货币指引 │
│ └── 案例: 已有的执法行动/处罚案例 │
│ │
│ Step 3: 结构化回答生成 │
│ ├── 注册要求: MSB注册 + 各州MTL申请 │
│ ├── KYC/AML: BSA合规计划 + SAR报告义务 │
│ ├── 证券法: 判断是否属于证券(Howey Test) │
│ ├── 税务: 1099-DA报告义务(2026生效) │
│ ├── Travel Rule: $3,000以上转账信息传递 │
│ └── 每条都附带法规原文引用和更新日期 │
│ │
│ Step 4: 风险提示 │
│ ⚠️ "以上为AI辅助分析，不构成法律意见。" │
│ ⚠️ "建议就具体合规方案咨询持牌律师。" │
│ ⚠️ "注意: SEC vs CFTC管辖权争议仍在进行中" │
└──────────────────────────────────────────────┘
关键设计原则:
1. 强制引用 (Mandatory Citation): 每个论断必须引用法规原文
2. 时效标注 (Temporal Awareness): 标注法规最后更新日期
3. 免责声明 (Disclaimer): AI不提供法律意见
4. 不确定性表达: 对争议领域明确标注不确定性
5. 审计日志: 记录每次问答，供合规审计
AI模型治理
模型风险管理 (Model Risk Management, MRM)
为什么金融AI需要特殊治理？
────────────────────────────
普通AI: 推荐错了一首歌 → 用户体验不佳
金融AI: 信贷模型偏差 → 歧视性贷款 → 巨额罚款 + 声誉损失
案例: 2019年Apple Card性别歧视事件
→ Goldman Sachs的信贷算法被指对女性不公
→ 引发纽约金融服务局调查
→ 教训: AI偏见在金融领域后果极其严重
模型风险管理框架:
┌────────────────────────────────────────────────┐
│ Model Risk Management │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 模型开发 │→ │ 模型验证 │→ │ 模型部署 │ │
│ │ Develop │ │ Validate │ │ Deploy │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌────▼─────┐ ┌────▼─────┐ ┌────▼─────┐ │
│ │ 数据治理 │ │ 独立复核 │ │ 持续监控 │ │
│ │ 公平性测试│ │ 压力测试 │ │ 性能衰减 │ │
│ │ 文档记录 │ │ 对抗测试 │ │ 漂移检测 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ 模型清单 (Model Inventory) │ │
│ │ 每个模型: ID/用途/风险等级/负责人/审计状态 │ │
│ └──────────────────────────────────────────┘ │
└────────────────────────────────────────────────┘
SR 11-7: 美联储模型风险管理指引
SR 11-7 (Supervisory Guidance on Model Risk Management)
─────────────────────────────────────────────────────
发布: 2011年(OCC/Fed)，至今仍是美国银行业模型治理金标准
核心要求:
1. 模型定义宽泛: 任何"将输入转化为输出的定量方法"都算模型
→ 包括ML模型、评分卡、VaR模型、LLM应用等
2. 三道防线:
├── 第一道: 业务线(模型开发者) — 自测 + 文档
├── 第二道: 模型验证团队(独立于开发) — 独立验证
└── 第三道: 内部审计 — 审查整个MRM框架
3. 关键要求:
├── 全面文档化: 模型假设/数据/方法/局限性
├── 独立验证: 由非开发团队验证模型
├── 持续监控: 部署后定期评估性能
└── 结果分析: 模型输出 vs 实际结果对比
LLM时代的新挑战 (SR 11-7 扩展):
┌──────────────────┬──────────────────────────────┐
│ SR 11-7要求 │ LLM应用的新挑战 │
├──────────────────┼──────────────────────────────┤
│ 模型文档化 │ LLM黑箱，内部机制难以文档化 │
│ 输入/输出明确 │ Prompt变化导致输出不确定 │
│ 独立验证 │ LLM行为难以穷举测试 │
│ 性能监控 │ 模型更新由供应商控制(GPT升级) │
│ 假设明确 │ LLM训练数据/偏见难以审计 │
│ 结果可追溯 │ 相同输入不同输出(温度≠0) │
└──────────────────┴──────────────────────────────┘
应对策略:
• 将LLM视为"辅助工具"而非"决策者" — Human-in-the-loop
• 构建确定性的Prompt模板 + 输出校验层
• 使用固定模型版本(API版本锁定)
• 建立LLM专项验证框架(Red-teaming/对抗测试)
EU AI Act 对金融AI的要求
EU AI Act (2024年8月生效, 2026年分阶段实施)
─────────────────────────────────────────
风险分级:
┌────────────┬──────────────────────────┬────────────┐
│ 风险等级 │ 金融AI场景 │ 要求 │
├────────────┼──────────────────────────┼────────────┤
│ 不可接受风险│ 社会评分用于信贷(非中国) │ 禁止 │
│ Prohibited │ │ │
├────────────┼──────────────────────────┼────────────┤
│ 高风险 │ 信贷评分/保险定价/ │ 严格监管 │
│ High Risk │ 就业筛选/生物特征识别 │ │
├────────────┼──────────────────────────┼────────────┤
│ 有限风险 │ 客服聊天机器人/ │ 透明度义务 │
│ Limited │ 情绪分析 │ │
├────────────┼──────────────────────────┼────────────┤
│ 最低风险 │ 垃圾邮件过滤/ │ 无额外要求 │
│ Minimal │ 内部数据分析 │ │
└────────────┴──────────────────────────┴────────────┘
高风险AI系统要求(金融相关):
1. 风险管理系统: 全生命周期风险识别/评估/缓释
2. 数据治理: 训练数据质量/代表性/偏见检测
3. 技术文档: 详细记录系统设计/算法/数据
4. 记录保存: 自动日志记录，可追溯
5. 透明度: 向用户说明AI参与决策
6. 人类监督: Human-in-the-loop / Human-on-the-loop
7. 准确性/鲁棒性/安全性: 持续测试和验证
罚则: 违规最高罚款 €35M 或全球营收7% (取较高者)
可解释性 (Explainability) — 金融AI的核心要求
为什么金融AI必须可解释？
─────────────────────────
1. 监管要求: "申请人有权知道拒贷原因" (ECOA/GDPR)
2. 公平性审计: 证明模型不歧视(种族/性别/年龄)
3. 模型调试: 理解模型为什么犯错
4. 客户信任: 用户需要理解AI的决策逻辑
可解释性技术栈:
┌─────────────┬────────────────┬──────────────────┐
│ 层级 │ 技术 │ 金融应用场景 │
├─────────────┼────────────────┼──────────────────┤
│ 全局解释 │ SHAP Summary │ 模型整体行为报告 │
│ Global │ Feature Imp. │ 监管报告/审计 │
├─────────────┼────────────────┼──────────────────┤
│ 局部解释 │ SHAP Values │ 个案拒贷原因 │
│ Local │ LIME │ 欺诈告警解释 │
├─────────────┼────────────────┼──────────────────┤
│ 反事实解释 │ Counterfactual │ "如果您收入多¥2万 │
│ Counter. │ Explanation │ 贷款就会批准" │
├─────────────┼────────────────┼──────────────────┤
│ LLM增强解释 │ LLM + SHAP │ 将特征重要性转化为 │
│ LLM-based │ 自然语言生成 │ 人类可读的解释文本 │
└─────────────┴────────────────┴──────────────────┘
LLM增强可解释性示例:
────────────────────
ML模型输出: 拒贷, score=0.32 (阈值0.6)
SHAP Top Features: debt_ratio=0.78(↓), income_stability=0.3(↓),
credit_history_length=2yr(↓)
LLM生成的客户解释:
"尊敬的客户，您的贷款申请未通过，主要原因如下：
1. 负债比过高(78%) — 建议将负债降低至50%以下
2. 收入稳定性不足 — 近12个月收入波动较大
3. 信用历史较短(2年) — 建议持续维护良好信用记录
改善以上因素后，欢迎再次申请。"
Web3 合规
链上监控 (On-Chain Compliance)
Web3合规的独特挑战:
───────────────────
传统金融: 身份 → 账户 → 交易 (强身份绑定)
Web3: 匿名地址 → 链上交易 (弱身份/假名)
核心矛盾: 去中心化理念 vs 监管合规要求
链上监控技术栈:
┌──────────────────────────────────────────────────┐
│ On-Chain Compliance Monitoring │
│ │
│ Layer 1: 地址标签 (Address Labeling) │
│ ├── 已知实体: 交易所/DeFi协议/桥/混币器 │
│ ├── 风险标签: 制裁地址/黑客地址/欺诈地址 │
│ ├── 聚类分析: 关联地址归属同一实体 │
│ └── 来源: Chainalysis / Elliptic / TRM Labs │
│ │
│ Layer 2: 交易图谱 (Transaction Graph) │
│ ├── 资金溯源(Source of Funds): 资金从哪里来 │
│ ├── 资金去向(Destination): 资金流向哪里 │
│ ├── 跳数分析(Hops): 经过几次转手到达制裁地址 │
│ └── 混淆检测: Tornado Cash/混币器使用检测 │
│ │
│ Layer 3: 风险评分 (Risk Scoring) │
│ ├── 地址风险分: 0-100 (基于关联/行为/标签) │
│ ├── 交易风险分: 单笔交易的合规风险 │
│ └── 实体风险分: 聚合同一实体所有地址 │
│ │
│ Layer 4: 合规动作 (Compliance Actions) │
│ ├── 允许(Allow): 低风险交易放行 │
│ ├── 增强审查(EDD): 中风险需要额外验证 │
│ ├── 冻结(Freeze): 高风险地址资产冻结(USDC可做到) │
│ └── 报告(Report): 向监管机构提交SAR │
└──────────────────────────────────────────────────┘
Travel Rule (FATF Recommendation 16)
Travel Rule — 加密资产版"旅行规则":
─────────────────────────────────────
要求: 虚拟资产服务提供商(VASP)在转账时，
必须传递发送方和接收方的身份信息
┌──────────────────────────────────────────────┐
│ Alice (交易所A) ──→ Bob (交易所B) │
│ │
│ 交易所A必须向交易所B传递: │
│ ├── 发送方: 姓名/账号/地址 │
│ └── 接收方: 姓名/账号 │
│ │
│ 阈值: FATF建议$1,000+, 各国不同 │
│ ├── 美国: $3,000 │
│ ├── 欧洲(MiCA): €1,000 (hosted→unhosted: €0)│
│ ├── 新加坡: SGD 1,500 │
│ └── 日本: 所有交易(无阈值) │
└──────────────────────────────────────────────┘
技术实现方案:
├── TRISA (Travel Rule Information Sharing Alliance)
├── Notabene: 最主流的Travel Rule协议
├── Sygna (CoolBitX): 亚太地区
└── OpenVASP: 去中心化方案
DeFi困境:
• DeFi协议没有KYC → 无法执行Travel Rule
• 解决思路: DeFi前端合规 vs 协议层合规 (争议中)
• 2025-2026趋势: "合规DeFi"赛道兴起
MiCA (Markets in Crypto-Assets Regulation)
MiCA — 欧盟加密资产市场法规:
───────────────────────────────
生效: 2024年6月(部分), 2024年12月(全面)
意义: 全球首个全面的加密资产监管框架
核心框架:
┌──────────────────────────────────────────────────┐
│ MiCA 监管框架 │
│ │
│ 资产分类: │
│ ├── EMT (E-Money Token): 电子货币代币 │
│ │ 例: USDC, EURC → 按电子货币法规监管 │
│ ├── ART (Asset-Referenced Token): 资产参考代币 │
│ │ 例: 锚定多种资产的稳定币 → 严格监管 │
│ └── 其他加密资产: BTC, ETH等 │
│ → 白皮书要求/信息披露/市场操纵禁止 │
│ │
│ CASP (Crypto-Asset Service Provider) 要求: │
│ ├── 授权/注册: 需获得成员国NCA授权 │
│ ├── 资本要求: 最低资本金€50K-€150K │
│ ├── 治理: 管理层适当性/利益冲突/外包管理 │
│ ├── 客户保护: 资产隔离/信息披露/投诉处理 │
│ └── AML/CFT: 遵守反洗钱指令(AMLD) │
│ │
│ AI/RegTech机遇: │
│ ├── 自动化白皮书合规检查 │
│ ├── 稳定币储备实时审计 │
│ ├── 跨境合规状态自动匹配 │
│ └── 市场操纵AI检测(wash trading/layering) │
└──────────────────────────────────────────────────┘
DeFi合规挑战
DeFi合规的根本矛盾:
──────────────────────
去中心化 ←────────────────→ 合规
无许可(Permissionless) KYC/AML
匿名性(Pseudonymity) 身份验证
不可审查(Censorship Resistant) 制裁执行
代码即法律(Code is Law) 法律即法律
2025-2026 DeFi合规趋势:
┌──────────────────────────────────────────────┐
│ 趋势1: 前端合规 (Frontend Compliance) │
│ 协议层无许可，但前端网站做KYC/地理围栏 │
│ 例: Uniswap前端屏蔽制裁地址 │
│ 问题: 用户可直接调用合约绕过 │
│ │
│ 趋势2: 合规DeFi (Compliant DeFi) │
│ 在协议层嵌入合规逻辑 │
│ 例: Aave Arc(机构版)/Maple Finance │
│ 方式: 白名单地址/合规预言机/链上身份 │
│ │
│ 趋势3: 链上身份 (On-Chain Identity) │
│ 零知识证明验证身份，不暴露隐私 │
│ 例: Polygon ID/Worldcoin/zkPass │
│ 方式: 证明"我是合规用户"而不透露"我是谁" │
│ │
│ 趋势4: 监管科技基础设施 │
│ 为DeFi协议提供合规中间件 │
│ 例: Chainalysis Oracle / TRM Screening API │
│ 方式: 合约调用API检查地址风险 │
└──────────────────────────────────────────────┘
2025-2026 RegTech 公司全景
核心玩家对比
┌─────────────────┬──────────────┬──────────────┬───────────────┐
│ 公司 │ 核心领域 │ 技术亮点 │ 客户群体 │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ Chainalysis │ 链上分析 │ 地址聚类/ │ 政府/交易所/ │
│ (估值$8.6B) │ Web3合规 │ 交易图谱 │ 银行 │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ Elliptic │ 链上合规 │ 跨链追踪/ │ 交易所/支付/ │
│ │ 风险评分 │ DeFi监控 │ 金融机构 │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ ComplyAdvantage │ AML/制裁筛查 │ AI实时风险 │ 银行/金融科技/ │
│ │ 负面新闻 │ 数据库 │ 加密 │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ Sumsub │ KYC/身份验证 │ 全栈验证/ │ 金融科技/ │
│ │ 全球覆盖 │ Deepfake检测 │ 加密/游戏 │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ Notabene │ Travel Rule │ VASP间消息 │ 交易所/ │
│ │ 合规 │ 协议 │ 合规部门 │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ TRM Labs │ 链上情报 │ 多链分析/ │ 政府/交易所/ │
│ │ 调查工具 │ 欺诈检测 │ DeFi │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ Hummingbird │ AML案件管理 │ 工作流自动化/ │ 银行/信用社/ │
│ │ SAR报告 │ AI辅助调查 │ 金融科技 │
└─────────────────┴──────────────┴──────────────┴───────────────┘
Chainalysis 深度剖析
Chainalysis — 链上合规领域绝对领导者
──────────────────────────────────────
成立: 2014年 | 总部: 纽约 | 估值: $8.6B (2023)
客户: 100+ 政府机构 / 几乎所有主流交易所
产品矩阵:
┌──────────────┬──────────────────────────────────┐
│ 产品 │ 功能 │
├──────────────┼──────────────────────────────────┤
│ Reactor │ 交易调查/可视化/资金追踪 │
│ KYT │ 实时交易监控(Know Your Transaction)│
│ Kryptos │ 自动化合规报告 │
│ Address │ 地址筛查/制裁检查 │
│ Screening │ │
│ Market Intel │ 市场情报/趋势分析 │
└──────────────┴──────────────────────────────────┘
核心技术:
├── 地址聚类: 将数百万地址归属到已知实体
│ 方法: 共同输入启发式 / 行为分析 / OSINT
├── 暴露度评分: 地址与高风险实体的直接/间接关联度
├── 跨链追踪: 追踪资金通过桥/DEX的跨链流动
└── AI增强(2025-2026):
├── LLM辅助调查报告生成
├── 异常模式自动发现
└── 预测性合规(预测洗钱路径)
ComplyAdvantage — AI驱动的AML
ComplyAdvantage — 用AI重新定义AML筛查
────────────────────────────────────────
核心差异化: 实时AI数据库 vs 传统静态名单
传统方案: ComplyAdvantage:
├── 静态制裁名单 ├── AI实时扫描全球媒体
├── 周/月更新 ├── 分钟级更新
├── 姓名精确匹配 ├── NLP语义匹配
└── 误报率30-40% └── 误报率降低70%
AI技术栈:
├── NLP: 多语言新闻/社交媒体实时分析
│ → 发现负面新闻/制裁预警/PEP关联
├── 实体解析(Entity Resolution):
│ → 将"张三"/"Zhang San"/"Mr. Zhang"识别为同一人
├── 网络分析(Network Analysis):
│ → 发现隐性关联(共同董事/关联公司)
└── 风险评分(Risk Scoring):
→ 动态评分，随新信息实时更新
Sumsub — 全栈KYC/身份验证
Sumsub — 一站式身份验证平台
──────────────────────────────
覆盖: 220+国家/地区, 14,000+文档类型
验证流程:
┌──────────────────────────────────────────┐
│ 用户上传证件照片 │
│ │ │
│ ▼ │
│ AI文档验证 (2-3秒) │
│ ├── 文档类型识别 │
│ ├── OCR信息提取 │
│ ├── 防伪特征检测(水印/MRZ/NFC) │
│ └── Deepfake/篡改检测 │
│ │ │
│ ▼ │
│ 活体检测 (Liveness Check) │
│ ├── 3D深度检测(防照片攻击) │
│ ├── 动作指令(眨眼/转头) │
│ └── 证件-人脸比对(>99.5%准确率) │
│ │ │
│ ▼ │
│ 数据库交叉验证 │
│ ├── 制裁名单/PEP/负面新闻 │
│ ├── 政府数据库(可用时) │
│ └── 设备/IP/行为分析 │
│ │ │
│ ▼ │
│ 结果: 通过 / 拒绝 / 人工审核 │
│ 平均耗时: 30秒(自动) / 5分钟(人工) │
└──────────────────────────────────────────┘
2025-2026亮点:
├── AI生成假证件检测(GenAI Fraud Prevention)
├── 可重用KYC(用户一次验证，多处复用)
└── Web3集成: 钱包连接 + 链上身份绑定
今日思考
思考1: 合规科技的终局是什么？
短期 (2025-2027): AI辅助人工
• AI处理80%的标准审查，人类处理20%的复杂案件
• LLM生成报告草稿，人工审核修改
• 合规人员从"审查员"变成"AI监督者"
中期 (2027-2030): 合规即代码 (Compliance as Code)
• 监管要求编码为可执行规则
• 实时合规验证(类似CI/CD中的自动测试)
• 监管沙盒 + 实时监控取代定期检查
长期 (2030+): 可编程监管 (Programmable Regulation)
• 监管机构直接发布机器可读规则
• 金融机构系统自动适配新规
• 链上合规: 智能合约内嵌合规逻辑
关键问题:
"合规自动化"会不会导致"合规军备竞赛"？
犯罪分子也在用AI绕过检测 → AI vs AI的对抗
思考2: Web3合规的产品机会在哪里？
未被充分满足的需求:
┌──────────────────────────────────────────────────┐
│ 1. DeFi协议的"合规中间件" │
│ 问题: DeFi协议想合规但没有工具 │
│ 机会: 提供可嵌入智能合约的合规SDK │
│ 示例: address.isCompliant() → true/false │
│ │
│ 2. 零知识合规证明 (ZK Compliance) │
│ 问题: KYC暴露隐私 vs 合规需要身份 │
│ 机会: 用ZK证明"我通过了KYC"而不透露个人信息 │
│ 项目: zkPass / Polygon ID / Sismo │
│ │
│ 3. 跨链合规聚合 │
│ 问题: 100+条链，合规数据分散 │
│ 机会: 统一的跨链合规视图和风险评分 │
│ │
│ 4. DAO合规工具 │
│ 问题: DAO法律地位不清，合规无从下手 │
│ 机会: DAO注册/税务/合规的全栈SaaS │
│ │
│ 5. AI Agent合规 │
│ 问题: AI Agent代理用户进行金融操作，谁负责合规？ │
│ 机会: AI Agent合规框架和监控工具 │
└──────────────────────────────────────────────────┘
思考3: PM视角 — 合规产品的设计原则
合规产品的独特挑战:
┌──────────────────────────────────────────┐
│ 1. 用户体验 vs 合规强度 │
│ KYC步骤越多 → 转化率越低 │
│ KYC步骤越少 → 合规风险越高 │
│ → PM需要找到"最小合规摩擦"的平衡点 │
│ │
│ 2. 全球化 vs 本地化 │
│ 每个国家法规不同 │
│ → 需要模块化合规引擎(规则可配置) │
│ │
│ 3. 准确性 vs 速度 │
│ 用户等不了5分钟的KYC │
│ 但漏放一个制裁对象后果极严重 │
│ → 分层策略: 快速通过低风险，深度审查高风险│
│ │
│ 4. 透明度 vs 安全性 │
│ 告诉用户"为什么被拒"可能暴露检测规则 │
│ → 提供适度解释但不暴露核心逻辑 │
└──────────────────────────────────────────┘
设计原则:
• 合规无感化: 尽可能在后台完成，减少用户摩擦
• 风险分层: 不同风险等级，不同审查力度
• 持续验证: 从"入网一次验证"到"持续风险评估"
• 模块可配: 合规规则引擎化，适应多法域
• 审计友好: 所有决策可追溯，所有日志可查
面试题
Q1: 如何设计一个AI驱动的KYC系统？需要考虑哪些因素？
回答框架:
1. 系统架构:
├── 身份验证层: OCR + 活体检测 + 防伪
├── 数据验证层: 制裁名单 + PEP + 负面新闻
├── 风险评估层: ML模型 + 规则引擎
└── 持续监控层: 行为分析 + 定期复审
2. 关键设计考量:
├── 准确率 vs 用户体验: 风险分层，低风险快速通过
├── 全球化: 220+国家，14,000+证件类型
├── Deepfake防护: AI生成假证件/假人脸成为新威胁
├── 隐私合规: GDPR/CCPA对生物特征数据的严格要求
└── 可解释性: 拒绝原因需向用户和监管说明
3. 指标:
├── 自动通过率(Auto-Approval Rate): 目标>80%
├── 平均验证时间: 目标<60秒
├── 误报率(False Positive): 制裁筛查<5%
└── 漏报率(False Negative): 必须接近0%
Q2: EU AI Act对金融机构的AI系统有什么影响？如何应对？
回答框架:
1. 直接影响:
├── 信贷评分/保险定价AI被归为"高风险"
├── 需要全面的风险管理/文档/监控
├── 人类监督(Human-in-the-loop)成为硬性要求
└── 违规罚款高达全球营收7%
2. 应对策略:
├── 模型清单(Model Inventory): 盘点所有AI系统
├── 风险分级: 按EU AI Act框架分类
├── 治理流程: 建立AI模型全生命周期治理
├── 可解释性: 每个高风险模型都要能解释决策
└── 持续合规: 定期审计 + 性能监控
3. PM视角:
├── 合规 ≠ 障碍，是产品差异化的机会
├── "可信AI"成为金融产品的卖点
└── 提前合规 = 市场准入优势
Q3: 如何在DeFi协议中实现合规，同时保持去中心化？
回答框架:
1. 核心矛盾: 去中心化 vs 合规(身份/审查)
2. 三种路径:
├── 前端合规: 协议层不变，前端做KYC/地理围栏
│ 优点: 最小改动 缺点: 可绕过
├── 协议层合规: 智能合约内嵌合规逻辑
│ 优点: 不可绕过 缺点: 牺牲无许可性
└── ZK合规: 零知识证明验证身份，不暴露隐私
优点: 兼顾隐私 缺点: 技术不成熟
3. 我的观点:
"分层合规"是最务实的方案:
├── 散户小额: 宽松(仅地址筛查)
├── 大额/机构: 严格(完整KYC + Travel Rule)
└── 底层协议: 提供合规接口(opt-in)，不强制
学习资源
推荐阅读
监管框架:
- FATF: "Updated Guidance for a Risk-Based Approach to Virtual Assets" (2021)
- EU AI Act 全文: https://artificialintelligenceact.eu/
- OCC/Fed SR 11-7: Model Risk Management Guidance
行业报告:
- Chainalysis: "2026 Crypto Crime Report"
- Elliptic: "State of Cross-Chain Crime"
- ComplyAdvantage: "The State of Financial Crime"
技术文章:
- "Building AI-Powered AML Systems" — Towards Data Science
- "Zero Knowledge Proofs for Compliance" — a16z crypto
- "The RegTech Landscape 2026" — CB Insights
推荐工具体验
链上合规:
- Chainalysis Reactor (demo): 交易追踪可视化
- Elliptic Lens: 钱包风险检查(有免费版)
- TRM Labs: 链上风险评估
KYC/身份:
- Sumsub (开发者沙盒): 体验AI身份验证流程
- Polygon ID: Web3原生身份验证
合规知识:
- FinCEN SAR filing guide: 了解STR格式
- MiCA法规原文: 理解欧洲加密监管
明日预告
Day 34: 金融AI(4)：信贷全链路AI
├── 信贷全链路(获客→审批→定价→贷后→催收)
├── AI评分卡 vs 传统评分卡(逻辑回归→XGBoost→LLM)
├── 联邦学习在信贷中的应用(数据不出域)
├── LLM在信贷中的场景(智能客服/文档审核/催收话术)
└── 案例: 蚂蚁花呗/微粒贷/Upstart
学习进度
Phase 1: 模型基础 Day 1-15 ████████████████ 100% ✅
Phase 2: 工程实践 Day 16-30 ████████████████ 100% ✅
Phase 3: 金融零售AI Day 31-42 ████░░░░░░░░░░░░ 25% 🔄
Phase 4: 面试冲刺 Day 43-50 ░░░░░░░░░░░░░░░░ 0%
当前进度: Day 33/50 (66% overall)
今日状态: 合规科技与监管AI — 从成本中心到效率引擎 ✅
今日金句 (Quote of the Day)
"Compliance is not about saying no — it's about finding intelligent ways to say yes."
"合规不是为了说'不' — 而是为了找到更聪明的方式说'是'。"