风控日报 — 2026-09-14

📊 筛选总结

  • 原料：39 条入文件 — GitHub 仓库搜索 39；arXiv 12 条候选/HN/Trending 均未通过相关性过滤进入原料（连续第二日单渠道）
  • arXiv：12 条候选全部无关，无一进入原料（相关性过滤拦截）；全噪声连续 46 期（07-17→09-14），累计约 906 条中 2 条相关，噪声率 99.8%，drop-all 默认维持
  • 剔除 · 已覆盖/重复 13 条：sentinel-upi[08-17 收录/09-09 专题]、AEGIS-SWARM[09-13 ★★★]、athena-aml[09-13]、azeri_laverie[09-12]、phaas-tracker[08-15]、veriguard[09-11 采]、warden-desk[09-05]、quantcore[07-07 首现残留]、aiia-demo[08-12 采]、TemporalStore[09-05 剔]、FlashSale=tannillium/SybilShield 更名[06-15]、portfolio-risk[投资域外]、weiwen-law-dsh[08-27]
  • 剔除 · 恶意残留 4 个（已确认不重复验证，累计维持 29 个）：defi-risk-screening[07-26]、Para99999/payment-fraud-detector[07-26]、yoelpa6680/upi-fraud-gnn[07-26]、gilangcowokull/SnifTern.ai[07-26]；Infrai astroturf 第 8 例今日现形（沉寂 2 日后重启，见威胁情报专题）
  • 剔除 · 域外/过薄 8 条：api-evangelist×2 厂商档案 stub（pagar-me/incandor）、CodeStalker 网安游戏化教学、summeca-meme-radar 币圈扫描、phase 桌游规则引擎[274★ 与风控无关]、MyThingsLab/my-guard 通用 ACL、TSEC-GRC 落地页、rules-engine-template 第 3 代退役仓[由 rules-kernel 三仓专题替代收录]
  • 筛出：7 条工程高信号 + 1 条威胁情报专题
  • 主题一 · 负结果写进 README：TypologyDesk 把数据集 artifact 审计与"本系统不能检测洗钱"声明置于指标之前，评估诚实度从报告层蔓延到 README 信息架构层
  • 主题二 · 规则引擎的"核/厂分离"：rules-kernel 把确定性契约（replay identity/provenance/unresolved-result）做成被引用而非被复制的原语库，退役仓的"死因复盘"是罕见的工程失败教学样本
  • 威胁情报双信号：Infrai astroturf 第 8 例现形（复制重启）；Zen7/TRDGNN 同一 3 分钟窗口内协调刷新 README（载荷零变化）——既非弃号亦非轮换的新生命周期状态

今日高信号

1. Shiva-data101/TypologyDesk — AML 排序的 artifact 审计：先声明生成器缺陷、再报指标（面向 AML 分析师 triage 的账户排序台（IBM AML HI-Small）：README 主体不是功能介绍而是数据集两处 artifact 的审计——① 9 月 10 日后稀疏尾：2022-09-11 后交易仅占账本 0.02%（1,108/5,078,345）却占全部洗钱交易的 12.7%，该尾段出现的每个账户都是正样本（716 个测试正样本 100% 命名模式账户）= 生成器 pattern-completion 流量而非有机活动，可按构造分离，artifact-free 列将其剔除；② 币种-模式绑定：≥4 种币种的账户在验证集 100% 正样本——真实银行数据不存在此性质，是生成器给 pattern wire 打标的方式，HGB 排序器在该池内重排故继承同一 artifact；结果双口径：artifact-free 测试集 k=50 上 HGB 与冻结的单列币种规则不可区分（14 vs 9 hits，bootstrap 区间重叠），全排序 2.9×（PR-AUC 0.0367 vs 0.0125）；"What this is not"声明段：本系统不能检测洗钱、未在真实银行数据上验证、排序优势来自合成生成器的币种信号）【信号：★★★】

