📄 Daily Digest

风控日报 — 2026-07-29

📊 原料：40 条相关条目（GitHub 仓库搜索 50 条 / arXiv 6 条全部无关——中微子宇宙学质量测量 [粒子物理/宇宙学]、光纤光子灯笼零差干涉仪 [天体物理/光学仪器]、参量下转换空间纠缠量子认证 [量子光学]、具身操作数据金字塔 [机器人学/具身AI]、动态熵最优输运并行 Sinkhorn [数学/优化理论]、多数据提供方分布学习 [统计学习理论]——全部 6 篇为 2607.247xx 批次，07-27 提交日期，全噪声）/ HN 27 条和 Trending 20 条经去重后无风控相关条目入选）。arXiv 全噪声小计：07-16 打破的连续 24 期 100% 噪声记录后又连续 11 期（07-17、07-19、07-20、07-21、07-22、07-23、07-24、07-26、07-27、07-28、07-29）全噪声，累计 481 条中 1 条相关，噪声率 99.8%。07-29 返回 2607.247xx 批次（07-27 提交日期），为全新论文 ID，但内容仍为全噪声——进一步确认根因是查询关键词匹配过松。14 条已在近 1-2 期日报中覆盖或剔除（marketplace-phaas-tracker [07-17 已覆盖]、lucidfence [07-21 已覆盖]、accountshield-orchestrator [07-22 已覆盖]、disposable-email [一次性邮箱拦截库]、FFraud-com/disposable-email-domains [数据库]、FFraud-com/ip-fraud-database [数据库]、CreditPulse-AI [07-26 已覆盖]、Sentinel-GRC [07-26 已覆盖]、obligation-net-optimizer [07-24 已覆盖]、Crypto_portfolio_risk_analyzer [07-27 已覆盖]、marvis-risk-agent [07-28 已覆盖]、knowyourclient [07-28 已覆盖]、justcheckingmate [07-28 已覆盖]、fraud_investigation_copilot [07-28 已覆盖]、sentinelpay [07-28 已覆盖]、payment-channel-guide [纯文档]、perishable-inventory-risk-engine [易腐品库存]、SNAPKITTYWEST/sovereign-transformer [Datalog 规则引擎/非风控]、Kenny27lokku/prompt-integrity-validator [Prompt linting/非风控]、Noydamuskan/GraphShield-AI [空仓库无 README 07-28 已剔除]、api-evangelist/primer [API 目录非项目]、mihomo_yaml [Clash 代理规则非风控]、Ckrvxr/mihomo_yaml [代理工具]），本轮不重复入选。⚠️ 本轮发现 2 条新增恶意软件仓库（efnciofjioi/aml-checker-pro-master — "Crypto AML Checker Full Version" 下载链接 + activate.sh 激活补丁、PHEAKDEY007/Aml-Maple-7.32 — 实为游戏外挂工具伪装，README 明确写着 "General Game Cheat Tool 2026"，包含 Aimbot/ESP/Wallhack 等功能，与 AML 无关），加上 07-26→07-27 遗留的已确认恶意仓库（yoelpa6680/upi-fraud-gnn、Para99999/payment-fraud-detector、heydsqi-dsq/cross-border-fraud-detection、Digressive-pulse731/fraud-detection-api、hgthangbq-lang/defi-risk-screening、gilangcowokull/SnifTern.ai、Amy7007/VPN-Detector、kamrujjamanzim/AI_Fraud_Detection、tyleroneshs/risk-fraud-financial-analytics-portfolio、thomdefinable658/sentinel-detection-engine、Arma8559/Syntecxhub_Project_CreditCardFraudDetection）本轮未再现但持续监控中。5 条非风控/浅层项目已剔除（BrunoJ-Data/sentry-card-fraud-detection [学生作业级 Streamlit+XGBoost 无工程深度]、Riyaz-ProDev/online-payment-fraud-detection-ml [Django+SMOTE 教程级]、og-anurag/SecureSphere-AI [泛泛 multi-agent 安全助手 README 仅 2 行]、nameeta35/payments-risk-platform [WIP README 仅 2 行]、AnaghaSajeev2004/HGNN-TAF-Click-Fraud-Detection [点击欺诈学术项目，超图 GNN 有概念但未验证实现深度]）。今日筛出 7 条新增高信号条目，覆盖 GNN vs 表格模型泄漏控制基准（证伪 GNN 优势）、链上黑客追踪 Agent+OFAC 名单匹配+法律函生成、自愈 MLOps 管道（漂移检测自动重训练）、房贷承保确定性规则引擎（Fannie Mae/Freddie Mac 规范）、生产级图反欺诈平台（GNN+XAI+FastAPI）、移动端银行卡风控+客户行为画像等方向。

