📄 Daily Digest

风控日报 — 2026-07-14

📊 原料：45 条相关条目（GitHub 仓库搜索 31 条 / arXiv 8 条全部无关——内存计算 DNN 硬件安全 ARMOR-IMC、Bandit PCA minimax regret、全脑功能对齐 fMRI 解码、信号表示扩散框架 Singularity Space、自修改能量景观 sandscapes、高斯泼溅贝叶斯复杂度控制 DP-Splat、因果推断潜在处理效应谱结构、量子 Krylov 复杂度 Loschmidt——arXiv 返回的论文与 07-09→07-13 完全一致，已连续多日无更新 / HN 16 条和 Trending 20 条经去重后无风控相关条目入选）。arXiv 数据源连续二十三期（06-13→07-14）返回 100% 噪声，累计 380 条全部无关。19 条已在近 1-2 期日报中覆盖（defi-risk-screening、disposable-email-domains [FFraud-com]、VPN-Detector、marketplace-phaas-tracker、ip-fraud-database [FFraud-com]、cross-border-fraud-detection、payment-channel-guide、perishable-inventory-risk-engine、upi-fraud-gnn、graph-fraud-detector [sabrinapribadi]、GraphShield、ai-genai-graph-neural-networks、DRAGNN-FraudDB、hisn-platform、payment-fraud-detector [Para99999]、disposable-email [emailalias]、transaction-risk-engine [Muhammedshibili688]、seine、fraud-risk-engine [Umbura]），本轮不重复入选。另有 8 条明显无关或垃圾项目已剔除（CodeStalker——网络安全 CTF 游戏非风控、ip2geo-python——通用 IP 定位 SDK 无风控工程深度、Credit-Card-Fraud-Detection [Bluehecer]——通用 XGBoost notebook 无工程亮点、real-time-risk-engine [jrajath94]——投资组合 VaR 非欺诈风控、Orbital-Risk-Engine——卫星碰撞风险非欺诈、budget [sonyabytes]——个人记账应用非风控、promptForge——Prompt 构建器非风控、tsec-website——RegTech 落地页无技术深度）。今日原料质量较好，10 条高信号条目入选，涵盖信贷风控 Agent、交易监控平台、Flink 支付风控、GNN 反洗钱、PEP 数据库等方向。

今日高信号

1. MARVIS-Agent — 全栈信贷风控 AI Agent（模型开发 + 验证 + 特征工程 + 策略工作流自动化）【信号：★★★】

eddyzzl/marvis-risk-agent（523★, Python）是 MARVIS-Agent——一个全能信贷风控 Agent（all-purpose credit risk agent），覆盖模型开发（model development）、模型验证（model validation）、数据处理（data processing）、特征工程（feature engineering）和策略工作流（strategy workflows）。风控视角：这是本日报追踪以来星标最高的风控 Agent 项目，代表 LLM Agent 在信贷风控全生命周期的深度应用：(1) 信贷风控的全生命周期覆盖——从数据→特征→建模→验证→策略，MARVIS 将整个信贷风控建模链路封装为 Agent 工作流，而非仅做单一环节（如欺诈评分），这是 Agent 从\"单点工具\"到\"端到端自动化\"的跨越。(2) 模型验证（model validation）的 Agent 化——模型验证是信贷风控的合规要求（SR 11-7 / 模型风险管理框架），通常需独立团队审查模型假设、数据质量、性能稳定性，Agent 辅助验证能大幅降低合规人力成本。(3) 策略工作流自动化——风控策略（额度调整、审批规则、催收策略）的制定和迭代是信贷运营的核心，Agent 化策略工作流意味着策略师可以用自然语言描述目标，Agent 自动生成规则配置和模拟测试。(4) 523★ 的社区信号——在高星项目中实属稀缺，说明信贷风控 Agent 的需求痛点被广泛认可。与 风控模型 的信贷风控建模流程和 实时风控引擎 的 Agent 化运营关联。→ GitHub

2. Smartcomply — 生产级交易监控平台（规则引擎 + 事件驱动风险评分 + Django/Redis Streams + K8s + AI 分类）【信号：★★★】

