📚 课程目录第3章告警数据解析

3. 告警数据解析

反洗钱告警去重、合并与实体聚合的第一步，不是写规则，而是把告警数据“读懂”。如果字段语义不清、关联关系断裂、时间与金额口径不一致，后续所有去重与聚合都会建立在错误前提上。本章聚焦告警数据的解析层，围绕字段结构、交易流水与客户信息关联、时间窗口与金额阈值、数据质量常见问题四个模块展开。

一、核心原理：告警不是孤立记录，而是“事件+主体+证据”的三元组

一条反洗钱告警在业务上通常表达为：某个主体（客户/账户/商户）在某个时间窗口内，因某组交易触发了某条规则。因此，解析的目标是把原始告警还原为可计算的三元组：

主体维度：客户号、账户号、证件号、商户号、受益所有人等，用于实体聚合。
事件维度：规则编号、规则名称、告警时间、风险等级、触发条件，用于去重与合并。
证据维度：交易流水号、交易时间、金额、币种、对手方、渠道，用于验证与合并依据。

只有把这三类信息拆开并建立稳定关联，才能回答“两条告警是不是同一件事”“多个告警是否指向同一实体”这两个核心问题。

二、告警字段结构：分层解析与标准化

实际系统中，告警数据常来自规则引擎、名单系统、人工上报等多个来源，字段命名和嵌套方式差异很大。建议按“标识层—规则层—主体层—证据层—状态层”五层解析：

层级	典型字段	解析要点
标识层	alert_id、source_system、batch_no	全局唯一性、来源可追溯、批次可重放
规则层	rule_code、rule_name、risk_level、trigger_time	规则版本、阈值参数、触发时间口径
主体层	customer_id、account_no、id_number、merchant_id	主键选择、空值处理、多主体归属
证据层	txn_id、txn_time、amount、currency、counterparty	交易粒度、币种折算、时间对齐
状态层	status、assignee、close_time、conclusion	去重时是否保留历史状态、合并优先级

解析时建议统一输出为扁平化结构，便于后续计算。例如：

{
  "alert_id": "A20240517001",
  "source_system": "AML_RULE_ENGINE",
  "rule_code": "R_STR_001",
  "risk_level": "HIGH",
  "trigger_time": "2024-05-17T10:23:00+08:00",
  "customer_id": "C10086",
  "account_no": "622202****1234",
  "txn_list": [
    {"txn_id": "T001", "txn_time": "2024-05-17T09:10:00+08:00", "amount": 98000, "currency": "CNY"},
    {"txn_id": "T002", "txn_time": "2024-05-17T09:40:00+08:00", "amount": 97000, "currency": "CNY"}
  ]
}

解析阶段不要急于做业务判断，先保证字段可追溯、类型正确、时区统一。很多“去重失败”其实源于解析阶段把不同口径的字段混在一起。

三、交易流水与客户信息关联：建立稳定主键与关联路径

告警中的交易流水与客户信息往往分散在不同表或不同系统。关联的核心是确定“以谁为主键”。常见做法有三种：

以客户号为主键：适合实体聚合，但同一客户多账户时需展开账户维度。
以账户号为主键：适合交易级去重，但账户变更、销户会影响连续性。
以证件号为主键：适合跨账户、跨机构实体识别，但需处理证件变更与空值。

推荐采用“客户号+账户号+证件号”组合键，并建立映射表。关联时注意：

交易流水中的对手方信息可能只有名称，需要与客户信息表做模糊匹配或名单映射。
同一交易可能同时出现在多条告警中，需用 txn_id 去重，而不是用告警 ID。
客户信息存在历史版本，关联时应取告警触发时间点附近的快照，避免“用今天的信息解释昨天的交易”。

常见误区：直接用客户名称关联。名称存在同名、别名、简称、空格与全半角差异，容易造成错误合并。应优先使用证件号、客户号等强标识，名称仅作为辅助校验。

四、时间窗口与金额阈值：口径统一是去重合并的前提

时间窗口和金额阈值是告警触发的核心参数，也是去重合并时最容易产生歧义的地方。解析时必须明确以下口径：

时间基准：使用交易时间、记账时间还是告警触发时间？三者可能相差数小时甚至跨日。
时区：跨境交易需统一为 UTC 或业务所在时区，避免窗口错位。
窗口类型：滑动窗口、滚动窗口还是自然日窗口？不同窗口下同一组交易可能触发不同告警。
金额口径：单笔金额、累计金额、折人民币金额还是原币金额？是否包含手续费？
阈值方向：大于、大于等于、区间内，边界值处理必须一致。

例如，某规则为“同一客户 24 小时内累计交易金额≥20 万元”，解析时应输出：

window_type: SLIDING
window_size: 24h
time_basis: txn_time
amount_basis: CNY_CONVERTED
threshold_op: GTE
threshold_value: 200000

只有把这些参数结构化，后续去重时才能判断两条告警是否“同窗口、同阈值、同主体”。

五、数据质量常见问题与复盘清单

数据质量问题往往不是单点错误，而是连锁反应。以下清单可用于解析后的质量校验：

问题类型	典型表现	处理建议
空值	customer_id 为空、txn_id 缺失	标记为不可聚合，进入人工复核队列
重复	同一 txn_id 出现在多条告警	按 txn_id 去重，保留最早触发告警
时间异常	交易时间晚于告警时间、跨时区未转换	统一时区，校验时间顺序
金额异常	负数、超大值、币种缺失	按币种折算，设置合理区间过滤
关联断裂	账户号无法匹配客户信息	建立映射表，保留未匹配记录

复盘建议：每次去重合并前，先跑一遍数据质量报告，统计空值率、重复率、时间异常率和关联成功率。这些指标比告警数量更能反映数据是否可用。

综上，告警数据解析不是简单的字段映射，而是为去重、合并与实体聚合建立统一语义基础。字段结构决定可计算性，关联路径决定聚合粒度，时间与金额口径决定去重边界，数据质量决定最终结果的可信度。把这四件事做扎实，后续的告警压缩与实体聚合才有稳定前提。