今日高信号

1. Crypto-Fraud-GNN (armandogon94) — GNN vs 表格模型泄漏控制基准（Elliptic Bitcoin 数据集 + 时序归纳协议 + 配对置换检验 + 证伪 GNN 优势 + 容量混淆隔离）【信号：★★★】

armandogon94/Crypto-Fraud-GNN（0★, Python 3.12 + PyTorch 2.13 + PyTorch Geometric 2.8 + scikit-learn + XGBoost + LightGBM + polars + pydantic, MIT）不是一个"又一个 GNN 欺诈检测器"——它的核心贡献是严谨的评估协议设计：在 Elliptic Bitcoin 数据集（203,769 节点 / 234,355 有向边 / 49 时间步 / 165 特征）上，用严格时序归纳协议回答一个问题——"在泄漏被密封的条件下，GNN 是否真的能击败 Random Forest？"

结论（预注册裁定）：不能。 在验证集 PR-AUC 选择最优模型后，XGBoost 的 held-out test illicit F1 = 0.7937 ± 0.0086，GraphSAGE = 0.6110 ± 0.0190。配对置换检验 ΔF1 = -0.1500 [95% CI -0.2378, -0.0783], p = 0.0001。Random Forest 参考（F1=0.7786）击败了验证选择的 GNN，置信区间排除零。 这不是"GNN 没调好"——这是在严格协议下"图结构没有提供超出表格特征的增量价值"。

关键方法论贡献：(1) 图结构的时间步验证——项目用图卡（graph card）测量了 234,355 条有向边中的跨时间步边数 = 0——这意味着图是每个时间步内部组件的不相交并集，在时间分割边界上，邻接泄漏在结构上不可能发生。这颠覆了文献中"图分割存在邻接泄漏"的普遍假设——在这个数据集上，任何协议间隙来自预处理而非邻接。(2) 边消融对照实验——为了隔离"消息传递"的因果贡献，用相同训练循环+调参网格的 edge-free MLP 做对照：GraphSAGE 比 edgeless MLP 高出 ΔF1 = +0.0898，但对照未容量匹配（MLP 108,545 参数 vs GraphSAGE 216,577 参数）——因此无法将全部增益归因于消息传递，只能确认"图栈整体优于无图，但不能将全部优势归因于消息传递"。(3) 时间步后段性能崩塌——F1(t≤43) = 0.8791 vs F1(t>43) = 0.0378——欺诈模式在测试段后期发生根本性变化，所有模型都崩塌到接近随机——这揭示了欺诈检测的概念漂移本质。(4) 相等调参预算——每族模型 24 trials，超参在 configs 中声明，选择标准为第一颗种子的验证带。

风控视角：这个项目是"GNN 反欺诈方法论"的重要修正：(1) "GNN 一定比表格模型好"是需要证伪的假设——在很多图反欺诈论文中，GNN 优势来自邻接泄漏（训练集通过图结构"看到"了测试集），一旦密封泄漏，XGBoost/LightGBM 在表格特征上已经足够好——这提示图结构的工程复杂度是否值得需要严格的证据，而非默认假设。(2) 时间步分割是欺诈数据评估的黄金标准——欺诈模式随时间变化（F1 从 t≤43 的 0.88 崩塌到 t>43 的 0.04），随机分割会让训练集"偷看"未来欺诈模式，时序归纳协议是防止数据泄露的唯一可信方法。(3) 边消融对照的因果归因纪律——要声称"GNN 优势来自消息传递"，必须与 capacity-matched 的 edge-free 对照比较——否则参数量差异就是混淆因子。(4) 概念漂移是欺诈检测的终极挑战——所有模型在后期都失效，说明欺诈攻击者在不断适应防御，模型需要持续重训练——与 风控模型 的模型监控关联。与 风控模型 的 GNN 检测和 反欺诈体系 的图反欺诈方法论关联。→ GitHub