Shiva-data101/TypologyDesk（0★, Python, 09-07 建→09-13 推送, 59KB, 无 license）src/docs/artifacts 分层，artifacts/stage5.json 支撑全部数字，requirements.lock 固定依赖。验证无恶意模式；README 2.4KB 但信息密度极高（每个声明都指向 artifact 文件）。

风控视角："评估即证据链"弧线在 IBM AML 数据上的 artifact 审计落点——此谱系记录过 Vignesh 的三类泄漏分类学[09-09]、jeganathan 的 PaySim 完美指标反面教材[09-09]、ring-faith 的图解释零假设[09-13]，TypologyDesk 补上"合成数据的生成器 artifact 必须先审计后读数"这一环：两个 artifact 的处理方式（可分离性论证→剔除列→继承性声明）是可复制的三步纪律。k=50 无差异+全排序 2.9× 的双口径+bootstrap 区间报告是排序类任务的正确姿势——单点指标会按叙事需要二选一。对照反面对照锚点：同样是 IBM AML/HI 族数据，jeganathan 报 PR-AUC 0.999 不提 artifact，TypologyDesk 的天花板是 0.0367——诚实评估的指标量级通常"更难看"。⚠️ 单一合成数据、无 license、Windows x86-64 + CPython 3.11 的环境约束较窄。与 风控模型 的评估纪律直接相关。→ GitHub

2. brandonifco/rules-kernel + rules-factory + rules-engine-template — 规则引擎的"核/厂分离"：确定性契约做成被引用的原语库，退役仓留死因复盘（三仓同日架构重组：① rules-kernel——规则集无关的确定性原语：replay identity（同规则版本+同 pinned corpus 基线+同初始状态+同有序决策→同结果序列，任意机器任意运行可复放）、provenance 可校验、replay-stable 生成器（PCG32）、"无法解析时显式说不能"的 unresolved-result 契约（调用方必须处理）；已发布 NuGet 0.2.0，9 项检查+105 个针对检查本身的测试；② rules-factory——把平语规则集变成引擎的"工厂"方法论（corpus+domain pack+identity→带 provenance 的引擎仓），设计先行（docs/method.md+corpus-map.md，17KB，尚无实现代码）；③ rules-engine-template（第 3 代）正式退役，README 完整复盘死因：模板=复制后分叉，两个引擎各自长出自己的随机源与复放身份、修正无法互相到达；4/8 不变量检查检查了"只有产物引擎才存在的文件"→空转报 PASS——"一个检查什么都没检查时必须说出口，且退出码要说"；61 处引用不存在的文件（含运行时错误消息里的）——"引用即承诺"；结论：copied foundation cannot be fixed once → kernel 被引用而非被复制，修正经版本号到达所有引擎）【信号：★★★（模式价值）】

brandonifco/rules-kernel / rules-factory / rules-engine-template（均 0★, Python/C# 混合工程, 全部 09-13 当日创建/重组, Apache-2.0）kernel 198KB 完整 .NET 工程（src/tests/probes/docs 全件套），factory 17KB 设计文档仓，template 225KB archived 保留历史与 closed issues。验证无恶意模式。

风控视角：规则引擎工程化的少见深度样本，三个可迁移件：其一，replay identity 是规则引擎审计/回归的核心契约——"同规则版本+同规则文件基线+同输入→同决策序列"正是国内规则引擎平台版本管理与争议回放的技术本质，这里被做成了带哈希基线的显式原语（对照 实时风控引擎 的决策审计需求）。其二，"引用而非复制"的核/厂分离是规则集资产化的架构论证：修正一次、全平台到达——对照规则平台常见的"每业务线复制一套规则模板然后各自漂移"的病。其三，退役仓的死因复盘本身是工程决策记录文化的示范——"检查空转报 PASS"“引用即承诺"两条教训直接适用于风控规则平台的质量门设计（检查项引用的规则文件不存在时必须 fail 而非 skip）。⚠️ 0★ 单人仓、从桌游/法规语料起家非风控专用、factory 仅设计文档、"引擎"产物（deckard/SRD_Combat）在第三方仓未核。与 风控策略 的规则治理和 实时风控引擎 的审计回放直接相关。→ rules-kernel、rules-factory、rules-engine-template（退役复盘）

