📄 Daily Digest

风控日报 — 2026-07-27

📊 原料：40 条相关条目（GitHub 仓库搜索 31 条 / arXiv 9 条全部无关——3D-Aware VLM 隐式/显式几何 [3D 视觉语言模型]、XMM-Newton NGC 4945 X 射线暂现源 [天体物理/X 射线]、凹版印刷质量控制合成数据 [印刷/工业检测]、统一视频密集预测 [视频理解]、扩散模型渐进种子剪枝 [生成模型推理]、AXIS 机器人操作数据引擎 [机器人学]、WorldWeaver 多 Agent 视频扩散世界模型 [视频生成/世界模型]、本征函数自由边界时频定位 [纯数学]、视频自监督结构化动力学 [视频运动分解]——全部 9 篇为 2607.215xx 批次，与 07-26 完全一致）/ HN 23 条和 Trending 20 条经去重后无风控相关条目入选）。arXiv 全噪声小计：07-16 打破的连续 24 期 100% 噪声记录后又连续 9 期（07-17、07-19、07-20、07-21、07-22、07-23、07-24、07-26、07-27）全噪声，累计 465 条中 1 条相关，噪声率 99.8%。07-27 返回的 2607.215xx 批次与 07-26 完全一致（9 篇论文 ID 全部相同），确认 API 再次进入缓存期。19 条已在近 1-2 期日报中覆盖或剔除（accountshield-orchestrator [07-22 已覆盖]、lucidfence [07-21 已覆盖]、marketplace-phaas-tracker [07-17 已覆盖]、FFraud-com/disposable-email-domains [数据库]、FFraud-com/ip-fraud-database [数据库]、CreditPulse-AI [07-26 已覆盖]、Sentinel-GRC [07-26 已覆盖]、sentinel-risk-engine [07-23 已覆盖]、AegisOS [07-23 已覆盖]、gnn-fraud-detection [07-26 已覆盖]、network_aware_fraud_experiments [07-26 已覆盖]、payment-channel-guide [纯文档]、perishable-inventory-risk-engine [易腐品库存]、tsec-website [RegTech 落地页]、sanki-engine.rs [国际象棋游戏引擎]、obsidian-rule-engine [Obsidian 插件]、nop-entropy [低代码平台]），本轮不重复入选。⚠️ 本轮发现 2 条新增恶意软件仓库（thomdefinable658/sentinel-detection-engine、Arma8559/Syntecxhub_Project_CreditCardFraudDetection），均通过 .zip 下载链接隐藏在 docs/images/ 和 outputs/plots/ 目录分发恶意载荷——加上 07-26 遗留的 6 个恶意仓库（hgthangbq-lang/defi-risk-screening、Digressive-pulse731/fraud-detection-api、Amy7007/VPN-Detector、yoelpa6680/upi-fraud-gnn、heydsqi-dsq/cross-border-fraud-detection、Para99999/payment-fraud-detector），GitHub 风控关键词搜索的恶意软件污染持续恶化。今日筛出 6 条新增高信号条目，覆盖开源业务风控系统 2.0、移动端触摸行为生物识别、执法机构 GNN 欺诈情报平台、生产级支付欺诈检测+漂移监控、医保索赔欺诈 ETL 管道、浏览器端加密货币组合风险分析等方向。

今日高信号

threathunterX/nebula2（1★, Java + Flink + Kafka + React，Apache-2.0）是开源业务风控系统，实时识别撞库、盗号、恶意注册、刷单、薅羊毛、爬虫等业务风险。核心定位明确：不是"请求有没有 SQL 注入"（WAF 的职责），而是"跨事件、跨时间窗、跨主体维度的行为分析"——同一个 IP 10 分钟登录失败 50 次→撞库；500 个新注册用同一设备指纹→批量注册；活动开始 3 秒领走 80% 券→薅羊毛。

四层风控模型是其核心架构：Event（业务行为）→ Variable（统计特征）→ Strategy（判定规则）→ Notice（风险结论）。一条告警的完整链路：攻击者→业务系统上报 ACCOUNT_LOGIN 事件→collector 就地脱敏（口令/Cookie 抹掉，IP/账号保留——因为 IP 哈希会让地理定位、信誉查询、跨维度关联全部失效）→Kafka→Flink 引擎计算变量（如"该 IP 10 分钟内失败次数=6"）→策略判定（失败次数>5 且 result==F）→Redis 名单写入（review，TTL 5min）→业务系统下次请求查 /checkRisk。

