📄 Daily Digest

风控日报 — 2026-08-07

📊 原料：48 条相关条目（GitHub 仓库搜索 50 条 / arXiv 14 条全部无关——医学深度伪造 HexMIL 多实例学习 [医学影像/AI 安全]、CT 病灶检测自蒸馏 SALT [医学影像]、赛弗特星系 NGC 5548 X 射线外流 [天体物理/高能天体]、过程监督推理训练数据 Reasoning Core [LLM 训练/推理]、非线性 sigma 模型 Lax 连接机器学习搜索 [数学物理/可积系统]、长时 Agent 推理运行时 Argus [LLM Agent]、脑形态测量 MT-GNN 图度量张量 [神经影像/图学习]、跨仓库代码上下文 OctoLong [代码 LLM]、中性原子系综量子互连 [量子计算/量子网络]、视觉 Transformer 方位选择性 IRIS [计算机视觉]、随机指派问题中心极限定理 [概率论/组合数学]、密度岭 SCMS 一致性收敛 [统计/非参数]、强化学习情景探索与神经记忆交互 [RL/探索-利用]、隐私感知课堂事件识别 [计算机视觉/教育]——全部 14 篇为 2608.05xxx 批次，08-05 提交日期，全噪声）/ HN 17 条和 Trending 20 条经去重后无风控相关条目入选）。arXiv 全噪声小计：07-16 打破的连续 24 期 100% 噪声记录后又连续 14 期（07-17、07-19、07-20、07-21、07-22、07-23、07-24、07-26、07-27、07-28、07-29、08-04、08-05、08-07）全噪声，累计 519 条中 1 条相关，噪声率 99.8%。08-07 返回 2608.05xxx 批次（08-05 提交日期），为全新论文 ID（从 08-04 的 2608.037xx 推进到 08-05 的 2608.051xx），但内容仍为全噪声——进一步确认根因是查询关键词匹配过松。~14 条已在近 1-2 期日报中覆盖或剔除（MULE_HUNTER [08-04]、RingGuard [08-05]、Portfolio-Risk-Engine [08-05]、sentinel-risk-engine [08-04]、CreditPulse-AI [07-29]、obligation-net-optimizer [07-24]、lucidfence [07-21]、marketplace-phaas-tracker [07-17]、disposable-email-domains / ip-fraud-database [数据库]、eramitgupta/disposable-email [数据库]、Pricing_and_Risk_Engine [金融衍生品定价]、argentum-engine [MTG 卡牌规则引擎]、legado-rule [网页解析规则引擎]、anas600/erp-v2 [ERP 系统]、axiom [Dart 自律引擎]），本轮不重复入选。⚠️ 恶意仓库持续残留：kamrujjamanzim/AI_Fraud_Detection 和 Digressive-pulse731/fraud-detection-api（07-26 批次已确认恶意）本轮仍在搜索结果中，不重复验证。⚠️ 新增恶意仓库：Suraj0099/SOLANA-AML-Checker（in-repo .zip 诱饵模式，README 为 GitHub Learning Lab 模板但链接 node_modules/reveal.js/plugin/highlight/Checker-SOLAN-AM-3.2-beta.1.zip，典型社攻伪装）。今日筛出 9 条新增高信号条目，覆盖账户保护决策编排、Pix 即时支付截止期感知欺诈评估、联邦学习跨行反欺诈、端到端 AML 监控、生产级 GNN 欺诈检测、UPI GNN 欺诈环检测、IEEE-CIS 支付欺诈评分、GNN+node2vec 社区检测、聚合支付平台风控等方向。今日延续 08-05 的回落模式——GNN 欺诈检测方向集中爆发（3 个新项目 + 2 个已覆盖），反映出 GNN 在金融反欺诈中的持续热度。

今日高信号

1. AccountShield Orchestrator (vinicius-ssantos) — 自适应账户保护决策编排平台（版本化风控策略 + step-up 挑战 + 安全恢复状态机 + 幂等+重放保护 + shadow-policy 对比 + 不可变审计 trace + 安全仿真）【信号：★★★】