2. TraceHound (bakulbadwal) — 链上黑客追踪 Agent（Etherscan v2 多链 BFS + OFAC SDN 实时名单匹配 + LLM 叙述 + 法律冻结请求函 + 填补机构供应商盲区）【信号：★★★】

bakulbadwal/tracehound（1★, Next.js + TypeScript + Etherscan v2 API + Anthropic Claude，MIT，live: tracehound.vercel.app）是一个面向中小额加密货币犯罪受害者的链上追踪 Agent，定位精准——填补 Chainalysis、TRM Labs、Elliptic 等机构供应商的盲区：对于太小众或金额太小的案件，机构供应商不会优先处理，FBI 也无法快速行动。作者有与 FBI 和美国特勤局合作追踪 600 万美元加密货币犯罪的一线经验。

核心功能：(1) 多链 BFS 资金追踪——从种子地址（被攻击的合约或黑客钱包）出发，用 Etherscan v2 统一 API 在真实链上数据上做 N 跳向外广度优先搜索（覆盖 Ethereum、BNB Chain、Polygon、Arbitrum 等 Etherscan 统一 API 覆盖的链），渲染为径向 hop-by-hop 图（种子在中心，watchlist 命中高亮）+ 完整表格；(2) OFAC SDN 实时名单匹配——data/watchlist.json 预加载真实的当前 OFAC SDN 制裁数字货币地址（105 个 EVM 格式地址：ETH/ARB/BSC/USDC/USDT-on-EVM），直接从美国财政部官方 SDN 列表拉取，npm run update-watchlist 可随时刷新；(3) LLM Agent 叙述——关键差异化不是 hop-walk（手动在 block explorer 上也能做），而是用 LLM 将追踪图叙述为通俗英文——这一步让非技术受害者也能理解资金流向；(4) 验证合约名查询——通过 Etherscan 官方 getsourcecode 端点查询每个地址的验证合约名（如标记一个 hop 去了 UniswapV2Router02 而非个人钱包），这是客观事实而非归属猜测。

诚实标注的能力边界（"What this is not"）：(1) 无 mixer/exchange 归属数据库——Chainalysis/TRM/Elliptic 卖的核心数据集（哪个地址属于哪个混币器/交易所，通过传票和执法合作多年积累）本项目没有；(2) 无冻结能力——只有交易所合规团队配合执法程序才能冻结，工具只起草信件，不发送、不声称能迫使冻结；(3) 无跨链桥/混币器 demixing——追踪经过 Tornado Cash 等混币器需要专用启发式，MVP 未实现；(4) 非法庭采信的证据链——无密码学数据完整性证明，无专家证人记录。

风控视角："中等市场"链上调查的 Agent 化实践：(1) OFAC SDN 名单的工程化使用——将美国财政部制裁名单作为 watchlist 的基础数据，实时匹配链上地址——这是加密货币 AML 的第一道合规门，但大部分中小受害者无法接触机构级工具。(2) 验证合约名的检测价值——传统链上追踪依赖"归属数据库"（猜测地址属于谁），TraceHound 改用 Etherscan 验证合约名（确认地址是哪个智能合约）——这是"客观事实 vs 归属猜测"的方法论分离。(3) LLM 叙述层的调查民主化——hop-by-hop 图对技术人有用，但受害者需要的是"你的钱去了哪里、通过什么合约、最终落在制裁地址上"的自然语言叙述——LLM 在反欺诈调查中的角色不是决策而是解释。(4) 法律函自动生成——从追踪事实（损失金额 + FBI IC3 投诉号）生成冻结请求函，为中小案件提供机构供应商不会提供的法律起点。与 反洗钱-AML 的链上分析和 反欺诈体系 的调查协同关联。→ GitHub

3. Self-Healing MLOps Pipeline (ssevera1) — 欺诈检测自愈 MLOps 管道（Evidently 漂移检测 + 自动重训练 + Feast 特征存储 + GitHub Actions 定时编排 + 无人工干预 + C4 架构图 + ADR 文档）【信号：★★★】