继承自 Nebula 1.x（2019 开源，1098 star）的领域资产：17 类事件模型、253 个统计变量、170 条策略模板——这些是经过审计的风控知识沉淀。技术栈完全重写，只继承领域资产不继承代码。

工程亮点：(1) 采集端脱敏的两条界限设计——sensitive（口令/Cookie）在采集端就地脱敏（原文不出网络边界），pii（IP/账号）保持原值由存储层加密保护——这是深思熟虑的隐私设计，而非遗漏；(2) 19 条 WAF 类规则作为补充——SQL 注入、XSS、目录遍历等特征匹配，但明确声明"不能替代专业 WAF"；(3) Mermaid 图文档化完整链路——README 用 flowchart 和 sequenceDiagram 可视化从事件到告警的全流程；(4) 诚实标注项目状态——0.x 早期版本，docker compose up 可起完整链路做评估，但全部组件单节点无高可用，K8s 编排尚未开始。

风控视角：这是罕见的"完整开源业务风控系统"，核心价值在领域模型而非技术栈：(1) 四层模型的解耦设计——Event/Variable/Strategy/Notice 四层将"数据采集→特征计算→规则判定→风险输出"解耦，每层可独立迭代，是风控系统架构的正确分层。(2) "旁路采集"的工程优势——不侵入业务系统代码，通过采集业务流量或日志旁路还原标准化事件，降低了风控系统与业务系统的耦合。(3) 253 个统计变量是风控的"特征工程资产"——这些变量不是临时编写的，而是从 1098 star 的 Nebula 1.x 继承并经审计的领域知识沉淀，覆盖了时序（velocity）、频次、空间（多设备/多 IP）、主体关联等多维度。(4) 采集端脱敏的隐私合规价值——GDPR/PIPL 要求"数据最小化"，在数据离开网络边界前就脱敏是最强的隐私保护措施，同时保留风控所需的 IP/账号原值是经过权衡的正确决策。与 实时风控引擎 的实时计算和 风控策略 的规则引擎关联。→ GitHub

2. gesture-fingerprint (threathunterX) — 移动端触摸行为生物识别（9 维度区分手人/脚本/作弊硬件 + 75k+ 标注手势 + 8 种市售作弊设备实测 + 证据驱动判定）【信号：★★★】

threathunterX/gesture-fingerprint（0★, Python，双语 README）解决一个精准问题：判定一次手机触摸/滑动来自人手、软件脚本，还是某一种特定的作弊硬件——不只是"人机识别"，而是告诉你是哪一种机器。项目用 8 类市售作弊硬件（从 61.9 元电容点击器到 1535 元机械臂，总计 1863.6 元）在 3 部手机、多种系统版本和手机状态（平放/竖放/手持/地铁）下采集，每类每场景重复 300-500 次，累计 75,000+ 条有效手势。

能识别的 10 类来源：(1) 真人（对照基准）；(2) 软件类——代码开发脚本、屏幕录制脚本、HID；(3) 硬件类——电容点击器、鼠标点击器、机械臂、自动滑屏点赞器、刷屏器一、刷屏器二。每类工具的轨迹签名都不同：真人散成扇形带自然弯曲；机械臂最接近真人但更集中；代码脚本是一根根笔直竖线钉在固定 X 坐标；屏幕录制只剩两条折线（250 次回放同一段录制）；刷屏器收缩成一小束（物理电机只走一条道）。

9 个行为维度逐项量化区分：接触面积（px²）、平均压力、速度波动系数、路径冗余率等。每条判定附带证据而非黑箱打分：如"接触面积接近 0 且平均压力接近 1，符合注入/非真实接触类基础特征；逐点压力波动接近 0；路径冗余率落在录制轨迹常见区间→自动化脚本-屏幕录制"。