vinicius-ssantos/accountshield-orchestrator（0★, Java, CI badge, portfolio-grade backend）是一个账户保护决策与编排层——不替代身份提供商（Keycloak/Auth0/Cognito），而是在其之上评估安全敏感账户事件，决定是 ALLOW、MONITOR、REQUIRE_STEP_UP、TEMPORARILY_BLOCK 还是 START_RECOVERY。

核心工程深度：(1) 版本化策略评估——风控策略版本化（policyKey + policyVersion），每次决策引用具体策略版本，支持策略回滚和审计追溯；(2) 可解释决策——决策响应同时暴露 outcome（动作）+ riskScore + riskBand + algorithmVersion + policyKey/Version，让"为什么拦截"可审计；(3) step-up 挑战生命周期——挑战发放、重试保护、成功率追踪；(4) 安全恢复状态机——START_RECOVERY 触发恢复授权流程，有独立的状态机管理恢复的生命周期；(5) 幂等 + 重放保护 + 速率限制 + 冷却期——防止重放攻击和暴力探测；(6) 不可变审计 trace——每次决策的完整上下文持久化，支持确定性重放（相同输入 + 相同策略版本 → 相同输出）；(7) shadow-policy 对比——新策略先在 shadow 模式运行，与当前策略的结果对比，验证不会锁死合法用户后才上线；(8) 安全场景仿真——内置安全攻击场景模拟，验证策略覆盖。

风控视角：账户保护编排是 ATO 防御的"决策大脑"：(1) "决策层 ≠ 身份提供商"的架构分离——AccountShield 明确定位为"决策和编排层"而非身份提供商，这种分离让风控逻辑独立于认证逻辑，可以跨认证系统复用——与 08-04 Emergency Outflow Lock 的"标准层"理念一致。(2) 版本化策略的工程纪律——风控策略必须版本化：每次决策引用策略版本，支持回滚和审计——这是金融风控"可解释、可审计、可回滚"的基础要求。(3) shadow-policy 对比是策略上线的最佳实践——与 08-04 Android Device Risk SDK 的 shadowMode 和 Ponytail Risk 的影子模式理念完全一致：新策略先在 shadow 模式验证，再切换到生产。(4) 确定性重放的审计价值——"相同输入 + 策略版本 → 相同输出"的可重放性是监管审计的硬性要求——监管询问"为什么两年前这笔交易被拦截"时，必须能重放决策。与 反欺诈体系 的 ATO 防御和 风控策略 的策略管理关联。→ GitHub

2. PixGuard-Sim (CristhianKapelinski) — Pix 即时支付截止期感知欺诈检测评估平台（pre-deadline flag fraction 指标 + MED-2.0 监管截止期 + LLM 5-10s 推理 vs 1.5s 授权预算 + 多生成器交叉验证 + SBSeg 2026 论文）【信号：★★★】

CristhianKapelinski/sbseg2026-pixguard-sim（0★, Python 3.11+, uv, MIT, SBSeg 2026 artifact）是一个检测器无关、生成器无关的欺诈检测评估工具，专为巴西即时支付系统 Pix 设计。核心洞察：Pix 结算不可撤销，且 MED-2.0 监管（2026 年 2 月 2 日起强制）要求金融机构在资金结算前拦截欺诈——因此准确率不够，检测器还必须及时决策。

核心指标创新——pre-deadline flag fraction：传统欺诈检测评估用 precision/recall/F1/PR-AUC，但 PixGuard-Sim 提出截止期感知指标——在可配置的决策截止期内标记的欺诈占比。该指标使用每个检测器的实测推理延迟（而非假设延迟）计算。关键发现：在亚毫秒级表格检测器中，截止期指标退化为 recall（延迟可忽略）；但一旦检测器需要"思考"（如 LLM），指标立即将准确率与可部署性分离——两个 hosted 推理模型在 1000 笔交易上 PR-AUC 达 0.846 和 0.849（零样本，未见过数据），找到 150 笔欺诈中的 112 笔（超过在 16,193 笔标注数据上训练的 Random Forest 的 93 笔），但它们的 P95 延迟分别为 5025ms 和 10329ms，在监管的 1.5s 授权预算内实际拦截的欺诈占比为 0.000。按准确率排序会选择两个无法部署的检测器。