emmaoluga-sketch/Smartcomply-Transaction-Monitoring-Platform（0★, TypeScript）是一个生产级交易监控平台（Production-ready Transaction Monitoring Platform），技术栈：规则引擎（rule engine）+ 事件驱动风险评分（event-driven risk scoring）+ React 仪表盘，后端使用 Django + Redis Streams + Docker，附赠 Rust 组件、Kubernetes、CI/CD、Terraform、可观测性（observability）和 AI 辅助风险分类（AI-assisted risk classification）。风控视角：这是近期技术栈最完整的风控平台项目之一，覆盖了生产级风控的几乎所有基础设施维度：(1) 规则引擎 + 事件驱动风险评分的双层架构——规则引擎做确定性规则匹配（黑名单、阈值），事件驱动风险评分做动态评分（交易事件触发模型推理），这是现代风控系统的标准分层设计。(2) Redis Streams 作为事件总线——Redis Streams 提供持久化消息队列和消费者组，适合做交易事件的流式分发和风险评分的异步处理，比纯 Kafka 更轻量、更易部署。(3) Rust 组件的性能层——在关键路径（如高频规则匹配、实时评分计算）使用 Rust 实现以获得毫秒级延迟，与 Django 的 Python 层形成性能互补。(4) K8s + Terraform + CI/CD 的 DevOps 成熟度——声明式基础设施（Terraform）+ 容器编排（K8s）+ 自动化流水线（CI/CD），表明该项目具备生产部署的工程标准。与 实时风控引擎 的架构设计、规则引擎 的事件驱动集成和 风控数据架构 的 DevOps 实践关联。→ GitHub

3. transaction-risk-engine — 实时交易风险引擎 + 可解释 AI（Java 后端）【信号：★★★】

ashika0124/transaction-risk-engine（0★, Java）是一个实时交易风险引擎（Real-Time Transaction Risk Engine），明确标注可解释 AI（Explainable AI），仅后端。风控视角：Java 后端 + 可解释 AI 的组合是大型金融机构交易风控的主流技术选型：(1) Java 在风控后端的统治地位——大型银行和支付机构的风控系统以 Java 为主导（Spring Boot 微服务、JVM 生态的成熟度和稳定性），该项目选择 Java 后端符合行业惯例，区别于多数 Python 原型项目。(2) 可解释 AI 作为核心标注——将 Explainable AI 放在项目标题中，说明模型可解释性不是附属功能而是核心设计目标，这在交易风控中至关重要：拦截交易必须给出原因（监管要求 + 用户投诉处理 + 运营审核）。(3) 实时引擎的架构含义——\"Real-Time\"意味着该引擎设计为事件驱动（交易提交时触发风险评分），而非批量离线评分，要求低延迟的规则匹配和模型推理。(4) 与 Muhammedshibili688/transaction-risk-engine 的对比——07-13 已覆盖的 Python 版侧重行为信号融合（geo/device/velocity），本项目的 Java + XAI 侧重可解释性和企业级技术栈，两者互补地展示了交易风控引擎的 Python 和 Java 路线。与 实时风控引擎 的 Java 选型和 模型可解释性 的 SHAP/XAI 实践关联。→ GitHub

kobe8bryant24lakers/flink-risk-platform（0★, Java）是一个生产级 Apache Flink 支付风控平台（Production-style Apache Flink payment risk platform），面向端到端学习（end-to-end learning）。风控视角：Flink 在支付风控实时流处理中的核心地位：(1) Flink 在实时风控中的不可替代性——Flink 是流式计算的行业标准（有状态计算、事件时间语义、精确一次语义），支付风控的实时规则（如\"1 分钟内同一卡号 3 笔失败交易\"）依赖 Flink 的窗口聚合和 CEP（Complex Event Processing）能力。(2) \"Production-style\"的工程含义——区别于学术 Demo，production-style 意味着该项目模拟了真实生产的架构要素：Kafka 消息总线、Flink 状态后端（RocksDB）、Checkpoint 容错、监控告警。(3) 端到端学习项目的价值——作为学习项目，它应该覆盖从数据接入（支付交易事件）→ Kafka → Flink 流处理 → 风控规则/模型 → 决策输出的完整链路，是理解实时风控架构的最佳实践参考。(4) Java 技术栈的支付风控生态——支付系统（如银联、支付宝后端）以 Java 为主，Flink 的 Java API 与支付系统的技术栈天然兼容，使该项目的工程实践可直接迁移到真实支付风控场景。与 实时风控引擎 的 Flink 流处理和 支付风控 的实时规则匹配关联。→ GitHub

5. Lexicon — AI 文档合规平台（事件驱动 + 欺诈检测 + LLM 推理 + 审计，FastAPI/Kafka/K8s）【信号：★★★】

