一名项目完整性分析师在 5 月 12 日发文，整理了六类用于交易欺诈识别的 SQL 查询模式。

这篇文章有个很实在的提醒：反欺诈并不总是从复杂模型开始。很多时候，第一步还是查交易表。谁在短时间内刷了太多次，哪两笔交易的地理位置不合理，哪个商户突然冒出异常尖峰，这些问题，用 SQL 就能很快捞出来。

但也正因为太快，风险也在这里。

SQL 命中的交易，看起来像异常，不等于已经坐实欺诈。原文也明确说明，示例基于通用交易表和虚构场景，不来自真实个案，也不代表其雇主数据或立场。这一点要放在前面讲清楚。

SQL 仍在一线，因为它便宜、快、可解释

过去几年，反欺诈叙事常被机器学习、图模型和实时决策引擎占满。真实工作里，很多分析仍从交易日志开始。

原因不复杂。交易数据天然适合 SQL：有用户、有商户、有金额、有时间、有地点。再加上连接、聚合、窗口函数，就能把很多异常形态显出来。

原文提到的六类模式，可以压成这张表：

SQL 模式核心信号使用边界
短时高频同一账户、卡片或设备在短时间内交易次数异常高适合发现试卡、盗刷线索，但会误伤批量采购、集中补单
不可实现旅行两笔交易地点相距很远，时间间隔短到无法完成移动信号较强，但速度阈值只是示例，不能机械套用
特定金额反复出现小额测试，或贴近审核门槛的金额更适合识别试探性交易，不适合所有支付场景
商户异常峰值某商户短时出现异常多独立卡、账户或交易金额必须看商户规模和历史波动，小店和大卖场不能同一把尺
个人消费时段偏离用户交易时间明显偏离过去习惯对老用户更有用，对新账户或低频用户效果弱
窗口函数派生特征用 LAG、ROW_NUMBER、滚动求和等生成组合信号能提高分析效率，但会增加数据仓库计算成本

这些模式的共同点，是把“看起来不正常”变成可查询条件。

比如短时高频本身不够。一个用户十分钟内多次支付，可能是盗刷，也可能只是分单下单。可如果它同时伴随小额测试、异常地理跳跃、非惯常时段消费，判断就更接近高置信风险。

这也是 SQL 的位置：它不是判决书，更像筛网。

阈值不是标准答案，基线才是工作量

原文里的 10 次、600 mph、3 倍基线这类数字，只能当示例起点。它们不是行业标准。

一家大型超市一小时内出现几十张不同银行卡，可能很正常。一家平时客流很低的小店，突然出现同样形态，就需要看一眼。周末午间的餐饮高峰，也不能拿周二凌晨的交易量做参照。

规则风控和模型风控的差别，就在这里。

模型会把很多变量压进一个分数。SQL 规则则把判断摊开：时间窗口多长，阈值多高，历史基线取多久，是否按商户规模分层，是否区分新老用户。

摊开是好事。分析师能解释，运营和审核团队也能追溯。但代价也很明确：每个阈值都要调，每个业务都要校准。

对数据分析师来说，照抄查询不是最重要的动作。更现实的做法是三件事：

  • 按业务线、商户规模、用户新老程度拆基线，不要用一个全局阈值打全场。
  • 把规则命中结果做成审核队列，而不是直接封禁或拒付。
  • 每周回看误报和漏报，把阈值往回调，而不是只盯命中数量。

对风控负责人来说，采购或上线新工具时也要看这一点：系统能不能支持规则解释、人工复核和反馈回写。只报一个“风险分”，但说不清哪些信号叠加出来，落地时会很难用。

真正的限制在误伤、成本和数据边界

SQL 规则最容易被低估的，不是写法，而是运行代价。

原文提到一个很具体的工程建议：跑窗口函数前，先限制日期范围。这个提醒不花哨，但很重要。对 Snowflake、BigQuery、Databricks 这类云数仓来说，在全量多年交易上直接跑 LAG、滚动求和或排序窗口，账单可能比规则更先失控。

隐私也是硬边界。交易数据常包含身份、位置、设备和消费习惯。反欺诈目标正当，不代表可以绕过数据使用规范。更稳的流程，是先用脱敏数据或限定样本验证规则，再在授权范围内接入生产数据。

还有一个常见误区：把命中当成成果。

命中多，不一定抓得准。规则太宽，会把正常用户送进审核队列；规则太紧，又会漏掉真正风险。审核人力有限时，误报本身就是成本。

接下来最该看的，不是某个阈值能不能“一把抓准”。而是团队有没有形成闭环：规则命中、人工复核、误报标注、阈值回调、白名单维护、组合信号评分。

单一规则只能产生线索。多个信号叠加，再经过历史基线和人工复核，才更接近高置信欺诈判断。

这篇文章的价值就在这里。它没有把 SQL 包装成机器学习替代品，也没有把规则说成万能答案。它只是提醒反欺诈团队：别嫌老工具土，也别把老工具当神。

筛网可以拦住泥沙，但不能替法官定罪。