反洗钱(AML)审查是金融机构里最让人头疼的重复劳动之一。一笔可疑交易触发警报后,合规分析师要翻客户历史、比对交易模式、查关联账户、写调查报告——一个警报从打开到关闭,30 到 90 分钟是常态。警报量大、人力有限,积压成了日常。
Amazon Q Business 的 Flows 功能和 Snowflake Cortex AI 的组合,通过 MCP(Model Context Protocol)打通了工作流引擎与数据智能,让这套流程可以自动化跑起来。测试环境里的结果:单个警报排查时间从 30–90 分钟降到 5 分钟以内。实际效果取决于警报复杂度和数据量,但方向已经很明确——把分析师从机械查数据里解放出来,专注做判断。
痛点在哪:AML 排查的"体力活"
一个典型 AML 警报的处理流程大致是:
- 读取警报详情——交易金额、方向、涉及账户。
- 拉取客户画像——KYC 信息、历史交易汇总、风险评分。
- 关联分析——同一客户的其他警报、关联人/关联账户的活动。
- 形成结论——判定是误报还是需要升级,写一段摘要。
步骤 2 和 3 占了绝大部分时间,本质上是"查数据 + 拼上下文"的体力活。分析师在多个系统间切换、手动跑 SQL、复制粘贴——这些步骤规则明确、重复度高,正是自动化最该切入的地方。
架构:Amazon Q Flows + Snowflake Cortex + MCP
整体架构分三层:
- Snowflake Cortex——驻留在数据仓库侧的 AI 推理层。它直接在 Snowflake 内跑 LLM,不需要把敏感数据搬出仓库。Cortex 可以做自然语言查询(
COMPLETE函数)、语义检索、摘要生成。 - Amazon Q Flows——Amazon Q Business 里的工作流编排引擎。你定义步骤、条件分支、输入输出映射,Q Flows 按顺序执行,每一步可以调用不同的工具。
- MCP 连接器——Amazon Q 通过 MCP Server 与 Snowflake Cortex 对接。MCP 是 Anthropic 提出的开放协议,统一了"AI Agent 调用外部工具"的接口规范。Amazon Q 作为 MCP Client,Snowflake 侧暴露 MCP Server,数据不出 Snowflake 边界。
流程跑起来时,Amazon Q Flows 依次调用 MCP 工具:先查客户信息,再查关联交易,最后让 Cortex 生成调查摘要。分析师只需要审阅最终输出,做人为判断。
实操:搭建一个 AML 排查 Flow
下面用一个最小可跑的示例展示关键配置。假设你已经有 Snowflake 账户和 Amazon Q Business 环境。
第一步:Snowflake 侧准备 Cortex 函数和 MCP Server
在 Snowflake 里创建一个存储过程,封装 Cortex COMPLETE 调用,用于根据客户 ID 生成风险摘要:
-- 在 Snowflake SQL Worksheet 中执行
CREATE OR REPLACE PROCEDURE aml_risk_summary(customer_id STRING)
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
customer_info STRING;
summary_result STRING;
BEGIN
-- 先拼接客户上下文:KYC + 近 90 天交易汇总
SELECT
OBJECT_CONSTRUCT(
'name', c.full_name,
'risk_score', c.risk_score,
'total_txn_90d', COUNT(t.transaction_id),
'total_amount_90d', SUM(t.amount)
)::STRING
INTO customer_info
FROM customers c
LEFT JOIN transactions t
ON c.customer_id = t.customer_id
AND t.transaction_date >= DATEADD(day, -90, CURRENT_DATE())
WHERE c.customer_id = :customer_id
GROUP BY c.customer_id, c.full_name, c.risk_score;
-- 调用 Cortex COMPLETE 生成摘要
SELECT SNOWFLAKE.CORTEX.COMPLETE(
'snowflake-arctic',
CONCAT(
'You are an AML analyst. Based on the following customer data, ',
'write a concise risk assessment summary in 3-5 sentences. ',
'Highlight any red flags.\n\nCustomer data: ', customer_info
)
)::STRING
INTO summary_result;
RETURN summary_result;
END;
$$;
然后配置 Snowflake MCP Server,让 Amazon Q 能远程调用这个存储过程。Snowflake 的 MCP Server 配置(简化版 YAML):
# snowflake_mcp_server_config.yaml
server:
name: aml-triage-tools
version: "1.0"
tools:
- name: get_customer_risk_summary
description: >
Given a customer_id, returns an AI-generated AML risk assessment
summary based on KYC data and recent transaction history.
inputSchema:
type: object
properties:
customer_id:
type: string
description: "The customer identifier from the AML alert"
required:
- customer_id
handler:
type: snowflake-procedure
procedure: aml_risk_summary
database: AML_DB
schema: ANALYTICS
- name: search_related_alerts
description: >
Search for other AML alerts involving the same customer or
related accounts in the past 12 months.
inputSchema:
type: object
properties:
customer_id:
type: string
lookback_months:
type: integer
default: 12
required:
- customer_id
handler:
type: snowflake-procedure
procedure: search_related_alerts
database: AML_DB
schema: ANALYTICS
说明:MCP Server 的实际部署方式随 Snowflake 版本演进可能有变化,以上 YAML 是结构示意,具体字段请参考 Snowflake Cortex AI MCP 文档。核心要点是:每个
tool对应一个 Snowflake 存储过程或 Cortex 函数,inputSchema用 JSON Schema 描述入参,Amazon Q 通过 MCP 协议发现并调用这些工具。
第二步:在 Amazon Q Business 中定义 Flow
Amazon Q Flows 通过自然语言描述 + UI 配置来编排步骤。以下用 JSON 表示 Flow 的逻辑结构(对应你在 Q Business 控制台里的配置):
{
"flow_name": "aml-alert-triage",
"description": "Automated AML alert triage: gather context, analyze risk, produce summary",
"trigger": {
"type": "api",
"input": {
"alert_id": "string",
"customer_id": "string",
"alert_reason": "string"
}
},
"steps": [
{
"id": "fetch_risk_summary",
"tool": "get_customer_risk_summary",
"input_mapping": {
"customer_id": "{{trigger.customer_id}}"
}
},
{
"id": "fetch_related_alerts",
"tool": "search_related_alerts",
"input_mapping": {
"customer_id": "{{trigger.customer_id}}"
}
},
{
"id": "generate_triage_report",
"type": "llm",
"model": "amazon-q-business",
"prompt_template": [
"You are an AML compliance analyst reviewing an alert.",
"Alert reason: {{trigger.alert_reason}}",
"Customer risk summary: {{fetch_risk_summary.output}}",
"Related past alerts: {{fetch_related_alerts.output}}",
"",
"Based on the above, produce a triage recommendation:",
"- Is this alert likely a false positive or requires escalation?",
"- List the key red flags (if any).",
"- Suggest next steps for the human analyst.",
"Keep the output under 300 words."
]
}
],
"output": {
"triage_report": "{{generate_triage_report.output}}"
}
}
这个 Flow 的执行顺序是线性的:先查风险摘要,再查关联警报,最后让 LLM 汇总判断。每一步的输出通过 {{step_id.output}} 传递给下一步,类似管道拼接。
第三步:调用 Flow
触发 Flow 的方式可以是 API 调用、事件驱动,或在 Q Business 聊天界面里直接输入。API 方式示例(Python):
import boto3
import json
q_business = boto3.client("qbusiness", region_name="us-east-1")
# 假设你的 Q Business application ID 和 Flow ID 已配置好
APP_ID = "your-q-business-app-id"
FLOW_ID = "aml-alert-triage"
def triage_alert(alert_id: str, customer_id: str, alert_reason: str) -> str:
response = q_business.execute_flow(
applicationId=APP_ID,
flowId=FLOW_ID,
input={
"alert_id": alert_id,
"customer_id": customer_id,
"alert_reason": alert_reason,
}
)
return response["output"]["triage_report"]
# 实际调用
report = triage_alert(
alert_id="ALM-20250618-0042",
customer_id="CUST-88321",
alert_reason="Large wire transfer to high-risk jurisdiction followed by rapid fund dispersal"
)
print(report)
注意:
execute_flow是示意性 API 名称。Amazon Q Business Flows 的实际 SDK 方法名和参数结构请参考最新 AWS 文档。上面的代码展示了调用模式——传入警报三要素,拿到自动生成的排查报告。
效果与边界
测试环境的数据:排查时间从 30–90 分钟降到 5 分钟以内。这个数字很亮眼,但有几个现实约束需要正视:
- 警报复杂度差异大——简单误报(比如一次性大额转账,客户历史干净)5 分钟够了;涉及多层嵌套实体、跨司法管辖区关联的复杂警报,自动化能加速数据收集,但人为判断仍不可省略。
- 数据质量是前提——Cortex 的摘要质量取决于输入数据是否完整。如果 KYC 字段缺失、交易标签不规范,AI 输出也会模糊。
- 合规审查不能跳过——自动化生成的是"初筛报告",不是最终决定。监管要求人为签字确认,Flow 输出应该定位为"分析师的辅助材料"而非"自动决策"。
- 幻觉风险——LLM 可能编造不存在的关联。关键事实(金额、日期、账户号)应该从结构化查询结果直接注入 prompt,而不是让 LLM 自行"回忆"。
上手建议
如果你打算在组织内试跑这套方案,可以按这个顺序推进:
- 选一个低风险警报类型做试点——比如"单次大额现金存款"这类规则明确、误报率高的场景,先验证 Flow 输出质量。
- 先跑 Shadow Mode——让 Flow 对历史警报跑一遍,分析师对照自己之前的结论,统计一致率和偏差类型,再逐步放开。
- 数据侧先治理——确保 Snowflake 里的客户维度表和交易事实表字段齐全、更新及时。Cortex 再强,喂进去的数据有缺口,输出就不可靠。
- MCP 工具粒度要细——不要做一个"万能查询"工具,而是拆成
get_customer_profile、get_recent_transactions、search_related_alerts等独立工具,让 Flow 编排更灵活,也方便单独测试每个工具的返回质量。 - 设置人工兜底——在 Flow 最后一步加一个条件分支:如果 LLM 判断为"需要升级",自动创建 Case 并通知资深分析师;如果判断为"误报",仍然要求分析师一键确认后才能关闭。
AML 排查自动化不是要取代分析师,而是把 80% 的查数据时间砍掉,让人专注在剩下 20% 的判断上。Amazon Q Flows 提供编排,Snowflake Cortex 提供数据侧推理,MCP 把两者缝在一起——这条路径已经可以落地了。