Nersisiian/Lexicon（7★, Python）是一个 AI 文档合规平台（AI Document Compliance Platform），支持事件驱动处理（event-driven processing）、验证（validation）、欺诈检测（fraud detection）、LLM 推理（LLM reasoning）和审计（audit），面向监管报告（regulatory filings）场景。技术栈：FastAPI + Kafka + PostgreSQL + MinIO + Prometheus + Kubernetes。风控视角：文档合规自动化是 AML/KYC 场景的高价值方向，该项目技术栈完整：(1) 监管报告的合规痛点——金融机构需向监管机构提交大量结构化报告（SAR/STR 可疑交易报告、AML 合规报告、风险敞口报告），报告的准确性、完整性和时效性是合规要求，LLM 辅助报告生成和验证是高价值场景。(2) 事件驱动 + Kafka 的文档处理管道——监管报告的提交触发事件（文件上传 → 验证 → 欺诈检测 → LLM 审查 → 审计归档），Kafka 编排这一异步管道，保证可追溯和容错。(3) MinIO 对象存储的合规存证——MinIO 是 S3 兼容的私有对象存储，原始文档和审计日志存储在 MinIO 中保证数据主权和不可篡改性，满足监管对数据留存的要求。(4) LLM 推理在合规审查中的角色——LLM 审查监管报告中的逻辑一致性、数据完整性和合规条款引用准确性，自动化人工合规审查中最耗时的文档阅读和交叉验证环节。与 反洗钱-AML 的合规报告自动化和 风控数据架构 的事件驱动管道关联。→ GitHub

6. anti-gambling-trader-tw — 统计学投资欺诈检测（台股/美股/加密货币 + 诈骗话术扫描 + 假绩效鉴别）【信号：★★】

mars-tw/anti-gambling-trader-tw（28★, Python）使用统计学判断交易是优势（edge）还是赌博（gambling），并检测投资诈骗：扫描群组诈骗话术、检验\"老师\"的胜率宣称、鉴别假绩效报告，支持台股/美股/加密货币，免费开源，数据不离开本地。风控视角：投资诈骗检测是消费者保护风控的前沿场景：(1) 投资诈骗（investment fraud）的检测维度——该项目从三个角度检测投资诈骗：话术扫描（\"保证收益\"\"内部消息\"等诈骗高频词）、胜率宣称验证（用统计检验验证宣称的胜率是否在统计上可信）、假绩效鉴别（用交易记录的统计特征检测伪造的回测/实盘曲线），这三个维度覆盖了投资诈骗的核心特征。(2) 统计检验在欺诈检测中的应用——使用统计学（如二项检验、t-检验）验证交易绩效是否显著优于随机，区别于纯 ML 模型，统计学方法在低数据量场景（如几十笔交易记录）更有效。(3) 社交工程诈骗的检测——扫描群组诈骗话术属于 NLP 文本分类在反诈骗中的应用，与交易欺诈检测的数值分析形成互补。(4) 数据本地处理的隐私设计——全离线运行（\"数据不离开你的电脑\"）适合处理用户的敏感财务数据。与 反欺诈体系 的投资欺诈检测和 风控模型 的统计检验方法关联。→ GitHub

7. AfricaPEP — 开源非洲 54 国政治公众人物数据库（PEP/KYC/AML + 模糊匹配 + Neo4j 图关系）【信号：★★】

PatrickAttankuru/AfricaPEP（1★, Python）是一个覆盖非洲全部 54 国的政治公众人物（PEP, Politically Exposed Persons）开源数据库，面向 KYC/AML 合规团队，技术栈：模糊名称匹配（fuzzy name matching）+ Neo4j 图关系（graph relationships）+ FastAPI + Docker。风控视角：PEP 筛查是 KYC/AML 合规的基础数据层，开源 PEP 数据库填补了商业数据的空白：(1) PEP 筛查的合规要求——反洗钱法规（FATF 建议、各国 AML 法）要求金融机构对政治公众人物（PEP）进行强化尽职调查（EDD），PEP 数据库是 KYC 流程的必要数据源，商业 PEP 数据库（如 World-Check、LexisNexis）价格昂贵。(2) 模糊名称匹配的风控价值——PEP 名称在不同语言和转写中有大量变体（如阿拉伯语/法语/英语转写），模糊匹配（如 Levenshtein 距离、Soundex、Jaro-Winkler）确保不漏检，是名称筛查的核心技术。(3) Neo4j 图关系的关联分析——PEP 不仅是个体，还包括其关联人（家族成员、商业伙伴、代理人），Neo4j 图数据库建模这些关联关系，支持\"二级关联\"查询（如\"该客户是否是某 PEP 的配偶的商业伙伴\"）。(4) 非洲市场的区域覆盖——非洲是反洗钱的高风险区域（部分国家腐败指数高、金融监管薄弱），54 国全覆盖的开源 PEP 数据库对拓展非洲市场的金融机构有实际合规价值。与 反洗钱-AML 的 PEP 筛查和 身份验证 的 KYC 强化尽职调查关联。→ GitHub

8. finomaly — 模块化金融异常检测库（规则 + ML 双引擎 + Python 开源）【信号：★★】