工程严谨性：(1) 三个独立作者的生成器交叉验证——通过 checksum-pinned 适配器在同一 harness 上运行三个独立生成器；(2) 两个 Pix 原生场景——多跳 MED-2.0 退款追踪和胁迫场景（开源先前工作中缺失）；(3) 可复现性——固定种子 + 内容哈希输入/输出，E4 实验检查帧哈希等价性；(4) SBSeg 2026 artifact 四 seal——SeloD（可用）/ SeloF（功能）/ SeloS（可持续）/ SeloR（可复现）。

风控视角："准确率 × 延迟 = 可部署性"是实时风控的核心公式：(1) 截止期感知评估填补了评估框架的空白——传统欺诈检测论文只报 AUC/F1，PixGuard-Sim 证明了"高 AUC 但高延迟 = 不可部署"——这对所有实时风控系统都有方法论价值。(2) LLM 在实时风控中的延迟陷阱——LLM 推理模型零样本 PR-AUC 0.849 看似惊艳，但 5-10 秒的推理延迟使其在 1.5s 授权预算内的实际拦截率为零——这是"LLM 做实时风控决策"的现实约束。(3) MED-2.0 监管的工程含义——巴西央行的 MED-2.0 要求"结算前拦截"是即时支付系统的全球趋势（印度 UPI 也有类似要求），结算不可撤销意味着拦截窗口=授权窗口。(4) 合成数据 + ground truth 标注的评估方法——所有数据为合成且 ground truth 标注，避免真实欺诈数据隐私问题，同时保证可复现性。与 实时风控引擎 的延迟约束和 风控模型 的评估方法论关联。→ GitHub

3. CF-Intelligence (yusufcalisir) — 联邦学习+差分隐私跨行反欺诈与协同 AML 平台（FedAvg/FedProx/Krum/Bulyan + Opacus DP + SecAgg + GNN + <100ms 推理 + FinCEN SAR XML + WAF + 多区域 DR + CBDC 激励结算）【信号：★★★】

yusufcalisir/CF-Intelligence（0★, Python 3.12 + FastAPI + PyTorch, live: cf-intelligence.vercel.app, MIT）是一个企业级隐私保护跨行欺诈检测与协同反洗钱情报平台。核心问题定位精准：GDPR Art. 6/17、CCPA、银行保密法严格禁止跨机构集中原始客户交易数据，这种数据碎片化导致系统性漏洞——跨行 velocity 和骡子洗钱（犯罪团伙在几分钟内将资金在 Bank Alpha → Bank Beta → Bank Gamma 间顺序转移，在单一银行的规则引擎检测到 velocity 异常前就已清算）和结构化 smurfing 网络（将大额非法存款拆分为微交易分布在多家机构以低于单行报告阈值）。

技术架构（六层）：(1) 本地隐私与模型训练边界——Opacus 差分隐私守卫（L2 裁剪 C + 噪声尺度 σ）+ 出站异常防御 + SecAgg 密码学种子掩码；(2) 拜占庭鲁棒服务器协调引擎——FedAvg / FedProx / Krum / Trimmed Mean / Median / Bulyan 六种聚合算法，防御恶意参与方投毒；(3) 金丝雀质量门 + 模型注册——Holdout AUC 验证 → 自动晋升 champion / 自动回滚；(4) 实时推理与运维服务——实时评分网关（<100ms SLA）+ SHAP 解释 + 6 阶段案件管理工作台（四眼原则监督认证）+ FinCEN BSA SAR XML 电子申报；(5) 企业基础设施——Edge WAF（SQLi/XSS/IP 白名单）+ Active-Passive 多区域 DR 故障转移（RTO <30s）+ HMAC-SHA256 Webhook + SIEM 日志导出（Syslog CEF/Splunk HEC/Datadog）；(6) Web3 CBDC 智能合约激励结算（.sol）——参与联邦训练的银行通过 CBDC 智能合约获得激励。