3. ksuk/merlon — 日本非银机构的自托管 AML/CFT 合规平台：CDD 评分+交易监控一体机（面向日本非银金融机构（crypto 资产交易所/资金移动业者）的 AML/CFT 合规软件：CDD（客户尽调）评分与 TM（交易监控）一体化——api/（Go：Customer/Transaction/Case/Report 四服务+原生评分/TM/筛选引擎）+ ui/（TypeScript+React 运营台）+ PostgreSQL 主库/Redis 可选缓存；配置驱动模型声称可跨法域（银行等机构按本地法规自配）；BSL 1.1 source-available 授权——Additional Use Grant 允许自托管生产使用、禁止对其提供托管/嵌入式第三方服务，样例内容 Apache-2.0；工程件套齐整：docs/decisions ADR 决策记录（如 0003-bsl-license-choice）、CHANGELOG/CONTRIBUTING/MAINTAINERS/SECURITY/CODE_OF_CONDUCT、.gitleaksignore、Makefile+docker compose Quick Start）【信号：★★】

ksuk/merlon（0★, Go, 07-20 建→09-13 推送, 5.2MB, BSL-1.1[NOASSERTION]）API/UI/adapters/config 分层完整，7 月至今持续演进。验证无恶意模式；README 8.2KB 架构图+授权边界清晰。

风控视角：区域性 AML 合规产品的完整工程参考——本库 AML 样本多为 pipeline/评分器（athena-aml[09-13] SaaS 骨架、TypologyDesk 排序台、azeri_laverie 取证教学[09-12]），merlon 是第一个"CDD 评分+TM+案件+报告"的一体化合规产品形态，且瞄准真实监管生态位（日本资金移动业/ crypto 交易所的 AML/CFT 义务）。两个取用点：① BSL 1.1 的授权边界设计（生产自用开放/托管转售禁止）是合规软件商业化的 License 样本——对照国内"反诈能力输出给城商行/消金"路径的授权模式选择；② docs/decisions 的 ADR 文化（把 license 选择写成编号决策记录）适合规则引擎平台做规则变更管理借鉴。⚠️ 0★、BSL 条款需读原文（Additional Use Grant 的边界）、检测模型/规则深度未核、与日本监管细项（inoisie group 对应的vectory screening 等）的符合度待验证。与 反欺诈体系 的 AML 章节相关。→ GitHub

4. jeffparulan/fraud-forged-ai — 6 节点可审计 LangGraph 欺诈流水线：LLM 出分、独立规则引擎交叉验证（开源 GenAI 欺诈检测平台（营销口径"替代 $2M+/年 BPM"）：6 节点可审计 LangGraph 流水线——route→MCP enrich→RAG→LLM cross-validation→post-score guardrails→explanation，每个 verdict 返回完整决策 trace（含每节点延迟）；LLM 分数被独立规则引擎交叉验证，post-score 护栏：OFAC 地理/高 RAG 相似度/MCP 链上标志可升级处置等级；两段式医疗理赔管线：本地 MedGemma（Mac Mini）先验证临床合法性→Nemotron-Super 再评欺诈——"临床审查与欺诈审查分离"镜像真实理赔流程；成本护栏：预算告警接 kill switch+Cloud Run scale-to-zero；Terraform+GCP 部署+CI）【信号：★★】

jeffparulan/fraud-forged-ai（1★, Python, 2025-12 建→09-13 推送, 1.9MB, MIT）backend/frontend/infrastructure 分层+docker-compose+run-local.sh+ARCHITECTURE/DEPLOYMENT/TESTING 文档。验证无恶意模式；README 14.3KB（徽章+营销体量声明下有真实架构细节）。

