1. 课程导入

课程导入 学习卡片

一、业务背景：为什么反洗钱监测离不开“交易行为分析”

反洗钱（AML）不是单纯的风控合规动作，而是金融机构必须持续履行的法定义务。它的核心目标，是识别并报告可疑交易，防止金融体系被用于洗钱、恐怖融资、逃税、诈骗资金转移等违法活动。在实际业务中，反洗钱监测主要依赖三类数据：客户身份信息（KYC）、账户信息、交易流水。其中，交易流水是动态行为最直接、最丰富、也最难处理的证据来源。

传统监测方式通常依赖固定规则，例如“单笔金额超过5万元”“当日累计现金存入超过20万元”“短期内频繁与高风险地区交易”。这些规则有效，但存在明显局限：一是容易被拆分交易规避；二是无法识别复杂链路；三是误报率高，导致人工审核成本居高不下。因此，现代反洗钱监测越来越强调基于时间序列和交易行为的模式识别，例如：

  • 同一客户在短时间内是否出现“分散转入、集中转出”；
  • 账户是否在沉寂很久后突然发生大额高频交易；
  • 多个账户是否在同一时间窗口内与同一对手方发生近似金额交易；
  • 客户交易金额是否明显偏离其历史均值或同类客户分布。

这些问题的共同点是：需要把“当前这笔交易”放回客户的历史交易序列中比较。SQL窗口函数正是解决这类“组内排序、滑动聚合、前后对比、同组排名”问题的高效工具。

二、监管要求：从“规则合规”走向“风险为本”

国内外监管框架均要求金融机构建立与自身风险状况相匹配的反洗钱监测体系。以我国为例，《反洗钱法》《金融机构反洗钱规定》《法人金融机构洗钱和恐怖融资风险管理指引》等文件，强调“风险为本”原则，要求机构对客户、业务、地域进行风险分类，并对高风险情形采取强化审查措施。同时，监管机构对可疑交易报告的质量、时效和留痕提出明确要求。

这意味着，反洗钱监测不能只停留在“命中规则就上报”，而需要：

  1. 可解释：为什么这笔交易可疑？是金额异常、频率异常，还是对手方异常？
  2. 可追溯：监测逻辑、参数、数据版本、执行时间必须可审计。
  3. 可量化：风险评分、阈值、窗口长度应有依据，并能持续调优。
  4. 可扩展：面对海量交易数据，监测方案要能稳定运行并支持增量计算。

SQL窗口函数的价值在于，它能在不改变原始交易明细粒度的前提下，为每笔交易附加“上下文指标”，例如“该客户近7天交易笔数”“该笔金额在客户历史中的百分位”“与上一笔交易的时间间隔”。这些指标既可作为规则条件，也可作为风险评分特征，直接提升监测的精准度和可解释性。

核心定位：窗口函数不是替代反洗钱规则，而是把“单笔静态判断”升级为“序列动态判断”。它让SQL从“筛选数据”变成“计算行为特征”。

三、SQL窗口函数在反洗钱监测中的价值定位

窗口函数（Window Function）在SQL中用于对一组与当前行相关的行进行计算，但不会像GROUP BY那样把多行合并为一行。它通过OVER(PARTITION BY ... ORDER BY ...)定义窗口，常见能力包括：

能力类别 典型函数 反洗钱监测场景
组内排序 ROW_NUMBER、RANK、DENSE_RANK 识别客户第1笔、最近1笔、金额排名前3的交易
滑动聚合 SUM、COUNT、AVG、MAX、MIN + OVER 近7天累计交易金额、近30天交易笔数、当日最大单笔
前后对比 LAG、LEAD 与上一笔交易时间差、金额变化率、对手方是否切换
分布定位 NTILE、PERCENT_RANK、CUME_DIST 判断当前金额是否处于客户历史高位或同类客户极端分位
首尾取值 FIRST_VALUE、LAST_VALUE 客户首次交易时间、最近一次交易对手方

与自连接、子查询相比，窗口函数通常更简洁、更易读，且在多数数据库中能获得更好的执行计划。对于反洗钱这种需要“按客户、按账户、按时间窗口”反复计算特征的场景，窗口函数是SQL层面最值得优先掌握的能力之一。

四、案例场景：一个典型的“拆分交易”监测思路

假设某客户在3天内向同一对手方转账多笔，每笔金额都略低于5万元上报阈值。单看每一笔都不触发规则，但合起来可能构成规避行为。使用窗口函数，可以快速计算：

SELECT
  customer_id,
  counterparty_id,
  txn_time,
  amount,
  SUM(amount) OVER (
    PARTITION BY customer_id, counterparty_id
    ORDER BY txn_time
    ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
  ) AS rolling_3_txn_sum,
  COUNT(*) OVER (
    PARTITION BY customer_id, counterparty_id
    ORDER BY txn_time
    ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
  ) AS rolling_3_txn_cnt
FROM aml_transactions
WHERE txn_time >= DATE '2024-01-01'
  AND txn_time < DATE '2024-01-04';

这段SQL为每笔交易附加了“最近3笔累计金额”和“最近3笔笔数”。如果rolling_3_txn_sum接近或超过阈值，而单笔均未超过，就形成了可解释的可疑线索。后续章节会进一步加入时间间隔、对手方集中度、历史基线等维度。

学习路径建议：先掌握窗口函数语法与执行逻辑，再理解反洗钱监测的典型模式（拆分、集中、快进快出、沉睡唤醒、循环转账），最后把模式翻译成可落地的SQL特征工程与评分规则。

五、常见误区与复盘

  • 误区一：把窗口函数当GROUP BY用。窗口函数保留明细行，GROUP BY会折叠行。反洗钱监测通常需要保留每笔交易，因此窗口函数更合适。
  • 误区二：忽略窗口帧。ROWS BETWEEN ...与RANGE BETWEEN ...语义不同，时间窗口计算必须明确边界，否则结果可能不符合业务预期。
  • 误区三：只算金额，不看时间。反洗钱中“时间间隔”往往比金额更关键，LAG/LEAD应尽早纳入特征体系。
  • 误区四：参数写死。阈值、窗口长度、分位点应配置化，便于监管变化或风险偏好调整时快速迭代。
  • 误区五：忽视数据质量。时间戳时区、金额币种、对手方缺失都会直接影响窗口计算结果，监测前必须做数据校验。

复盘来看，窗口函数在反洗钱交易监测中的真正价值，不是“写得更炫”，而是把业务上模糊的“行为异常”转化为可计算、可审计、可复用的SQL特征。掌握这一能力后，你就能在合规、风控、审计、数据治理等多个岗位场景中，用更少的代码表达更复杂的交易行为逻辑。

← 上一章 📖 返回目录 下一章 →