风控视角：联邦学习是跨行反欺诈的隐私-效用权衡解法：(1) "跨行 velocity"是单行风控的盲区——洗钱团伙利用机构间数据孤岛，在单行看来正常的交易模式实际上是跨行协调犯罪——联邦学习让多家银行"联合训练、分别推理"打破这个盲区。(2) 拜占庭鲁棒聚合防御投毒攻击——联邦学习的核心威胁是恶意参与方投毒（提交错误梯度破坏模型），Krum/Bulyan 等鲁棒聚合算法是防御手段。(3) Opacus 差分隐私的形式化隐私保证——(ε,δ)-DP 提供数学隐私保证，满足 GDPR 等法规的隐私要求——比"我们匿名化了数据"的口头承诺更有法律效力。(4) FinCEN SAR XML 电子申报的合规闭环——检测到可疑活动后自动生成 SAR（Suspicious Activity Report）XML 并电子上报 FinCEN，完成从"检测"到"合规申报"的完整闭环。与 反洗钱-AML 的跨行协同和 风控模型 的联邦学习关联。→ GitHub

4. AegisAML (waleed-ahady) — 端到端反洗钱交易监控平台（IBM 合成数据 + 时间因果特征工程 + 成本感知阈值 + Kafka/Redpanda 流式评分 + FastAPI + PSI 漂移监控 + NetworkX 图调查 + 分析师反馈闭环）【信号：★★★】

waleed-ahady/aegis-AML（0★, Python 3.11-3.13, Docker Compose + GitHub Actions + CodeQL + Dependabot）是一个生产导向的反洗钱交易监控平台，将 IBM 风格合成银行交易转化为可复现的验证→特征工程→成本感知训练→实时评分→流式告警→分析师反馈→漂移监控→网络调查管道。核心差异化：大多数欺诈项目止步于 notebook + 高准确率，AegisAML 包含模型周围的运维路径。

完整管道：(1) IBM AML CSV schema 摄取——数据质量报告；(2) 时间因果特征管道——按时间顺序的 train/validation/test 分割，历史特征严格从先前交易计算（防止未来信息泄漏）；(3) 本地图特征——先前交易对计数、唯一对手方数；(4) 成本感知阈值优化——在告警容量和召回约束下优化阈值，而非仅优化 F1；(5) 版本化模型 bundle——在线特征状态快照 + 模型版本管理；(6) FastAPI 评分服务——实时交易评分 + 告警持久化 + Prometheus 指标；(7) Kafka/Redpanda 流式——生产者+消费者交易重放；(8) 离线账户网络风险排名——NetworkX 图分析；(9) PSI + 分类分布漂移报告——监控训练-测试分数分布偏移；(10) 分析师反馈 → 未来重训练数据集——形成模型迭代闭环。

风控视角："模型周围的运维路径"是 AML 系统工程化的核心：(1) 时间因果特征防泄漏——历史特征严格从先前交易计算是时序数据的黄金准则，防止"用未来信息预测过去"——与 08-05 Review Authenticity Engine 的数据泄漏自检理念一致。(2) 成本感知阈值优于纯 F1 优化——AML 系统的告警容量有限（分析师人力），成本感知阈值在"告警量 × 召回率"约束下优化，比纯 F1 更贴近运营现实。(3) PSI 漂移监控是 MLOps 基础——PSI（Population Stability Index）监控训练-生产分数分布偏移，是模型衰退的早期预警——与 08-04 FraudFlow AI 路线图中的"漂移检测"一致，但 AegisAML 已实现。(4) 分析师反馈闭环——检测→告警→分析师标注→反馈→重训练数据集，形成模型持续迭代的闭环——这是生产 AML 系统区别于演示项目的核心标志。与 反洗钱-AML 的交易监控和 风控模型 的 MLOps 闭环关联。→ GitHub

5. Graph Fraud AI (yourfavCHEFP) — 生产级图 AI 金融欺诈检测平台（GCN/GraphSAGE/GAT/Graph Transformer + 基线对比 + 可解释 AI + FastAPI + Docker + 图分析）【信号：★★★】

yourfavCHEFP/graph-fraud-ai（1★, Python + Jupyter Notebook + FastAPI + Docker）是一个端到端图机器学习平台，将金融活动建模为图来检测隐藏在交易网络中的复杂欺诈模式——欺诈环、协同账户、隐藏交易关系、身份网络、协调攻击。