风控视角："LLM 出分、确定性终审"治理线的平台化落点——AEGIS-SWARM[09-13] 用确定性 Policy Gate 裁决、sentinel-fraud-detection[09-13] 干脆零 AI 路径，FraudForge 走中间路线：LLM 评分保留但必须过独立规则引擎交叉验证+后置护栏才能生效——三种形态合成"LLM 决策权收敛"的完整光谱。另两个补位：① 两段式理赔（临床合法性≠欺诈性，分开审）是理赔/审贷流程拆分的可迁移模式——对照国内医保基金的"诊疗合规审查 vs 骗保识别"双层结构；② 成本护栏（kill switch+scale-to-zero+预算告警）是 LLM 风控生产化讨论中少见的运维缺环补位。⚠️ 营销级成本声明（$2M+/95%+）不可验证、"auditable"深度=trace 完整性未逐节点核、MCP enrich 的真实数据源未核。与 风控归因 Agent 项目 的证据链 schema 和 支付风控 的 GenAI 治理相关。→ GitHub

5. moksh033/Guardian — 执法侧风控：报案数据预测 ATM 取现地点+钱骡识别，抢 2-6 小时拦截窗口（SIH 2026 参赛（SIH26184 网络犯罪投诉预测分析框架）：问题定义——NCRP（国家网络犯罪举报门户）报案后，犯罪分子典型在 2-6 小时内经钱骡网络取现，执法需在窗口内干预；三个输出：① Spatio-Temporal Transformer 预测 ATM 取现地点（自报 >85% 精度）；② GNN 识别交易网络中的钱骡账户（自报 >90%）；③ 混合评分（GNN 70%+规则 30%）+ATM Step-Up 验证处置建议，供执法前置拦截；36MB 团队仓：alembic/api/apps 全栈+DESIGN/IMPLEMENTATION_PLAN+MEMBER-1~4 分工文件）【信号：★★】

moksh033/Guardian（0★, Python, 09-13 当日新建, 36MB, 无 license）SIH（Smart India Hackathon）参赛仓，README 7KB 架构图完整，.env 在库（⚠️ 需注意但无密钥模式命中）。验证无恶意模式。

风控视角："报案数据→拦截窗口"的执法侧风控样本——本库 30+ 检测样本全部在"交易瞬间"做 ALLOW/BLOCK 决策，Guardian 的价值在把风控输出接到执法响应链：损失已发生后预测取现地点+前置 Step-Up 干预，"2-6 小时"是本库第一个量化的损失挽回时间窗。与 team-UNECom[09-12]（支付后游戏内价值漂洗）互证：风控视野正从交易瞬间向"支付之后"延伸。混合评分的权重口径（GNN 70/规则 30）虽朴素，但"预测类输出+规则类输出融合后给处置建议"的结构与国内公安机关的反诈资金流拦截实践同构。⚠️ hackathon 属性、精度声明无验证口径、NCRP 真实数据的合法可得性存疑、无 license。与 反欺诈体系 的资金链拦截相关。→ GitHub

6. youseifsamirshabaan/credit-card-fraud-detection — Kafka+Spark 流式欺诈检测的全家桶教学管道（端到端实时欺诈检测大数据架构：Python producer 回放交易 CSV→Kafka（transactions_raw）→Spark Structured Streaming（清洗+特征工程+MLlib 模型推理）→三路落存（HDFS 预测/PostgreSQL 预测/Kafka 预测回传）→Superset 监控台+Airflow 编排+docker compose 一键起；README 12.6KB 以 ASCII 架构图完整走线）【信号：★】

youseifsamirshabaan/credit-card-fraud-detection（0★, Python, 09-07 建→09-13 推送, 159KB, 无 license）producer/kafka/spark/hadoop/postgres-dw/airflow/superset/jupyter/docs 全目录在位。验证无恶意模式。

