风控日报 — 2026-07-07

📊 原料：42 条相关条目（GitHub 仓库搜索 33 条 / arXiv 9 条全部无关——AI 编码 Agent 分布式攻击迭代 VibeCoding、多 Agent 辩论社会结构与潜在目标涌现、360° 全景主动探索 EAGLE-360、LLM 遗忘定位基准 LACUNA、模糊函数编程范式 Program-as-Weights、LLM 在线安全监控阈值校准、X-to-4D 生成对齐 Align4D、可控世界模拟器 WorldDirector、正项级数商的概率符号规则 / HN 和 Trending 本轮无风控相关条目入选）。arXiv 数据源连续十七期（06-13→07-07）返回 100% 噪声，累计 306 条全部无关。2 个垃圾/破解仓库已剔除（kaliarif55/Crypto-Aml-Checker-2026 "Full Version Pro | Premium Loader Mod"、efnciofjioi/aml-checker-pro-master "Full Version Tool 2026"）。另有 16 条已在近 1-2 期日报中覆盖或明显无关（defi-risk-screening、VPN-Detector、marketplace-phaas-tracker、disposable-email ×2、ip-fraud-database、upi-fraud-gnn、quantcore、perishable-inventory-risk-engine、Sentinel-GRC、payment-channel-guide、ai-support-agent、cross-border-fraud-detection、payment-fraud-detector、phase-rs、Oubliette），本轮不重复入选。

今日高信号

1. payguard-realtime-fraud — Kafka→Spark Structured Streaming→Delta Lake→LightGBM 实时欺诈检测（防泄漏时间切分）【信号：★★★】

koutilyaY/payguard-realtime-fraud（0★, Python）是一个实时信用卡欺诈检测系统，技术栈：Kafka → Spark Structured Streaming → Delta Lake → LightGBM，核心亮点是防泄漏的时间有序评估（leak-free time-ordered evaluation），基于真实 ULB 信用卡数据集。风控视角：该项目展示了现代实时欺诈检测的完整数据栈和正确的评估方法：(1) Spark Structured Streaming + Delta Lake——Spark Structured Streaming 提供 Exactly-once 语义的流处理，Delta Lake（带 ACID 事务的数据湖格式）解决了流批一体的存储问题，两者组合是大数据风控的新兴架构选型。(2) 防泄漏时间有序评估——欺诈检测最致命的错误是数据泄漏（随机切分导致用未来训练预测过去），该项目明确强调 leak-free time-ordered eval，说明作者理解欺诈检测评估的核心陷阱。(3) LightGBM 选型——在表格欺诈数据上，LightGBM 以高效率、原生类别特征支持和强不平衡数据处理能力成为生产首选，比 XGBoost 训练更快。与 实时风控引擎 的流式架构和 风控模型 的评估方法论关联。→ GitHub

2. fraud-detection-pipeline — Kafka·Redis 特征存储·XGBoost·FastAPI 实时欺诈评分管道【信号：★★★】

vinay23is/fraud-detection-pipeline（0★, Python）是一个实时欺诈评分管道，技术栈：Kafka（事件流）· Redis（特征存储/feature store）· XGBoost（评分模型）· FastAPI（服务化）· Streamlit（可视化）· Docker Compose（编排）。风控视角：Redis 特征存储是该管道的核心工程亮点：(1) Redis 作为实时特征存储——欺诈评分需要实时拼接用户画像特征（最近 N 分钟交易频次、设备指纹、历史风险分），Redis 的亚毫秒级读取是实时特征查询的标准选型，该项目将 Redis 明确定位为 feature store 而非简单缓存。(2) Kafka 事件驱动 + XGBoost 评分——交易事件经 Kafka 流入，消费侧拉取 Redis 特征拼接后送入 XGBoost 评分，是实时欺诈引擎的标准数据流模式。(3) Docker Compose 全栈编排——Kafka + Redis + FastAPI + Streamlit 一键启动，降低了部署门槛，适合作为风控管道的参考架构模板。与 特征平台 的实时特征存储和 实时风控引擎 的管道架构关联。→ GitHub

3. fraud-detection-gnn — GraphSAGE vs XGBoost 图欺诈检测（Elliptic Bitcoin + GNNExplainer + FastAPI）【信号：★★★】