技术栈分层：(1) 图构建——交易图构建 + 实体关系建模 + 节点/边特征工程 + 欺诈网络分析；(2) 基线模型——Logistic Regression / Random Forest / XGBoost / LightGBM 表格基线；(3) GNN 模型——GCN（图卷积网络）、GraphSAGE（归纳式图采样）、GAT（图注意力网络）、Graph Transformer 实验；(4) 可解释 AI——模型解释 + 欺诈风险因子 + 重要关系 + 图可视化解释；(5) 生产工程——FastAPI 推理服务 + Docker 容器化 + 交互式可视化。

风控视角：GNN 欺诈检测的"全家桶"工程实践：(1) 多 GNN 架构对比的方法论价值——同时实现 GCN/GraphSAGE/GAT/Graph Transformer 并与表格基线（XGBoost/LightGBM）对比，是评估"GNN 到底比表格模型好多少"的系统化方法——08-05 RingGuard 的方法论一致。(2) GraphSAGE 的归纳式推理价值——与 GCN 的直推式（transductive）不同，GraphSAGE 学习聚合函数而非节点嵌入，可以对新节点推理——这对风控场景（新用户、新商户不断出现）至关重要。(3) GAT 的注意力机制在欺诈检测中的语义——GAT 的注意力权重可以解释"这个节点的哪些邻居贡献了风险"，天然具有可解释性——与可解释 AI 模块呼应。与 风控模型 的 GNN 检测和 反欺诈体系 的图反欺诈关联。→ GitHub

6. Mule-Hunt (sohamvjadhav) — UPI 支付图 GNN 欺诈环检测管道（GCN/GraphSAGE/GATv2 + Jumping-Knowledge + 环感知分割 + Isotonic 校准 + 冷启动回退 + GNNExplainer + PSI 漂移 + FastAPI）【信号：★★★】

sohamvjadhav/Mule-Hunt（1★, Python 3.11+, MIT, dashboard + FastAPI）是一个GNN 管道，用于检测 UPI 风格支付网络中的协调欺诈。核心建模：账户为节点、转账为有向边、欺诈环为一组循环转账的账户。模型预测哪些账户属于欺诈环，评估网络级信号（异常连接性和协调循环）——这些信号在逐笔交易分析中不可见。

工程深度亮点：(1) 合成数据——使用 SantanderAI/gen-fraud-graph 生成合成 UPI 风格图 + 内置小型生成器供离线测试；(2) 环感知分割——train/validation/test 分割时保留完整欺诈环（hold out complete fraud rings），而非随机分割——防止同一环的节点同时出现在训练和测试中导致数据泄漏；(3) 三种 GNN + Jumping-Knowledge——GCN / GraphSAGE / GATv2，可配置深度（消息传递层数），使用 JK 聚合替代硬编码 2 跳感受野；(4) 交易级头部——在同一骨干上添加逐笔交易风险评分（节点嵌入 + 金额/时间特征），与节点损失联合训练；(5) Isotonic 概率校准——验证集 Brier score 报告，校准概率输出；(6) 冷启动回退——低活跃账户（邻域太小 GNN 无法评分）回退到梯度提升表格模型——这是工程化的"降级策略"；(7) PSI 漂移监控——train/test 分数分布偏移监控；(8) GNNExplainer 模型接地解释——在账户的 2 跳邻域上运行 GNNExplainer，报告哪些特征和邻居驱动了风险评分——可选 LLM 生成自然语言解释（无 API key 时有确定性本地回退）。

风控视角：环感知分割和冷启动回退是 GNN 反欺诈的工程纪律：(1) 环感知分割防数据泄漏——随机分割会让同一欺诈环的节点同时出现在训练和测试中，导致模型"记住"而非"泛化"——环感知分割是图反欺诈评估的正确方法。(2) 冷启动回退的工程价值——GNN 需要足够邻域才能评分，但新用户/低活跃用户的邻域太小——回退到表格模型是生产系统必须有的降级策略。(3) GNNExplainer 的可解释性——GNN 的"黑盒"问题比表格模型更严重（图结构传播使得贡献路径复杂），GNNExplainer 通过子图掩码识别关键邻居——这是图反欺诈可解释性的前沿。(4) Isotonic 校准在欺诈决策中的价值——概率校准确保模型输出的分数可以解释为真实概率（校准后的 0.7 意味着 70% 的欺诈概率），对阈值决策至关重要。与 风控模型 的 GNN 检测和 反欺诈体系 的欺诈环检测关联。→ GitHub

