jamil3424-bit/banking-fraud-detection-dashboard

# 银行欺诈检测仪表板 **状态：** ✅ 已完成 ## 🎯 核心要点（快速回顾） - 构建了完全事件驱动的双 Lambda 架构：一个函数以确定性方式评估风险，第二个函数通过 DynamoDB Streams 自动响应并生成通俗易懂的解释 - 将“快速、低成本、确定性”的评分逻辑与“解释”层解耦——这是一种在生产系统中广泛使用的模式，用于分离关注点并控制成本 - 对两个 Lambda 角色应用了最小权限 IAM（仅限特定的表/存储桶/操作，没有使用通配符权限） - 将 AI 层设计为可替换的——目前使用模板逻辑，但采用了与 LLM API 调用完全相同的结构，从而避免在个人项目中产生不必要的经常性成本 - 全流程完成了 3 次端到端测试，无需任何手动触发——证实了这是真正的事件驱动行为，而不仅仅是孤立的函数测试 ## 架构 1. 提交交易 → **Lambda 1** (`fraudDetectionScorer`) 根据 4 个欺诈信号计算确定性的风险评分，并将结果写入 DynamoDB 2. DynamoDB Streams 在每次新写入时自动触发事件 3. **Lambda 2** (`fraudExplanationGenerator`) 自动触发，读取风险数据，生成通俗易懂的解释，并更新同一个 DynamoDB 项目 ## 使用的 AWS 服务 - **S3** — 原始交易数据存储 - **DynamoDB** — 启用了 Streams (NEW_IMAGE) 的标记交易存储 - **Lambda (x2)** — 解耦的评分 + 解释函数 - **IAM** — 两个自定义的最小权限角色（范围限定于确切的资源，而非通配符） - **CloudWatch** — 两个函数的日志记录 ## 技术栈 Python 3.12, boto3, AWS CLI, Git/GitHub ## 检测到的欺诈信号 - 收货地址最近被更改 - 来自新/未识别设备的购买 - 异常巨大的购买金额 - 多次失败的支付尝试 ## 备注 本项目中的解释层特意采用了模板逻辑构建，而没有使用实时的 LLM API 调用，以避免在个人作品集项目中产生经常性成本。其代码结构（事件处理、DynamoDB 读写）与真实的 Claude/OpenAI API 集成完全相同——接入实时调用只需进行微小且独立的代码修改。

标签：AWS Lambda, DynamoDB Streams, Python, 事件驱动架构, 反欺诈检测, 无后门, 无服务器, 漏洞探索, 逆向工具