markasame/fraud-detection-gnn（0★, Python）是一个完整的图神经网络欺诈检测项目：GraphSAGE 节点分类 vs 扁平 XGBoost 基线对比，在 Elliptic Bitcoin 数据集上训练，集成 GNNExplainer 可解释性 + FastAPI 模型服务 + Streamlit 子图可视化仪表盘，技术栈 100% 免费（PyTorch CPU + PyTorch Geometric，无付费 API）。风控视角：该项目的价值在于 GNN 欺诈检测的完整闭环（训练→对比→解释→服务→可视化）：(1) GraphSAGE vs XGBoost 基线对比——通过同时实现图模型和扁平模型并直接对比，展示了 GNN 在图结构欺诈（如洗钱网络）中的增量价值，避免了"上了 GNN 就一定好"的盲目假设。(2) GNNExplainer 可解释性——GNN 的黑箱性是生产落地的障碍（监管要求解释为何某地址被判为非法），GNNExplainer 通过识别关键子图和边来解释 GNN 预测，是图模型可解释性的标准方法。(3) Elliptic Bitcoin 数据集——该数据集是图欺诈检测的公开标杆（200K+ 节点， illicit/unknown/licit 三分类标签），是评估 GNN 欺诈方案的标准化基准。与 反洗钱 的虚拟资产追踪和 反欺诈体系 的 GNN 图算法关联。→ GitHub

4. Financial-Fraud-Detection — GNN + 时序学习 + 异常检测的实时交易欺诈平台【信号：★★】

Suhanikhanna26/Financial-Fraud-Detection（0★, Python）是一个实时交易欺诈检测平台，融合三种技术：图神经网络（GNN）+ 时序学习（Temporal Learning）+ 异常检测（Anomaly Detection）。风控视角：GNN + 时序 + 异常检测的三层融合是欺诈检测方法论的前沿方向：(1) GNN 捕获关系模式——欺诈团伙的行为模式（资金中转、分账套现）体现在交易网络拓扑中，GNN 学习节点关系表征检测团伙欺诈。(2) 时序学习捕获行为漂移——用户正常行为模式随时间演化（消费习惯变化），时序模型（LSTM/Transformer）学习行为基线，检测偏离基线的异常交易。(3) 异常检测作为无监督补充——标记欺诈模式（zero-day fraud）无历史标签可训练，无监督异常检测（Isolation Forest/Autoencoder）提供对未知欺诈的检测能力。三者互补覆盖已知和未知欺诈模式。与 反欺诈体系 的多层检测和 风控模型 的时序学习关联。→ GitHub

5. Payment-Fraud-Detection — XGBoost + SMOTETomek 类不平衡处理的生产级支付欺诈系统（Razorpay 启发）【信号：★★】

adityasaigandham5/Payment-Fraud-Detection（0★, Jupyter Notebook）是一个受 Razorpay 启发的生产级支付欺诈检测系统，技术栈：XGBoost + SMOTETomek（过采样+欠采样混合）+ FastAPI + Streamlit，核心特点：高级特征工程 + 类不平衡处理 + AUC-PR 优化 + 实时预测 + REST API + 交互式仪表盘。风控视角：SMOTETomek 混合重采样和 AUC-PR 优化是欺诈检测类不平衡问题的工程实践：(1) SMOTETomek 混合策略——SMOTE 过采样（对少数类合成新样本）+ Tomek Links 欠采样（移除边界噪声样本）的组合，比单纯过采样或欠采样更有效，先 SMOTE 再 Tomek 清理重叠区域。(2) AUC-PR 优化而非 AUC-ROC——欺诈率 <1% 时 AUC-ROC 虚高，AUC-PR 更真实反映少数类检测能力，该项目明确优化 AUC-PR。(3) Razorpay 启发的端到端工程——对标印度支付巨头 Razorpay 的实际场景，从特征工程到 API 部署的完整链路，是生产级而非 Notebook 玩具。与 支付风控 的类不平衡处理和 风控模型 的评估指标关联。→ GitHub

6. json-rules — TypeScript JSON 规则引擎：一棵 AST 编译为内存检查 + Prisma 查询计划 + SQL WHERE【信号：★★】