7. RiskFlow PayGuard (kivancfk) — IEEE-CIS 支付欺诈风险评分平台（LightGBM + 概率校准 + 漂移诊断 + 成本感知 ALLOW/REVIEW/BLOCK + TreeSHAP reason codes + 63 特征契约 + 4 阶段完成）【信号：★★★】

kivancfk/riskflow-payguard（0★, Python, IEEE-CIS Fraud Detection dataset）是一个端到端支付欺诈风险工程项目，围绕 IEEE-CIS 数据集构建，目标是将原始支付数据转化为欺诈风险评分、运营决策（ALLOW/REVIEW/BLOCK）、解释和监控输出——定位为可部署的金融科技产品而非仅 notebook 练习。

四阶段完成度（Phase 1-4 全部 Complete，Product integration 待实现）：(1) Phase 1——本地数据工作流 + EDA + 特征工程 + 按时间顺序的模型数据集；(2) Phase 2——可复现 LightGBM 基线 + 欺诈导向评估 + 版本化模型 bundle（baseline-v1，PR-AUC 0.4946 / ROC-AUC 0.8808 on test）；(3) Phase 3——概率校准 + 漂移诊断 + 策略优化 + 版本化策略 bundle；(4) Phase 4——原生 LightGBM TreeSHAP + 确定性贡献 + reason codes + artifact 不可变性检查。

工程严谨性亮点：(1) 63 特征模型契约——29 分类 + 34 数值特征，明确特征契约；(2) 仅训练集分类词汇表——防止测试集泄漏到训练词汇中；(3) 缺失类别和未见类别处理——推理时处理未见过的类别值；(4) sigmoid 概率校准——校准拟合和策略选择使用不同验证分区；(5) 成本感知 ALLOW/REVIEW/BLOCK 阈值优化——显式欺诈策略成本和运营约束（告警容量、召回要求）下的阈值优化；(6) artifact 不可变性检查——frozen model 和 policy artifact 的不可变性验证 + 重载 bundle 推理测试；(7) TreeSHAP reason codes——稳定的分析师 reason codes + 已观测/缺失/未知类别解释状态 + 批量和单行解释一致性。

风控视角："数据→评分→决策→解释→监控"的完整工程链路：(1) 概率校准 + 成本感知阈值是运营决策的基础——模型输出原始 logit 分数需要校准为概率，再结合业务成本（误报成本 vs 漏报成本）优化 ALLOW/REVIEW/BLOCK 阈值——这是从"模型分数"到"运营决策"的工程桥梁。(2) TreeSHAP reason codes 的合规价值——每笔拦截决策附带 reason codes（"哪些特征贡献了风险"），满足监管对"可解释拦截"的要求——与 08-04 Sentinel Risk Engine 的可解释设计一致。(3) artifact 不可变性是模型审计的基础——模型和策略 artifact 不可变 + 版本化 + 重载验证，确保"这笔交易两年前被拦截时使用的是哪个模型版本"可追溯。(4) IEEE-CIS 作为标准基准——IEEE-CIS 是欺诈检测领域最常用的公开基准之一，baseline-v1 的 PR-AUC 0.4946 提供了可对比的参考点。与 风控模型 的评分卡设计和 风控策略 的决策引擎关联。→ GitHub

8. AI Fraud Graph Network (jhondados) — GNN+node2vec 社区检测欺诈环检测（⚠️ 仅 1.7KB 骨架代码 + 占位符随机特征 + 性能指标无代码支撑）【信号：★】