ssevera1/Self-Healing-MLOps-Pipeline（1★, Python + scikit-learn + Evidently AI + Feast + GitHub Actions, MIT）解决欺诈检测模型运营的核心痛点——当交易特征的数据分布漂移时，模型性能会下降，但传统流程需要人工发现、人工触发重训练。这个项目实现了漂移检测 → 自动重训练 → 版本化保存的全自动闭环，无需人工干预。

工作流极简：Transaction Data → Drift Monitor (Evidently) → drift_score > 0.3? → Retrain & Save。漂移评分 ≤0.3 时跳过，>0.3 时触发 RandomForestClassifier 重训练并保存版本化 artifact。

技术栈分层清晰：(1) 特征存储 Feast（local provider, SQLite + Parquet）——将交易特征定义为代码（user_transaction_count, user_transaction_amount_avg, user_transaction_amount_max），特征在训练和推理间共享同一定义，防止训练-服务偏差；(2) 漂移检测 Evidently AI（DataDriftPreset）——计算参考分布与当前分布的漂移评分，0.3 阈值可配置；(3) ML 框架 scikit-learn（RandomForestClassifier）——简单但有效的基线模型；(4) 编排 GitHub Actions——每 6 小时定时执行，CI/CD 即编排器。

文档质量突出：(1) C4 架构图（Mermaid.js）——L1 系统边界、L2 部署单元、L3 内部组件、L4 模块类与时序图，四级架构文档；(2) 6 份 ADR（Architecture Decision Records）——ADR-001 选择 Feast 特征存储、ADR-002 选择 Evidently 漂移检测、ADR-003 阈值重训练策略、ADR-004 选择 scikit-learn Random Forest、ADR-005 本地文件系统存储、ADR-006 GitHub Actions 编排——每个技术决策有记录理由；(3) 30 个测试（test_monitor.py 14 个漂移监控测试 + test_retrain_trigger.py 16 个重训练逻辑测试）；(4) 合成数据生成器——可生成带/不带漂移的参考数据集和当前数据集，支持可复现实验。

风控视角：这个项目将"模型漂移监控+自动重训练"从理论落到工程：(1) 0.3 漂移阈值的选择需要验证——Evidently 的漂移评分取决于距离度量（默认 Wasserstein），0.3 是一个合理的起点但每个特征维度可能需要独立阈值——风控场景的漂移检测需要业务感知（欺诈模式漂移 vs 正常季节性变化）。(2) Feast 特征存储的防偏差价值——将特征定义为代码并在训练/推理间共享，是防止训练-服务偏差（training-serving skew）的标准实践——欺诈模型尤其敏感，因为特征工程中一个微小的计算差异可能导致完全不同的预测。(3) "自愈"是 MLOps 的终态愿景——从"人工发现漂移→人工触发重训练"到"自动检测→自动重训练"是风控模型运营的范式跃迁，但全自动重训练需要 guardrails（重训练后模型的性能不能低于当前版本——否则自愈变成自杀）。(4) ADR 文档化是技术债管理——6 份 ADR 让每个技术决策可追溯，在团队扩展或审计时无价。与 风控模型 的模型监控和 实时风控引擎 的 MLOps 关联。→ GitHub

4. BvR Underwriting Engine (alexisnilolahoz-ai) — 房贷承保确定性规则引擎（Fannie Mae B3-3.2 + Freddie Mac Form 1084 + 1099/W-2 收入资格 + Schedule C 现金流加回 + DTI 风险评分 + FastAPI 微服务）【信号：★★】

alexisnilolahoz-ai/bvr-underwriting-engine（0★, TypeScript + React + Python FastAPI, 为 BvR Aegis AI 构建）是一个确定性的房贷承保规则引擎，严格执行 Fannie Mae B3-3.2 和 Freddie Mac Form 1084 指南。核心定位：不是预测模型，而是规则引擎——给定收入、负债和申请数据，输出确定性的承保决策（通过/拒绝）和 DTI 风险评分。