风控视角：这个项目展示了"反作弊行为生物识别"的实验级深度：(1) "是哪一种机器"比"是不是人"更有运营价值——传统人机识别只输出二元结果（人/非人），但知道是"机械臂"还是"屏幕录制脚本"让风控团队能针对性封堵（如检测到 HID 设备可封锁蓝牙通道）。(2) 物理硬件实测是反作弊的黄金标准——纯数据集训练的模型可能过拟合到已知模式，购买市售作弊硬件在真机上实测确保覆盖真实攻击工具的轨迹分布。(3) 接触面积+压力的物理直觉——真人触摸有真实接触面积（手指物理接触屏幕）和自然压力波动，软件注入事件（dispatchTouchEvent）的接触面积为 0、压力恒定为 1.0——这是物理层面无法伪造的信号。(4) 证据驱动的可解释判定——每条判定附带"为什么"（如"接触面积中等、压力偏低、速度波动偏高，符合机械臂/物理工具特征"），满足风控的可审计要求。与 反欺诈体系 的行为分析和 设备指纹 的行为生物识别关联。→ GitHub

3. Maharashtra Pride & FraudLens (ajinkyachalke008) — 执法机构 GNN 金融欺诈情报平台（GNN + 集成 ML + Neo4j 知识图谱 + 13 模块 + Section 65B 法庭报告 + Gemini 2.5 Pro）【信号：★★】

ajinkyachalke008/maharashtra-pride（1★, React + TypeScript + FastAPI + Python + Neo4j）是一个双用途平台：面向公众的马哈拉施特拉邦警察致敬页面 + 面向浦那警察网络犯罪部门的 FraudLens 金融欺诈情报仪表盘。FraudLens 将碎片化证据源（银行流水、截图、聊天记录、交易日志、情报报告）转化为统一调查情报图谱，暴露犯罪团伙、骡子网络、洗钱链条和组织化网络欺诈。

核心管道：原始证据→AI 提取→图谱智能→风险分析→法律映射→法庭可采信报告。13 个专业情报模块覆盖证据提取、图谱构建、团伙检测、风险评分、BNS 2023 法律条款映射、Section 65B 合规报告生成。技术栈：React + TypeScript + Vite 前端，FastAPI + Python 后端，Neo4j 图数据库，Gemini 2.5 Pro LLM 驱动证据提取和分析，NetworkX 图算法。

工程亮点：(1) 163 commits + 完整测试套件（tests/e2e/）+ CI/CD（.github/workflows/）——非空壳项目；(2) 真实案例数据——case_study_investment_scam.csv 提供投资诈骗案例研究；(3) Docker Compose 一键部署；(4) Lovable AI 脚手架生成——项目通过 Lovable AI 初始化（.AJJU 为原 .lovable 目录），但后续有大量手工开发。

风控视角：执法机构视角的欺诈调查平台，补充了企业风控缺失的"调查→起诉"闭环：(1) 证据到图谱的自动化转换——传统欺诈调查需要分析师手动整理银行流水、聊天记录，FraudLens 用 LLM 自动提取实体和关系构建知识图谱，加速调查。(2) Section 65B 法庭报告自动化——印度证据法 Section 65B 要求电子证据有认证声明才能在法庭采信，自动化生成合规报告缩短了从检测到起诉的周期。(3) BNS 2023 法律映射——将检测结果映射到具体法律条款（Bharatiya Nyaya Sanhita 2023），让风控发现直接关联到法律追诉依据。(4) 诚实评估——项目带有致敬页面的展示性质，FraudLens 是真实代码但深度待验证，LLM 证据提取的准确性需实测。与 反洗钱-AML 的调查协同和 风控模型 的 GNN 图检测关联。→ GitHub

4. FraudShield (evanc-hane) — 生产级支付欺诈检测（梯度提升 + 类权重 + PSI 漂移监控 + FastAPI 版本化 API + Prometheus + 决策阈值优化）【信号：★★】

evanc-hane/fraud-shield（1★, Python 3.11+）是一个面向生产的支付欺诈检测系统，将原始交易信号转化为校准的风险决策，通过版本化 FastAPI 端点提供服务，并实时监控特征分布漂移。README 诚实标注"Portfolio project only"，数据为合成数据。