Filidetan597/finomaly（2★, Python）是 Finomaly——一个模块化的开源 Python 库，用于检测金融交易中的异常，同时支持基于规则（rule-based）和机器学习（ML）的方法。风控视角：规则 + ML 双引擎的异常检测库在风控工程中的实用价值：(1) 规则 + ML 双引擎的工程理念——生产风控系统通常同时运行规则引擎（高精度、可解释、低延迟）和 ML 模型（高召回、泛化能力强），两者互补形成分层检测，finomaly 将两者封装在同一库中降低了集成成本。(2) 模块化设计的扩展性——模块化意味着可以独立替换规则集或 ML 模型（如将 Isolation Forest 替换为 Autoencoder），不绑定特定算法，适合快速实验和 A/B 测试。(3) Python 库的集成便利性——作为 Python 库（而非独立平台），可以被 pip 安装并直接 import 到现有风控管道中，与 Pandas/Polars dataframe 无缝集成。(4) 与 PyOD/anomaly detection 库的定位差异——通用异常检测库（如 PyOD）不针对金融场景设计，finomaly 聚焦金融交易数据的领域特征（时间序列、金额分布、交易频率）。与 风控模型 的异常检测方法和 实时风控引擎 的规则+模型双层架构关联。→ GitHub

9. watsonx-vision-toolkit — 视觉文档分析与欺诈检测工具包（Watsonx/Ollama + 文档分类 + 交叉验证）【信号：★★】

qvidal01/watsonx-vision-toolkit（0★, Python）是一个可复用 Python 工具包，用于基于视觉的文档分析（vision-based document analysis），支持 IBM Watsonx AI 或 Ollama（本地推理），包含欺诈检测（fraud detection）、文档分类（document classification）和交叉验证（cross-validation）功能。风控视角：视觉文档分析在 KYC/身份验证中的实用价值：(1) 文档图像分析在 eKYC 中的核心地位——在线开户需要验证用户上传的身份证件（身份证、护照、驾照），视觉模型做证件类型分类、信息提取和篡改检测，是 eKYC 自动化的关键技术。(2) Watsonx / Ollama 双后端的灵活性——支持 IBM Watsonx（云端商业 AI）和 Ollama（本地开源 LLM），云端适合高性能场景、本地适合数据隐私敏感场景，双后端使工具包适用于不同部署环境。(3) 交叉验证的欺诈检测方法——cross-validation 在文档欺诈检测中指的是将 OCR 提取的文本信息与视觉特征交叉验证（如证件印刷质量、水印、全息图一致性），多信号融合提高篡改检测的准确率。(4) 可复用工具包的工程价值——作为 toolkit 而非 monolithic 应用，可被嵌入不同风控流程（KYC 注册、证件更新、理赔审核）。与 身份验证 的文档检测和 反欺诈体系 的合成身份欺诈关联。→ GitHub

10. sentinelpay — 实时加密支付风险层（钱包评分 API + 预存入风控）【信号：★★】

ceemv22/sentinelpay（0★, HTML）是一个实时加密支付风险层（real-time crypto payment risk layer），提供预存入钱包评分 API（pre-deposit wallet scoring API）。风控视角：加密货币支付风控是新兴支付渠道的前沿场景：(1) 加密支付欺诈的独特挑战——加密货币交易的不可逆性（无 chargeback 机制）使支付风控必须在交易上链前拦截，\"pre-deposit\"（预存入）风控即在用户将资金存入平台钱包前进行风险评估。(2) 钱包评分的风险建模——对钱包地址进行风险评分需要分析链上行为（交易历史、关联地址、资金来源、是否与已知黑客/暗网地址有交互），这是加密风控的核心数据源。(3) API 化的集成模式——以 API 形式提供钱包评分，可被交易所、支付网关、DeFi 协议集成到其入金/出金流程中，是 B2B 风控服务的标准交付模式。(4) 加密风控与传统支付风控的对比——传统支付风控有丰富的数据（持卡人信息、交易历史、3DS 验证），加密风控仅有匿名钱包地址，数据稀疏性是最大挑战，需更多依赖图分析和链上情报。与 支付风控 的加密货币场景和 反洗钱-AML 的链上交易监控关联。→ GitHub

技术趋势

行业案例

<!-- PRIVATE SECTION — stripped on publish -->

值得深入

  1. MARVIS-Agent 的 tool schema 和 strategy workflow 设计——523★ 的信贷风控 Agent，值得 clone 下来研究其 Agent tool 定义、prompt 模板和策略工作流编排，对比 04-Projects 中的 Agent 设计。优先级：高。
  2. Smartcomly 的规则引擎 + Redis Streams 集成模式——Redis Streams 消费者组如何做事件驱动的风险评分，以及 Rust 组件在关键路径的性能优化。优先级：中。
  3. flink-risk-platform 的端到端 Flink 架构——作为 Flink 支付风控的学习项目，适合用于 07-Interview-Prep 中 Flink 相关面试题的实践参考。优先级：中。
  4. AfricaPEP 的 Neo4j 图关系建模——PEP 关联人的图建模（家族、商业伙伴、代理人）和模糊名称匹配的工程实现。优先级：低。