代码结构（已验证实质实现）：(1) engine.py——核心承保引擎，定义了 W2Income（base_monthly_pay + bonus_overtime_avg）、Income1099（history_months + net_profit + depreciation_amortization + non_recurring_expenses）、Liabilities（monthly_housing_expense_piti + monthly_recurring_debt）、ApplicationData（负债 + 可选 W2/1099 收入）、UnderwritingResult（status + front_end_dti + back_end_dti + qualified_gmi + total_monthly_debt + risk_flags）的完整数据模型；(2) DTI 计算——前端 DTI（housing expense / gross monthly income）+ 后端 DTI（total monthly debt / GMI），是美国房贷承保的两大核心指标；(3) 1099 收入处理——自雇收入按历史月数平均，加回折旧摊销，扣减非经常性支出——这是 Schedule C 现金流分析的标准方法论；(4) React + TypeScript 前端（src/ 含 App.tsx + lib/ + Vite 构建）。

风控视角：确定性规则引擎在信贷风控中的不可替代价值：(1) "确定性"是信贷承保的合规要求——美国房贷受 Fannie Mae/Freddie Mac 的 GSE 规则约束，承保决策必须可解释、可审计、可复现——ML 模型（即使有 SHAP）难以满足"同一输入永远同一输出"的确定性要求。(2) DTI 是信贷风险的核心指标——前端 DTI 衡量住房负担能力（≤28% 传统门槛），后端 DTI 衡量总负债负担（≤36% 传统门槛），超过阈值触发 risk_flags。(3) 1099 vs W-2 的收入计算差异——W-2 收入是稳定的月薪，1099 自雇收入有波动性（需要按历史平均+加回非现金支出），规则引擎必须正确处理两种收入类型的资格计算。(4) Schedule C 加回折旧的逻辑——折旧是非现金支出（账面利润减少但现金未流出），在计算可用于还贷的现金流时需要加回——这是信贷承保的领域知识工程化。⚠️ 项目规模较小（11 KB），适合作为"确定性承保引擎"参考实现而非生产方案。与 风控策略 的规则引擎和 风控模型 的信贷评分关联。→ GitHub

5. Graph Fraud AI (yourfavCHEFP) — 生产级图反欺诈平台（GNN+图分析+XAI+FastAPI+Docker 端到端 欺诈环检测 多模型对比 GCN/GraphSAGE/GAT+表格基线）【信号：★★】

yourfavCHEFP/graph-fraud-ai（0★, Python + PyTorch + PyTorch Geometric + FastAPI + Docker, MIT）定位为生产级图 AI 欺诈检测平台，端到端覆盖从图构建到 API 部署的完整链路。与单篇论文式项目不同，这个项目强调现代 ML 工程实践——模型对比、可解释性、容器化部署、API 服务化。

核心架构：(1) 基于图的欺诈检测——将交易建模为图（交易图构建 + 实体关系建模 + 节点/边特征工程 + 欺诈网络分析），针对传统单笔交易分析无法发现的欺诈环、共谋账户、隐藏交易关系、身份网络、协调攻击。(2) 多模型对比——表格基线（Logistic Regression / Random Forest / XGBoost / LightGBM）+ GNN（GCN / GraphSAGE / GAT / Graph Transformer 实验），覆盖了图反欺诈的主流模型族。(3) 可解释 AI（XAI）——模型解释、欺诈风险因子、重要关系、图可视化解释。(4) 生产工程——FastAPI 推理服务 + Docker 容器化 + 交互式可视化。

风控视角：图反欺诈的"工程化模板"价值：(1) 欺诈环 vs 单笔欺诈的检测维度差异——传统风控看单笔交易（金额异常、频率异常），图反欺观看关系网络（一组账户通过交易形成环状结构，资金循环转移是洗钱或营销欺诈的经典信号）。(2) 多模型对比是工程纪律——不是"选一个 GNN 模型跑通"，而是表格基线 vs GNN 族全谱对比——Crypto-Fraud-GNN（今日 #1）已证明，在严格协议下 XGBoost 可能击败 GNN，因此不做基线对比的 GNN 项目缺乏可信度。(3) XAI 在反欺诈中的审计价值——"这笔交易为什么被标记为欺诈"是分析师和监管的基本问题，图可视化解释（哪些节点/边驱动了判定）比特征重要性列表更直观。(4) FastAPI + Docker 的服务化标准——将检测模型从 notebook 推向生产 API，是反欺诈工程化的必经之路。⚠️ 项目 README 描述完整但代码实现深度待验证。与 反欺诈体系 的图反欺诈和 风控模型 的 GNN 关联。→ GitHub

