upadhyayanurodh/ai-upi-fraud-intelligence-agent

# ai-upi-欺诈-智能-Agent [](http://upi-fraud-dashboard-339163283135.s3-website.ap-south-1.amazonaws.com)        ## 问题 UPI 每月在印度处理超过 160 亿笔交易。欺诈模式——如信用卡测试、账户接管、骡子账户和地理位置异常——会随着时间推移在 VPA 层面的多笔交易中显现。孤立地看，没有任何单笔交易显得具有欺诈性。欺诈运营团队需要同时识别数百个 VPA 中的模式，用通俗易懂的语言理解风险，并优先处理置信度最高的信号。 ## 解决方案 一款 AI agent，可实时监控 UPI 交易流，并在异常行为超过检测阈值时立即发出欺诈警报： 1. **规则引擎** —— 将四种确定性模式应用于每个 VPA 的 30 分钟滑动窗口：信用卡测试、不可能的地理位置、高频交易和骡子模式 2. **AI 解释** —— 标记的交易将被发送至 Amazon Nova Micro (Bedrock)，生成 3 句话的通俗风险评估 3. **实时仪表板** —— 托管在 S3 上的界面，每 5 秒轮询一次，具备严重性过滤、模式分布、状态热力条和累犯跟踪功能 4. **零凭证访问** —— 任何拥有 URL 的人都能看到实时警报；浏览器中无需登录，无需 API key ## India DPI Intelligence Suite 的一部分 这是 **3 个 Agent 中的第 1 个** —— 这是一套构建在 India 数字公共基础设施轨道上的生产级 AI agent 套件，每个 agent 位于不同的云提供商上。 | Agent | DPI 轨道 | 云服务 | 状态 | |---|---|---|---| | **Agent 1 — UPI 欺诈情报** | UPI (NPCI) | AWS | ✅ 完成 | | Agent 2 — ONDC 网络情报 | ONDC (Beckn) | GCP | 🔄 进行中 | | Agent 3 — OCEN 信贷情报 | OCEN + Account Aggregator | Azure | 🔄 进行中 | ## 架构 ``` flowchart TD SIM["🖥️ Python Simulator\ntransaction_simulator.py\n(local — not deployed)"] -->|"~2–5 cycles/s\n(bursts on fraud)\nSQS SendMessage"| SQS subgraph AWS["AWS — ap-south-1 (Mumbai)"] SQS["AWS SQS\nupi-transaction-queue\nbatch size 10"] SQS -->|"SQS trigger\nbatch 10 messages"| PROC subgraph PROC_SUB["Lambda: upi-fraud-processor"] PROC["1. store_transaction()\n2. get_vpa_history() — 30-min window\n3. run_rules() — 4 patterns\n4. If fraud: explain + alert + notify"] end PROC -->|"write"| TXN["DynamoDB\nupi_transactions\nPK: vpa · SK: ts_txn_id\nTTL 24h"] PROC -->|"query"| TXN PROC -->|"Converse API\nNova Micro"| BDR["Amazon Bedrock\napac.amazon.nova-micro-v1:0"] BDR -->|"3-sentence\nrisk assessment"| PROC PROC -->|"write alert"| ALERTS["DynamoDB\nupi_alerts\nPK: alert_id · SK: timestamp\nTTL 72h"] PROC -->|"publish"| SNS["Amazon SNS\nupi-fraud-alerts"] ALERTS -->|"scan\nConsistentRead=True\nLimit=500"| API subgraph API_SUB["Lambda: upi-alerts-api"] API["get_recent_alerts()\ncompute_stats()\nreturn JSON"] end API -->|"GET /default/upi-alerts-api"| GW["API Gateway\nHTTP API — zynwu9f1j4\nCORS: * · auto-deploy"] GW -->|"HTTPS response"| S3WEB S3WEB["S3 Static Website\nupi-fraud-dashboard\nindex.html — polls every 5s"] end S3WEB -->|"HTTP"| BROWSER["🌐 Browser\nAlert feed · Pattern donut\nState heatbar · Repeat offenders"] ``` 有关完整的组件分解、基础设施表和构建/运行时流程，请参阅 [ARCHITECTURE.md](./ARCHITECTURE.md)。 ## 在线演示 **[http://upi-fraud-dashboard-339163283135.s3-website.ap-south-1.amazonaws.com](http://upi-fraud-dashboard-339163283135.s3-website.ap-south-1.amazonaws.com)** 托管在 AWS S3 静态网站 (ap-south-1) 上。无需登录。警报每 5 秒自动更新一次。 ### 自己尝试 在本地运行模拟器以生成实时合成交易流： ``` python3 src/simulator/transaction_simulator.py --tps 2 --fraud-rate 0.15 ``` 在浏览器中打开仪表板 URL。在 10-15 秒内，欺诈警报就会出现——按严重性排序，并附带 AI 生成的风险解释和置信度分数。使用 **All / High / Medium** 过滤按钮进行分类处理。 ## 技术栈 | 层级 | 技术 | |---|---| | AI 模型 | Amazon Bedrock — Nova Micro (`apac.amazon.nova-micro-v1:0`, Converse API) | | 数据接入 | AWS SQS — `upi-transaction-queue`, 批大小 10 | | 处理 | AWS Lambda — `upi-fraud-processor`, Python 3.12, 由 SQS 触发 | | 交易状态 | Amazon DynamoDB — `upi_transactions`, 每个 VPA 的历史记录, 24小时 TTL | | 警报存储 | Amazon DynamoDB — `upi_alerts`, 欺诈警报 + AI 解释, 72小时 TTL | | 通知 | Amazon SNS — `upi-fraud-alerts` | | 仪表板 API | AWS Lambda + API Gateway HTTP API — `upi-alerts-api` | | 仪表板托管 | Amazon S3 — 静态网站, 公开读取, ap-south-1 | | 模拟器 | Python 3.12 — 合成 UPI 流, 4 个欺诈模式注入器 | | 区域 | ap-south-1 (孟买) | ## 开发工具 使用 [Claude Code](https://claude.ai/code) (Anthropic) 构建，用于提供智能体开发辅助。 ## 功能特性 - **四种欺诈模式** — CARD_TESTING, GEO_SPREAD, HIGH_VELOCITY, MULE_PATTERN，结合基于规则的检测和置信度评分（其中三种在 v1.0.0 版本中处于激活状态；`MULE_PATTERN` 是一个已知的限制 — 参见 [已知限制](#known-limitations--production-notes)) - **30 分钟行为窗口** — 从 DynamoDB 查询每个 VPA 的历史记录以进行模式检测；孤立地看没有任何单笔交易显得具有欺诈性 - **AI 风险解释** — 被标记的警报将发送至 Amazon Nova Micro (Bedrock Converse API) 生成 3 句话的通俗评估；如果 Nova 的内容过滤器阻止了响应或 Bedrock 不可用，警报仍会与其规则信号一起显示（参见 [已知限制](#known-limitations--production-notes)） - **实时仪表板** — 托管在 S3 上，每 5 秒轮询一次 API，浏览器零凭证访问 - **严重性过滤** — All / High / Medium 过滤按钮；警报按严重性然后按时间戳排序 - **模式分布图** — 显示 CARD_TESTING vs GEO_SPREAD vs HIGH_VELOCITY vs MULE_PATTERN 分解的甜甜圈图 - **状态热力条** — 按警报量排名的受影响最严重的印度各邦 - **累犯跟踪** — 多次触发警报的 VPA 显示在侧边栏中 - **在间歇性 API 响应下保持稳定的用户体验** — `lastStats` 缓存可防止指标在空响应时闪烁；`dataReceived` 标志在冷启动时显示 "Loading..." 而不是错误的 "No alerts" - **完全无服务器** — SQS + Lambda + DynamoDB + SNS + API Gateway + S3。空闲时缩减至零。 - **自动过期** — DynamoDB TTL 将在 24 小时后清除交易历史记录，并在 72 小时后清除警报；无需手动清理 - **可配置的模拟器** — `--tps` (模拟周期/秒) 和 `--fraud-rate` 标志；在每个欺诈周期中，四个注入器中的一个会随机触发。一个欺诈周期会发出*突发*交易（例如，信用卡测试发出 15-25 笔），因此实际吞吐量会飙升至高于 `--tps` 的值 ## 部署 本项目**部分托管在 AWS 上** — 所有 Lambda、DynamoDB、SNS、API Gateway 和 S3 资源均在 ap-south-1 运行。模拟器在本地运行并将交易推送到 SQS。 有关完整的分步构建和部署指南，请参阅 [SETUP.md](./SETUP.md)。 **你需要准备：** - 一个 AWS 账户（免费套餐可涵盖其中的大部分内容） - 配置好凭证的 AWS CLI **你将部署：** 1. AWS SQS 队列 + DynamoDB 表 + SNS 主题 + IAM 角色（通过 `src/setup/create_infra.py` 或 AWS 控制台） 2. `upi-fraud-processor` Lambda（由 SQS 触发的欺诈检测 + Bedrock） 3. `upi-alerts-api` Lambda + API Gateway HTTP API（仪表板数据 API） 4. 开启静态网站托管的 S3 存储桶 + 上传 `dashboard/index.html` **预估成本：** 对于轻度使用，完全在 AWS 免费套餐范围内 — 每天以几个周期/秒的频率运行几个小时的模拟器，可以轻松适配 SQS 免费套餐（100 万请求/月）。Bedrock 按付费 token 计费；Nova Micro 的警报解释每次仅需不到一卢比（约 ~₹0.001）。 ## 演示 ### 实时仪表板 — 警报已激活  ### 初始加载 — 正在连接 AWS  ## 关键决策与权衡 **选择 SQS 而不是 Kinesis** 最初的设计使用的是 Kinesis Data Streams。在构建窗口期间，由于账户无法激活 Kinesis，因此采用了 SQS。事实上，对于事件驱动的微服务，SQS → Lambda 是更常见的生产模式；唯一失去的功能是有序交付和多消费者重放 —— 这两者对于这个单消费者欺诈 pipeline 来说都不是必需的。 **带有专用访问模式的两个 DynamoDB 表** `upi_transactions` 使用复合键 — `vpa` (PK) + `timestamp#transaction_id` (SK) — 这样可以在单次查询中获取一个 VPA 在时间窗口内的所有交易。`upi_alerts` 使用 `alert_id` (PK)，因为警报只需写入一次，并通过全表扫描进行读取。两个表，两种读取模式，各自针对其工作负载进行了优化。 **规则引擎作为 LLM 的预过滤器** 每笔交易在触及 Bedrock 之前都会经过四个确定性规则的过滤。只有异常交易才会产生 AI 成本，这使得 LLM 的开销几乎为零，同时保留了可审计性 —— 每个警报都可以追溯到特定规则的触发。确定性、可追溯的检测是 RBI/PMLA 等欺诈报告机制所看重的属性，尽管此演示本身并不执行法规报告。 **30 分钟滑动窗口** 捕获信用卡测试突发和地理分布异常，同时忽略长期的合法行为。交易表上 24 小时的 TTL 保证了存储是有界的，且没有任何维护开销。 **选择 Amazon Nova Micro 而不是 Claude** 最初选择的模型是 Claude 3 Haiku。在 Claude 访问在 IAM 层面被阻止后，改用了 Nova Micro —— Bedrock 上的 Claude 需要 `aws-marketplace:Subscribe` 权限，该权限通过 AWS Marketplace 控制，与 Bedrock 模型访问页面是分开的。Converse API 与模型无关，因此这次切换只需更改一行模型 ID 并重新调整 prompt。可用的模型 ID：`apac.amazon.nova-micro-v1:0`（跨区域推理配置文件 — 在 ap-south-1 中必须带有 `apac.` 前缀）。 **完全无服务器托管** 仪表板 = S3 静态网站。API = Lambda + API Gateway。笔记本电脑上没有运行任何服务器进程。两者在空闲时都会缩减至零 —— 这是金融科技规模下轻量级运营仪表板的常见模式。 **AI 作为增强手段，而非检测手段** 规则负责检测；AI 负责解释。因为检测是基于规则的，每个警报都是确定且可追溯的 —— 这对于欺诈报告机制（如 RBI/PMLA）所要求的可审计性是非常有用的属性。AI 增加了一层叙述，可帮助人类分析师更快地进行分类处理 —— 采用 3 句话的风险评估比查看原始的置信度分数行动起来更快。 ## 经验教训 **1. Lambda handler 名称是独立于函数名称的配置字段** 部署 `upi-alerts-api` 后，每次调用都失败并提示 `Runtime.HandlerNotFound: Handler 'lambda_handler' missing on module 'lambda_function'`。Lambda 控制台默认 handler 为 `lambda_function.lambda_handler`，但实际函数命名为 `handler`。Handler 是一个控制台配置字段（Code → Runtime Settings → Edit）— 在文件中重命名该函数并不会更新它。请将其设置为 `lambda_function.handler`。 **2. boto3 默认的 60 秒超时会静默挂起，直到 Lambda 的执行上下文将其杀死** 修复 handler 后，Lambda 每次运行都超时。默认的 Lambda 超时时间为 3 秒，但 boto3 的默认连接超时为 60 秒 — 因此，缓慢的 DynamoDB 调用会静默挂起，直到 Lambda 强制触发 `Sandbox.Timedout`。修复：将 Lambda 超时提高到 30 秒，并设置显式的 boto3 超时 — `Config(connect_timeout=5, read_timeout=10, retries={"max_attempts": 1})`。 **3. DynamoDB 的 `Limit` 限制的是每次 API 调用返回的项目数，而不是返回的总项目数** 仪表板在有11 条警报时仅显示了 10 条，且没有任何错误。DynamoDB 的 `Limit` 参数限制的是每次 API 调用返回的项目数；当存在 `LastEvaluatedKey` 时，说明还有更多项目。对于全新的表，单次 `scan(Limit=500)` 就足够了；在规模较大时，需要基于 `LastEvaluatedKey` 进行分页，或者在 `timestamp` 上添加 GSI。 **4. 当 CORS 在 API 级别配置时，API Gateway HTTP API 会忽略 Lambda 的 CORS 标头** 即使 Lambda 返回了 `Access-Control-Allow-Origin: *`，仪表板仍显示 "Connection error — retrying…"。当在 HTTP API 上配置 CORS 时，API Gateway 会*忽略*后端的 CORS 标头并使用自己的。修复：在 API 本身上配置 CORS — `Access-Control-Allow-Origin: *`, `Access-Control-Allow-Headers: Content-Type`, `Access-Control-Allow-Methods: GET, OPTIONS`。 **5. Amazon Bedrock Nova Micro 的内容过滤器会静默触发 — 返回 200 OK 以及一个空的内容数组** 修复模型 ID 后，Nova 返回了 200 OK 以及空内容数组 — 没有错误，也没有异常。Prompt 中包含了 "fraud analyst" 和 "detect fraud"，这触发了 Nova 内容过滤器的敏感短语。将其重构为 "payment risk analyst reviewing a flagged UPI transaction" 和 "risk signals detected by automated monitoring" — 意图相同，框架不同 — 成功绕过了过滤器。 **6. 在区域 Bedrock endpoint 中，原生 Amazon 模型需要推理配置文件前缀** 第一次调用使用了直接模型 ID `amazon.nova-micro-v1:0` 并失败：“model not supported for on-demand throughput.”。在 ap-south-1 中，原生 Amazon 模型必须通过跨区域推理配置文件进行调用 — `apac.amazon.nova-micro-v1:0`。此要求仅出现在跨区域推理文档中，而未出现在 Bedrock 模型访问页面上。 **7. Bedrock 上的 Claude 需要 `aws-marketplace:Subscribe` — 与模型访问页面分开** 即使在提交了 Bedrock 用例表单并收到批准后，调用 Claude 仍返回 `AccessDeniedException`。Bedrock 上的 Claude 需要 `aws-marketplace:Subscribe` IAM 权限，该权限通过 AWS Marketplace 控制，与 Bedrock 模型访问页面完全分开 — 并且在控制台上没有相关文档记录。切换到不需要 Marketplace 权限的 Amazon Nova Micro 解决了这个问题。 **8. 冷启动 + 5 秒轮询 = 首次打开时显示 "No alerts yet" — 始终需要为首次获取进行设计** 新访问者在首次打开时看到 "No alerts yet"，因为第一次调用遇到了 Lambda 冷启动（约 1.1 秒），而此时 5 秒的轮询尚未触发。修复方案：一个 `dataReceived` 标志会渲染 "Loading… Connecting to AWS…" 直到收到第一个非空响应（带有 12 秒的安全超时），并在页面加载 2 秒后进行第二次 fetch 作为冷启动备份。 ## 已知限制与生产环境说明 本节记录了 v1.0.0 行为与理想生产系统之间的差距。该仓库完全反映了实时部署的情况，而不是预期的功能集。 **`MULE_PATTERN` 不会触发。** `get_vpa_history()` 根据分区键 `vpa`（即**付款方**）查询 `upi_transactions`，因此 VPA 的历史记录仅包含其*发送*的交易。骡子账户规则的流入条件需要 VPA 作为**收款方**（接收资金）的交易 — 这些交易存储在发送方的分区下，永远不会被返回，因此流入计数始终为 0，该规则永远不会触发。CARD_TESTING、GEO_SPREAD 和 HIGH_VELOCITY 工作正常（在仪表板的甜甜圈图中可见，该图从不显示 mule）。修复此问题需要面向收款方的访问路径 — 在 `payee_vpa` 上建立 GSI，或为每笔交易建立镜像的“已接收”记录。参见 [ARCHITECTURE.md](./ARCHITECTURE.md#fraud-patterns-detected)。 **模拟器的攻击集与检测器的规则不是 1:1 匹配的。** 模拟器注入 `card_testing`、`geo_spread`、`mule_account` 和 **`round_trip`**；引擎检测的是 CARD_TESTING、GEO_SPREAD、**HIGH_VELOCITY** 和 MULE_PATTERN。因此，`ROUND_TRIP` 被注入但**没有检测规则**（它永远不会被标记），而 `HIGH_VELOCITY` 被检测到但没有专用的注入器（它是偶然触发的，例如由于累积的活动）。再加上 mule 的缺陷，能够可靠地从注入 → 警报闭环的配对只有 **CARD_TESTING 和 GEO_SPREAD**。 **"AI explained" 指标统计了被阻止的响应。** `compute_stats` 将任何不以 `"[Bedrock"` 开头的解释标记为 AI 已解释 — 包括 Nova 内容过滤器阻止的消息。因此，即使有少量警报显示的是过滤器阻止消息而不是真实评估，仪表板的 "AI explained %" 也可能显示为 100%。 **"Total Alerts" 是最近的 60 条，而不是表中的总数。** API 返回 `get_recent_alerts(60)` 并计算该切片的统计信息，因此设计上 KPI 被限制为 60。在生产规模下，这将转移到在 `timestamp` 上使用 GSI 以实现真正的范围查询和准确的总数。 **生产环境加固（特意不在本演示的范围内）。** S3 网站仅支持 HTTP 并且全球可读（仅包含合成数据 — 前端使用 CloudFront 以支持 HTTPS），并且 Lambda IAM 策略授予了对 `Resource: "*"` 而不是特定模型 ARN 的 `bedrock:InvokeModel` 权限。这两者对于公开演示来说都是合理的，在生产环境中会进行收紧。 ## 状态 **活跃** — v1.0.0 已于 2026 年 6 月部署。实时地址 [http://upi-fraud-dashboard-339163283135.s3-website.ap-south-1.amazonaws.com](http://upi-fraud-dashboard-339163283135.s3-website.ap-south-1.amazonaws.com)。 ## 作者 **Anurodh Upadhyay** [LinkedIn](https://www.linkedin.com/in/anurodhupadhyay) · [GitHub](https://github.com/upadhyayanurodh) · upadhyayanurodh@gmail.com

标签：Amazon Bedrock, AWS Serverless, 云计算, 反欺诈检测, 实时监控看板, 规则引擎, 逆向工具, 金融风控