技术栈分层清晰：数据层（可复现生成器，非线性不平衡欺诈模式）→ 特征层（交易 velocity、金额比率、账户年龄、行为信号）→ 模型层（Histogram 梯度提升 + 类权重）→ 评估层（PR-AUC/ROC-AUC/recall/precision/F1/FPR）→ 服务层（类型化 FastAPI 评分 API + 显式 approve/review/block 决策）→ 监控层（滚动 PSI + Prometheus metrics）→ 交付层（测试 + linting + Docker + GitHub Actions）。

工程亮点：(1) 决策阈值在验证集上优化——在 minimum-recall 约束下选择阈值（优先召回率，有意增加人工复核和误报），然后只在分层 holdout 上报告最终指标一次，避免数据泄露；(2) PSI（Population Stability Index）漂移监控——滚动窗口计算特征分布稳定性指数，检测生产环境特征漂移（如欺诈模式变化导致模型性能下降），是 MLOps 的核心监控指标；(3) 合成数据上的诚实评估——10,000 笔交易（3.78% 欺诈率），PR-AUC 0.2541（是随机基线的 6.7 倍），明确声明"合成性能用于回归测试管道，不代表真实欺诈检测质量"。

风控视角：这个项目展示了"欺诈检测系统的标准 MLOps 实践"：(1) PR-AUC vs ROC-AUC 的不平衡数据直觉——在 3.78% 欺诈率下，ROC-AUC 0.82 看起来不错但 PR-AUC 仅 0.25，说明在不平衡数据上 ROC-AUC 会高估性能，PR-AUC 更能反映欺诈检测的实际效果。(2) minimum-recall 约束的阈值选择——风控系统宁可多人工复核（高召回）也不漏掉欺诈（低召回=损失），这种"召回优先"的阈值策略是支付风控的标准实践。(3) PSI 漂移监控的工程价值——欺诈模式不断进化（攻击者适应防御），模型上线后特征分布会漂移，PSI 提供量化预警机制决定何时重训练。(4) approve/review/block 三级决策——不是二元（欺诈/正常）而是三级分诊，review 队列让人工分析师聚焦边界案例，是规则+ML 混合架构的体现。与 实时风控引擎 的决策引擎和 风控模型 的模型监控关联。→ GitHub

5. Clinical Data ETL (ksdisch) — 医保索赔欺诈检测 ETL 管道（Medicare 4 表 + dbt 三星模型 + Prefect 编排 + pandera 验证 + PostgreSQL）【信号：★★】

ksdisch/clinical-data-etl（1★, Python + dbt + Prefect + PostgreSQL）是一个多源临床数据 ETL 管道，摄取三个异构医疗数据集——Medicare 索赔欺诈检测（4 张关联 CSV 表）、UCI 糖尿病再入院住院记录、合成住院记录（住院时长）——用 pandera 验证、PostgreSQL 暂存、dbt 转换为三个独立星型模型、Prefect 编排。定位为数据工程/分析工程项目。

架构完整：data/raw/claims_fraud/（Train+Test Beneficiary/Inpatient/Outpatient Claims/Provider Labels CSV）→ Python 摄取（pandera 逐表 schema 验证 + Train/Test 合并为单表 + Test provider 可空欺诈标签）→ PostgreSQL raw schema（4 张原始表）→ dbt 转换（staging→intermediate→marts 三层）→ 三个独立星型模型（claims fraud + diabetes readmission + length-of-stay）。

Medicare 欺诈星型模型：dim_beneficiary（受益人：年龄/性别/种族/州县/11 种慢性病/住院报销总额）+ fct_claims（索赔事实表：claim 类型/持续时间/报销金额/10 个诊断码/6 个手术码）+ dim_provider（医疗机构：is_potential_fraud 标签/总索赔数/总报销额）。

工程亮点：(1) pandera schema 验证在摄入层——每张表的字段类型、范围、缺失值在写入 PostgreSQL 前验证，防止脏数据污染下游；(2) dbt staging→intermediate→marts 三层转换——staging 做类型清洗、intermediate 做业务逻辑（如统一 inpatient+outpatient 索赔）、marts 做维度建模，是 analytics engineering 的标准实践；(3) Prefect 编排可观测性——每个 ETL 步骤有 Prefect 任务追踪，失败可重试；(4) CI 流水线（.github/workflows/ci.yml）。