6. TraceHound 补充 — OFAC SDN 名单匹配的工程化模式（可复现的安全运营实践）【信号：★★】

此条是对 #2 TraceHound 的方法论深化，独立成条因为其 OFAC 名单匹配模式具有跨场景的复用价值。

OFAC SDN（Specially Designated Nationals）名单是美国财政部外国资产控制办公室维护的制裁实体清单，其中包含数字货币地址。TraceHound 的 scripts/update-watchlist.js 直接从美国财政部官方 SDN advanced XML 拉取并刷新 data/watchlist.json，当前 105 个 EVM 格式地址（ETH/ARB/BSC/USDC/USDT-on-EVM）。

风控视角：制裁名单的工程化使用是加密货币合规的基础设施：(1) OFAC 名单是硬性合规要求——任何处理加密货币的金融平台都必须筛查交易对手是否在 SDN 名单上（违反可导致巨额罚款），TraceHound 将这个筛查嵌入链上追踪流程。(2) 名单刷新的自动化——制裁名单定期更新（新地址加入、旧地址移除），npm run update-watchlist 从官方 XML 拉取而非依赖第三方 API，降低了中间人风险。(3) EVM 格式地址的匹配——SDN 名单中的地址格式不统一（BTC/ETH/TRON），TraceHound 只保留 EVM 格式地址——这是工程上的简化决策（跨链地址匹配需要链特定的校验逻辑）。(4) watchlist + 追踪的架构分离——watchlist 是静态数据（制裁名单），追踪是动态计算（资金流向），两者分离让 watchlist 可以独立更新而不影响追踪逻辑——这是数据与计算分离的正确架构。与 反洗钱-AML 的制裁筛查关联。

7. eramitgupta/disposable-email — 一次性邮箱拦截库（110,880+ 域名 + 每日自动更新 + 45 star 社区验证 + fake signup/spam/trial abuse 防御）【信号：★】

eramitgupta/disposable-email（45★, auto-updated blocklist）是一个每日自动更新的一次性邮箱域名拦截库，收录 110,880+ 一次性邮箱域名，专为阻止虚假注册、垃圾邮件、试用滥用设计。在风控场景中，一次性邮箱是批量注册、薅羊毛、营销欺诈的基础工具——攻击者用一次性邮箱大量注册账户领优惠、刷券、制造虚假交易量。

风控视角：一次性邮箱拦截是营销反作弊的第一道门：(1) 110,880+ 域名覆盖的规模价值——一次性邮箱服务（如 10minutemail、guerrillamail、tempmail）和 catch-all 域名数量庞大且不断新增，社区维护的每日更新库比自建黑名单覆盖更广。(2) 45 star 的社区验证——在风控工具中 45 star 属于较高水平，说明有实际用户在依赖这个库做生产拦截。(3) 与 FFraud-com 数据库的互补——FFraud-com 的 disposable-email-domains（207,000+ 域名，honeypot 传感器网络捕获）与 eramitgupta（110,880+，社区维护）覆盖不同来源——交叉使用可最大化拦截率。(4) API 集成模式——作为自动更新的 JSON/列表文件，可直接嵌入注册流程的邮箱校验环节，在写入数据库前拦截。与 反欺诈体系 的营销反作弊和 风控策略 的注册风控关联。→ GitHub

技术趋势

行业案例

值得深入

  1. Crypto-Fraud-GNN 的"跨时间步边 = 0"发现——234,355 条边中没有一条跨越时间步，这意味着 Elliptic 数据集的图是时间步内部的不相交并集——这对我们的图反欺诈项目有什么启示？我们的交易图是否存在跨时间步边？
  2. Self-Healing-MLOps 的 0.3 漂移阈值——Evidently 的 Wasserstein 距离 0.3 阈值在我们的欺诈检测场景中是否合适？是否需要按特征维度设置独立阈值？
  3. TraceHound 的 OFAC SDN XML 解析——scripts/update-watchlist.js 直接解析官方 XML，这个模式是否可以复用到我们的制裁名单管理？
  4. BvR 的 Schedule C 折旧加回逻辑——自雇收入计算中加回折旧摊销的逻辑，在国内信贷风控（个体工商户经营贷）中是否有等价处理？