inixiative/json-rules（4★, TypeScript）是一个TypeScript JSON 规则引擎，核心创新：一份 JSON 规则定义 → 一棵 AST → 同时编译为三种执行目标：(1) 内存中的快速条件检查（in-memory checks）、(2) Prisma ORM 查询计划（query plans）、(3) 原生 SQL WHERE 子句。风控视角：单 AST 多目标编译是规则引擎工程的前沿模式：(1) 规则与数据存储的协同优化——传统规则引擎（如 Drools）在内存中执行全部规则，需要先将所有数据载入内存；该项目可以将过滤条件直接编译为 SQL WHERE，让数据库先做初步筛选，大幅减少内存中的规则评估量。(2) JSON 规则定义——以 JSON 而非 DSL 描述规则，便于 API 动态下发和前端可视化编辑，适配微服务架构下的集中式规则管理。(3) TypeScript 类型安全——规则引擎在 TS 生态中的工程化实现，对使用 Node.js/TS 技术栈的风控后端团队有参考价值。与 规则引擎 的编译优化和多目标执行关联。→ GitHub

7. payments-platform — 规则引擎 + AI 模型混合的支付风险评分系统【信号：★★】

nameeta35/payments-platform（0★）是一个支付风险评分系统，核心设计：同时支持传统规则引擎和 AI 模型评估支付交易风险。风控视角：规则 + 模型混合是生产风控系统的标准架构：(1) 规则与模型的互补——规则引擎处理确定性风控（黑名单匹配、限额检查、地区封锁），AI 模型处理概率性风控（行为异常评分、团伙关联预测），两者并行评估后融合为最终风险决策。(2) 可解释性与预测力的平衡——规则引擎的决策完全可解释（监管友好），AI 模型提供更强的预测力，混合架构使高风险交易可追溯到具体规则触发原因。(3) 支付场景的评分系统设计——支付交易的风险评分需要综合考虑交易金额、频率、设备、地理位置、商户类别等多维信号，该项目的混合评分框架展示了支付风控的综合评估思路。与 支付风控 的混合架构和 规则引擎 的规则+模型融合关联。→ GitHub

8. risk_engine — Elixir/OTP 实时组合风险引擎（Phoenix.PubSub 阈值告警）【信号：★★】

Null-logic-0/risk_engine（0★, Elixir）是一个基于 Erlang/OTP 的实时组合风险引擎（portfolio risk engine）：摄取交易流，追踪每个组合的现金敞口（cash exposure）、波动率（volatility）和回撤（drawdown），通过 Phoenix.PubSub 广播风险快照和阈值告警。风控视角：Elixir/OTP 的并发模型在实时风控中具有独特优势：(1) OTP 进程模型——Erlang VM 的轻量级进程（每组合一个 GenServer 进程）天然适合大规模并行风险计算，进程间消息传递是无锁的，避免了共享内存模型的并发复杂性。(2) Phoenix.PubSub 实时广播——风险快照和告警通过 PubSub 推送给订阅者（前端仪表盘、告警系统），实现了风险状态的实时感知。(3) 从交易风控到组合风控——虽然该项目是投资组合风险而非欺诈风控，但其"实时摄取→敞口计算→阈值检查→告警推送"的管道模式可直接迁移至实时交易风控（实时计算用户敞口→异常阈值告警）。与 实时风控引擎 的并发架构和 风控模型 的阈值监控关联。→ GitHub

9. healthcare-insurance-analytics — 医疗保险理赔数据分析与欺诈探索（EDA + 利益相关者洞察）【信号：★】

afrah-data/healthcare-insurance-analytics（0★, Jupyter Notebook）是一个医疗保险与理赔数据的探索性数据分析（EDA）项目，使用 pandas 对医疗和保险理赔数据进行利益相关者驱动的洞察分析（stakeholder-driven insights）。风控视角：医疗保险欺诈是风控的重要细分领域：(1) 医疗保险欺诈场景——医疗欺诈包括虚假理赔（phantom billing，未提供的医疗服务）、 UPCoding（低风险服务高报）、身份盗用就医、重复理赔等，与支付欺诈的模式不同。(2) EDA 作为风控建模的第一步——风控模型的效果高度依赖对数据的理解，该项目的利益相关者驱动分析思路（先理解业务方的痛点再确定分析方向）是风控数据探索的正确方法。(3) 跨行业风控方法论迁移——虽然该项目本身是探索性分析而非完整欺诈检测系统，但医疗保险理赔数据的异常模式（频率异常、金额异常、编码异常）与金融欺诈的检测方法论可互相借鉴。与 反欺诈体系 的行业扩展和 特征平台 的数据探索关联。→ GitHub

10. Banking-Fraud-Detection — GNN + Autoencoder 银行信用卡实时欺诈检测【信号：★】