jhondados/ai-fraud-graph-network（0★, Python + HTML）是一个基于图的欺诈检测系统，建模账户、设备、IP、商户、卡之间的关系。GraphSAGE 3 层消息传递 + 交易 velocity、共享实体、历史欺诈标签特征。声称 GNN 达到 0.982 AUC-ROC，检测到 247 个有组织欺诈环，误报率 2.1%（vs XGBoost 表格模型的 0.891 AUC / 0 欺诈环 / 8.2% 误报率），实时评分 <12ms。

风控视角：⚠️ 低实质项目——声称的性能指标无代码支撑：(1) 验证发现该仓库仅 31KB、3 个文件——38KB 的 index.html（葡萄牙语 GitHub Pages demo）、1.7KB 的 fraud/gnn_detector.py（仅一个 SAGEConv 骨架 + torch.randn(n, 16) 占位符随机特征），无 node2vec、无社区检测、无 API 服务器、无数据集、无训练管道、无测试。(2) README 头条的 0.982 AUC / 247 欺诈环 / <12ms 指标无法从仓库代码中复现——应视为营销声明而非证据。(3) 核心论点"GNN 检测欺诈环 vs XGBoost 检测 0 个"在方法论上有参考价值，但本项目未提供任何代码佐证。保留为"GNN 欺诈环检测"方向的追踪条目，但所有性能数字待验证。与 风控模型 的 GNN 检测关联。→ GitHub

9. Szy_Pay 易支付 (sanzhiyuwl) — 聚合支付平台文档（服务商模式商户进件 + 微信特约商户 + 进件风控 + 消费者投诉管理 + 分账结算 + Go+Vue3）【信号：★★】

sanzhiyuwl/SzyPay-docs（1★, Go + Vue3, 文档仓库 v1.2.0）是一套面向数字商业的电子支付通道平台文档——对上聚合各家支付渠道，对下给商户一套统一的收款接口、收银台与自助中心，把订单、回调、结算、对账、风控收敛成开箱即用的服务。

核心能力与风控关联：(1) 服务商模式商户进件——商户在平台服务商名下进件，拿到子商户号，资金由渠道直清到商户自己的账户（平台账户无资金停留）；(2) 进件风控与业务管控——进件驳回逐字段回显、子商户业务受限状态查询与快照、受限即锁收单、处置通知实时订阅；(3) 消费者投诉管理——微信消费者投诉 2.0 全闭环：工单台、协商记录、回复与传图、退款审批、站内信触达；(4) 清晰的资金视图——订单、流水、结算、对账、分账、代付一目了然。

风控视角：支付平台的风控嵌入点是工程实践参考：(1) "进件风控"是支付平台的第一道门——商户进件时的风控审核（资质验证、行业类目审核、黑名单匹配）决定了平台是否接纳这个商户——这是 B 端风控的核心场景。(2) "受限即锁收单"的实时联动——子商户业务受限状态实时同步，一旦受限立即锁定收单能力——这是支付平台风控与业务系统的实时联动设计。(3) 资金直清的合规设计——平台账户无资金停留（"二清"风险规避），资金由渠道直接结算到商户账户——这是中国支付合规的架构设计。(4) ⚠️ 文档仓库无源码——价值在于支付平台架构和风控嵌入点的设计参考，非可运行代码。与 支付风控 的平台架构和 风控策略 的商户风控关联。→ GitHub

技术趋势

行业案例

值得深入

  1. PixGuard-Sim 的 pre-deadline flag fraction 指标——如何将"准确率 × 延迟 = 可部署性"的评估框架引入我们的风控模型评估？我们当前的风控模型是否有类似的延迟预算约束？
  2. AccountShield 的版本化策略 + shadow-policy 对比——策略版本化如何实现？shadow-policy 对比在策略上线流程中如何落地？我们的策略管理是否具备这种可回滚、可审计的能力？
  3. Mule-Hunt 的环感知分割——图数据的 train/test 分割如何防止同一欺诈环的节点泄漏？这种分割策略如何标准化到我们的 GNN 模型评估中？
  4. CF-Intelligence 的拜占庭鲁棒聚合——FedAvg/FedProx/Krum/Bulyan 六种聚合算法在跨行联邦学习中的投毒防御效果对比？哪些算法适合我们的跨机构协同场景？