大学生数据库实践课：金融反欺诈风控分析

本期播客

大学生数据库实践课：金融反欺诈风控分析

同学们好，欢迎来到《大学生数据库实践课》图数据库专题的最后一站：19.3 讲。如果说前两讲我们是在“交朋友”和“查机票”，那么这一讲我们就要进入最硬核、商业价值也最高的领域——金融反欺诈风控。

在金融圈，犯罪分子的手段极其隐蔽。他们不会直接从 A 转账到 B，而是通过几十个中间账户洗钱，或者利用复杂的交叉担保来骗取贷款。面对这种“天罗地网”，传统的 SQL 查询就像是在用放大镜找细菌，而 DuckPGQ 则是直接给数据库装上了“X光机”。

一、 为什么金融风控是图数据库的“主战场”？

金融数据的本质是关联。一个账户本身没问题，但如果它所有的资金都流向了黑名单账户，那它就有问题。

• 背景：我们有账户（Account）、人（Person）、公司（Company）、贷款（Loan）等实体，以及转账（Transfer）、担保（Guarantee）、投资（Invest）等关系。
• 挑战：识别“洗钱路径”或“循环担保”需要多层穿透。用 SQL Join，三层关系就能让查询速度慢如蜗牛；用 PGQ，几层关系只是几个箭头的距离。

二、 实战案例：用图式思维“破案”

我准备了两个具有代表性的风控查询：

1. 追踪“黑钱”：锁定资金分发中心

MATCH (src:Account where src.accountId = 166...)  
      <-[e1:transfer]-(mid:Account)  
      -[e2:transfer]->(dst:Account where dst.isBlocked = true)  

• 德哥点评：看这个 <-...- 和 -...-> 的组合。它描述了一个非常典型的洗钱模式：中间账户 mid 同时向源账户和黑名单账户转账。通过这种“分叉式”匹配，我们能瞬间揪出隐藏在背后的资金中转站。

2. 精准防控：时空维度的异常过滤

MATCH (src:Account)-[e:Transfer]->(dst:Account)  
WHERE e.amount > 4829783 AND e.createtime BETWEEN '...' AND '...'  

• 德哥点评：这展示了图数据库对边属性（Edge Properties） 的处理能力。我们不仅在找关系，还在筛选关系。在海量交易流水中，只有同时满足“大额”和“特定时间窗口”的转账才会被我们的风控引擎“点名”。

三、 德哥的“破案三问”：进阶挑战

想成为风控专家？先试着回答这三个问题：

1. 【架构思维】：在 FinBench 模型中，为什么 CompanyInvestCompany 和 PersonInvestCompany 要分开定义？如果我要查“某家公司背后的最终受益人（穿透 5 层股权）”，图数据库比 SQL 强在哪里？
2. 【闭环检测】：金融风控中最怕“循环担保”（A给B担保，B给C担，C又给A担）。你能试着写一个 MATCH 模式，找出这种能让银行系统瞬间崩溃的“死亡环路”吗？
3. 【团伙识别】：很多骗子会用不同的身份登录同一个 App。如果我们把 Medium（登录设备）也连进图里，如何通过“共享设备”把看似无关的几个账户关联成一个欺诈团伙？

四、 德哥的实践心得：公益是一辈子的事，学习也是

1. 从“表”到“图”的进化：学习图数据库，最难的不是语法，而是转换思维。要学会用“路径”和“模式”去思考业务，而不是“行列”和“过滤”。
2. SQL 依然是你的好搭档：大家发现了吗？我们所有的图查询最后还是嵌套在 SQL 里。这就是 DuckPGQ 的魅力——它让你在不改变使用习惯的前提下，获得了处理复杂关系的能力。
3. 实践出真知：FinBench 是工业级的测试集。我建议同学们一定要动手运行一下那些循环路径查询，感受一下那种“一眼看穿复杂关联”的爽快感。

图数据库专题到此告一段落。 我们从社交、航空一路走到了金融风控，相信大家已经领略到了 SQL:PGQ 标准的力量。

如果你对“循环担保”的 SQL 写法有灵感，或者在配置 DuckPGQ 环境时遇到了坑，欢迎随时在 Github 或微信找我交流。数据库的世界很大，我们一起探索！

详细教程, 点击「阅读原文」