mirabenchauhan128765-art/Banking-Fraud-Detection（0★）聚焦银行信用卡实时欺诈检测，方法：图神经网络（GNN）+ 自编码器（Autoencoder）组合。风控视角：GNN + Autoencoder 组合覆盖监督和无监督两个维度：(1) GNN 的监督学习路径——在标注数据上训练 GNN 识别已知欺诈网络模式（团伙、中转链）。(2) Autoencoder 的无监督路径——训练正常交易的自编码器重建模型，高重建误差的交易标记为异常，检测 zero-day 欺诈。(3) 实时检测的工程挑战——GNN 的实时推理（子图采样+特征聚合）和 Autoencoder 的在线推理需要低延迟工程，该方向值得深入研究。与 反欺诈体系 的无监督检测和 风控模型 的 Autoencoder 异常检测关联。→ GitHub

技术趋势

• Spark Structured Streaming + Delta Lake 成实时欺诈数据栈新选型：payguard-realtime-fraud 展示了 Kafka→Spark Structured Streaming→Delta Lake→LightGBM 的完整管道，Delta Lake 的 ACID 事务 + 流批一体解决了传统数据湖的一致性问题。
• Redis 作为实时特征存储成为标配：fraud-detection-pipeline 将 Redis 明确定位为 feature store（而非简单缓存），亚毫秒级特征查询是实时欺诈评分的基础设施。
• GNN 欺诈检测的完整闭环趋于成熟：fraud-detection-gnn（GraphSAGE+基线对比+GNNExplainer+FastAPI+Streamlit）展示了从训练→对比→解释→服务→可视化的完整工程闭环，GNN 不再停留在 Notebook 实验阶段。
• 规则引擎的多目标编译优化：json-rules 的单 AST→多目标（内存检查+Prisma+SQL WHERE）编译模式，解决了传统规则引擎"全数据载入内存"的性能瓶颈，代表规则引擎工程的前沿方向。
• 类不平衡处理的混合策略：Payment-Fraud-Detection 的 SMOTETomek（过采样+欠采样混合）+ AUC-PR 优化，展示了欺诈检测类不平衡问题的工程最佳实践。
• Elixir/OTP 并发模型在实时风控中的潜力：risk_engine 展示了 Erlang VM 轻量级进程+Phoenix.PubSub 在实时组合风险计算中的应用，进程模型天然适合大规模并行风险评估。

行业案例

• 信用卡实时欺诈检测的数据栈演进：payguard-realtime-fraud 基于 ULB 真实信用卡数据，展示 Kafka→Spark Structured Streaming→Delta Lake→LightGBM 管道和防泄漏时间切分评估。
• 支付欺诈检测的类不平衡工程：Payment-Fraud-Detection 受 Razorpay 场景启发，SMOTETomek 混合重采样 + AUC-PR 优化 + FastAPI + Streamlit 端到端，是印度支付市场风控实践的缩影。
• 比特币交易图欺诈检测：fraud-detection-gnn 在 Elliptic Bitcoin 数据集（200K+ 节点）上做 GraphSAGE vs XGBoost 对比 + GNNExplainer 解释，展示了虚拟资产 AML 的图方法闭环。
• 医疗保险欺诈分析：healthcare-insurance-analytics 从利益相关者驱动的视角做理赔数据 EDA，反映了医疗保险欺诈（虚假理赔、upcoding）这一垂直领域的数据探索实践。
• 投资组合实时风控的并发架构：risk_engine 用 Elixir/OTP 构建组合风险引擎，追踪敞口/波动率/回撤并实时告警，展示了非 JVM 生态在高并发风控中的探索。

值得深入

• payguard-realtime-fraud 的防泄漏时间切分实现：如何确保 Spark Structured Streaming 管道中训练/测试切分严格按时间排序、Delta Lake 的 time travel 如何辅助回溯验证——值得研究其评估正确性的工程保证。→ GitHub
• fraud-detection-pipeline 的 Redis 特征存储设计：特征的 schema 设计、实时更新策略（write-through vs write-back）、特征 TTL 管理、冷热特征分层——值得研究其 feature store 的工程细节。→ GitHub
• fraud-detection-gnn 的 GNNExplainer 子图解释：GNNExplainer 如何识别关键子图和边、解释结果如何在 Streamlit 中可视化呈现、解释是否具备业务可操作性——值得研究图模型可解释性的工程化。→ GitHub
• json-rules 的 AST 多目标编译：AST 如何设计以同时支持内存执行和 SQL 生成、Prisma 查询计划的编译策略、规则复杂度对编译效率的影响——值得研究规则引擎的编译器设计。→ GitHub