风控视角：医保欺诈的数据工程基础——欺诈检测的前提是干净、结构化的数据：(1) 医保欺诈的核心信号在 provider 维度——dim_provider 的 is_potential_fraud 标签是监管机构（如 OIG）标注的，欺诈模式通常体现在 provider 层面（upcoding、空壳网络、虚假账单），而非单笔索赔。(2) 星型模型让欺诈分析变得自然——dim_provider + fct_claims 的星型结构让"某 provider 的索赔模式与同类 provider 的偏差"这种分析变成简单的 SQL 聚合。(3) Train/Test 合并 + 可空标签的设计——将 Train（有标签）和 Test（无标签）合并为单表，Test provider 的欺诈标签设为 NULL，这是 Kaggle 竞赛式数据集的正确工程处理——既可用于监督学习（Train 部分），也可用于无监督异常检测（全部数据）。与 反欺诈体系 的医保欺诈和 风控数据架构 的数据管道关联。→ GitHub

6. Crypto Portfolio Risk Analyzer (canyildizted2-cloud) — 浏览器端加密货币组合风险引擎（CoinGecko 基本面评分 + DeFiLlama 黑客检查 + DEX 流动性 + 托管审计 + 严重度惩罚）【信号：★ · ⚠️ 空仓库仅 README】

canyildizted2-cloud/Crypto_portfolio_risk_analyzer（0★, Vanilla JS，浏览器端运行）声称是一个完全在浏览器中运行的加密货币组合风险分析引擎，无需后端、无需 API key、无数据收集。注意：验证发现仓库仅有 .gitignore + LICENSE + README.md 三个文件，README 中引用的 analyzer.html、js/coin_analyzer.js、js/custody_analyzer.js、js/alerts.js 均不存在——为设计阶段/概念项目。

声称的两阶段评分架构：(1) Phase 1——项目年龄、市值排名、开发者活跃度（GitHub commits/stars）、价格波动信号；(2) Phase 2——代币经济学分析、DEX 流动性检查、持有人分布启发式。配合托管审计（Ledger/Trezor 硬件钱包 + MetaMask/Phantom 软件钱包 + Binance/Coinby 交易所风险评估，交叉引用 DeFiLlama Hacks 数据库）和严重度惩罚系统（Critical -3 / Warning -2 / Info -1，覆盖零 BTC 敞口、极端山寨币主导、低稳定币储备、托管集中、严重回撤）。

风控视角：加密货币组合风险的概念框架值得理解（但项目无实现）：(1) "严重度惩罚"vs"加权评分"的范式区别——传统组合风险用加权评分（各维度分值×权重求和），本项目用扣分制（从满分开始按严重度扣减），扣分制让"致命风险"（如托管集中 -3）的影响更直观。(2) 托管安全审计的前瞻性——加密货币的"托管风险"（交易所被黑客攻击/跑路）是传统金融不存在的独特风险维度，将交易所的 DeFiLlama Hacks 记录纳入风险评分是有价值的实践。(3) 浏览器端运行的隐私优势——无后端意味着用户组合数据不离开设备，但 API 调用（CoinGecko/DeFiLlama）仍会暴露查询行为。⚠️ 因仓库无实现代码（仅 README），仅作为"加密货币组合风险分析"方向的信号追踪。与 风控模型 的市场风险方法论关联。→ GitHub

技术趋势

行业案例

值得深入

  1. Nebula 2.0 的四层模型与自研风控引擎的对比——Event→Variable→Strategy→Notice 的分层是否适用于我们的风控归因 Agent 项目？253 个统计变量中哪些可以直接复用？
  2. gesture-fingerprint 的接触面积/压力维度在 Web 端的可行性——移动端有原生触摸事件 API，Web 端的 Pointer Events 是否能获取足够的压力和接触面积数据？
  3. FraudShield 的 PSI 漂移监控阈值设定——PSI<0.1 稳定、0.1-0.25 轻微漂移、>0.25 显著漂移的标准是否适用于我们的欺诈检测场景？