风控视角：Lambda 式实时管道的完整教学参考——本库实时计算栈样本以 Redis Streams/FastAPI（sentinel-upi）与 Postgres 队列（athena-aml）为主，Spark Structured Streaming 侧第一次补位；"推理结果三路落存"（批存储/服务查询/流回传）直接对应国内实时风控的双写需求。教学价值在于组件间契约完整（每段管道的输入输出 schema 可从 docker compose 追）。⚠️ 教学体量、CSV 回放非真实流、MLlib 模型层深度未核、无 license。与 实时风控引擎 的流计算章节相关。→ GitHub

7. Payal-Gaikwad-15/AI-BizScore — 小企业信贷的"运营参数替代征信"轻量评分（小企业健康与信贷风险引擎：6 项运营输入（月营收/运营成本/总负债/客户流失率/业主征信分/逾期应收）→健康分+风险评级+KPI+风险驱动解释+行动建议；Streamlit 部署 live demo，模型 pkl 在库）【信号：★】

Payal-Gaikwad-15/AI-BizScore-Small-Business-Health-Credit-Risk-Engine（0★, Jupyter, 09-12 建→09-13 推送, 2.7MB, 无 license）单 notebook+app.py+模型文件，README 5.7KB。验证无恶意模式；live demo 链接在 README（未复测连通）。

风控视角："企业运营健康"替代"业主征信"的轻量样本——核心论点（业主征信好≠企业经营健康：高成本/高负债/高流失/逾期应收都能单独击穿）与国内税票贷/流水贷的"经营流水反欺诈"同构；评分输出带风险驱动+行动建议是"评分可解释→客户可操作"的少见闭环（多数评分器止步于分数）。⚠️ 样本自建（Small_Business.csv 来源未注明）、模型指标未报告、单 notebook 体量。与 风控策略 的小微信贷场景相关。→ GitHub

8. 威胁情报专题 — Infrai astroturf 第 8 例现形（沉寂 2 日后重启）+ zip 家族"协调触碰"：Zen7/TRDGNN 同一 3 分钟窗口刷新 README、载荷零变化（① Infrai 第 8 例：VortexM81/fintech-document-risk-service——三件套指纹齐活：README 快速上手段第一行即 export INFRAI_API_KEY="your-key"+root 含 llms.txt+"pulls its weight"营销句式+README 仅 11 行的极短模板；采集流自 09-02 起持续出现该仓（09-03/09-08 raw 均有），今日指纹确认——第 7 例[09-11]后沉寂 2 日重启复制，节奏突变 +1；② zip 家族第 6 日：Zen7-Payment-Agent 与 TRDGNN 在 09-13 05:32Z/05:35Z（相差 3 分钟，同一操作会话）先后 "Update README.md"——README 模板仍为下载页、三个 zip 载荷路径与字节数零变化（Sapharensian/Zen_Payment_Agent_v1.7.zip 584,580B+Zen7-Payment-Agent.zip 1,394,759B+TRDGNN configs/Software-v1.4.zip 587,686B 全部 HTTP 200+同尺寸），两仓上一条 commit 均为 2026-02-19——这是 TRDGNN 约 7 个月来首次活动；既非弃号亦非轮换，是协调触碰（疑似维持仓库活跃度/家族握手信号）；③ sulemanyou/card-detection-fraud-credit 维持整仓 404（下架态未变）。累计恶意仓 29 个不变；Infrai 8 例单列计数）【信号：★★★（威胁情报）】

验证实录（主会话 Python urllib/HTTP API）：VortexM81 README 原文逐行核对（INFRAI_API_KEY+llms.txt+营销句式三项命中）；Zen7/TRDGNN commits API 确认 3 分钟双推送+前次活动 2026-02-19；三 zip HEAD 探活 200/content-length 与 09-10→09-13 记录逐字节一致。风控视角：两个新数据点。其一，astroturf 复制是脉冲式而非线性（09-08 两例→09-11 一例→沉寂 2 日→今日重启）——"连续 N 日 0 新增即战役结束"的判断过早，观察窗口维持"节奏突变告警"。其二，协调触碰是 zip 家族第 4 个生命周期状态（下架/轮换/静置之后）：payload 不动、README 元数据刷新，最合理的解释是维持搜索活跃度——GitHub 关键词搜索结果排序受最近推送影响，刷新让恶意仓持续浮在 fraud/AML 关键词搜索前列（本采集流每日捞到它们即证据）。推论：采集流的"已确认恶意残留"清单需要按 pushed_at 重新监控而非一次性拉黑——触碰事件本身即威胁情报。已链接仓库名仅作威胁情报引用、永不作技术引用。→ Zen7-Payment-Agent、TRDGNN、fintech-document-risk-service（Infrai 第 8 例，勿用）

技术趋势

  • 负结果与 artifact 写进 README 主叙事：TypologyDesk 把生成器 artifact 审计（稀疏尾/币种绑定）+artifact-free 双口径+bootstrap 区间+"本系统不能检测洗钱"声明段做成 README 主体——评估诚实度从论文/报告层蔓延到仓库信息架构层，与 ring-faith[09-13] 的零假设校正、"Nothing here is runnable yet"[09-13 sentinel] 同一条"主动披露边界"线。
  • 规则引擎的核/厂分离：rules-kernel 把 replay identity/provenance/unresolved-result 做成被引用而非被复制的原语库，"修正经版本号到达所有引擎"——规则集资产化的架构论证第一次见到完整表述；退役仓的死因复盘（空转 PASS/引用即承诺）是质量门设计的正反教材。
  • "LLM 出分、确定性终审"成为 GenAI 风控平台标准件：FraudForge 的独立规则引擎交叉验证+post-score 护栏、AEGIS-SWARM[09-13] 的零 LLM 策略门、athena-aml[09-13] 的无 key 确定性 fallback——三种实现同构，LLM 决策权收敛已从论文议题变成赛道默认。
  • 风控视野持续后移：Guardian 把检测输出接到执法拦截窗口（报案→ATM 预测→2-6h），与 team-UNECom[09-12] 的支付后资金流追踪互证——"支付之后"正在从个别样本变成方向。
  • 威胁情报：astroturf 复制脉冲式重启（第 8 例）；zip 家族出现第 4 种生命周期状态"协调触碰"（payload 零变化+README 同会话刷新，疑似维持搜索活跃度）——恶意仓监控需从"一次性拉黑"改为"持续观察 pushed_at 事件"。

行业案例

  • 日本非银 AML/CFT（merlon）：crypto 交易所/资金移动业的自托管合规一体机，BSL 1.1 授权边界设计。
  • 印度网络犯罪执法侧（SIH Guardian）：NCRP 报案→ATM 取现预测+钱骥识别→2-6 小时窗口拦截。
  • 美国医保理赔两段式（FraudForge）：MedGemma 临床合法性审查与 Nemotron 欺诈评分分离——"临床合规≠非欺诈"。
  • AML 分析师 triage 台（TypologyDesk）：IBM AML HI-Small 上的排序台+artifact 审计方法论。
  • 小微信贷经营健康评分（AI BizScore）：运营参数替代征信的轻量闭环（评分→风险驱动→行动建议）。

值得深入

  • TypologyDesk 的 artifacts/stage5.json：bootstrap 区间的具体方法与 artifact-free 列的精确定义；IBM HI-Small 的 named-pattern 账户机制与已发表文献的对照。
  • rules-kernel 的 unresolved-result contract：风控规则引擎能否引入显式"无法裁决"第四态（对照 allow/warn/review/block 的封闭集）——kernel 的调用方强制处理契约是现成设计。
  • FraudForge 的 MCP enrich：实际调用的链上/账户数据源是什么，与 AEGIS-SWARM 的 MCP 调查层同类——两仓对照可回答"agent 化调查"的最小可行数据面。
  • Guardian 的 NCRP 数据可得性：印度报案数据的合法接入路径（公开 API/合作研究）决定该样本是概念还是可复现系统。