📚 课程目录第2章数据采集层

二、数据采集层：交易数据来源与实时性要求

数据采集层是可疑交易推理链条的起点，决定了后续特征提取、规则命中与模型推理的质量上限。本节从数据来源、采集规范与实时性三个维度展开，帮助学员建立从原始交易日志到结构化分析数据的全链路认知。

2.1 交易数据来源全景

反洗钱系统需要覆盖三类核心数据源：银行、支付机构与虚拟资产。每类数据源在交易结构、字段标准与合规要求上存在显著差异。

数据源类型	典型机构	核心交易类型	数据量级（日均）	合规监管主体
银行	商业银行、政策性银行	转账、汇款、跨境支付、定期存取	百万～千万笔	央行、银保监会
支付机构	支付宝、微信支付、银联	扫码支付、网关支付、代收代付	千万～亿级	央行支付结算司
虚拟资产	交易所、钱包服务商	链上转账、OTC 交易、DeFi 交互	百万～千万笔	FATF、各地金融监管局

  关键认知： 银行数据以结构化交易流水为主，支付机构数据包含丰富的设备指纹与行为上下文，虚拟资产数据则依赖链上公开账本与 KYC 关联映射。三类数据必须统一清洗后才能进入同一推理管道。

2.2 数据采集规范

采集规范决定了数据质量的下限。反洗钱系统必须遵循以下四项核心规范：

字段完整性规范：交易时间、交易双方标识（账号/地址）、金额、币种、IP、设备 ID 为必采字段，缺失率不得超过 0.1%。
格式标准化规范：时间统一为 ISO 8601（UTC+8），金额以最小货币单位（分/satoshi）存储，地址类字段做脱敏哈希。
数据血缘规范：每笔交易必须携带来源系统标识、采集时间戳与批次号，支持全链路溯源。
隐私合规规范：涉及个人敏感信息（姓名、身份证号）需在采集层完成 AES-256 加密或 token 化，日志中禁止明文存储。

// 数据采集层标准化 JSON 示例（银行转账）
{
  "tx_id": "TXN2025032112345678",
  "source_system": "BANK_CORE_CSH",
  "collect_timestamp": "2025-03-21T14:30:00.000+08:00",
  "tx_time": "2025-03-21T14:29:55.000+08:00",
  "sender": {
    "account_hash": "a1b2c3d4e5f6...",
    "account_type": "SAVINGS",
    "bank_code": "ICBC"
  },
  "receiver": {
    "account_hash": "f7e8d9c0b1a2...",
    "account_type": "CHECKING",
    "bank_code": "CCB"
  },
  "amount": 50000000,
  "currency": "CNY",
  "ip_address": "192.168.1.100",
  "device_id": "DEVICE_ABC123",
  "batch_no": "BATCH_20250321_01"
}

2.3 实时性要求与分层策略

不同可疑交易场景对数据时效性的要求差异巨大。反洗钱系统通常采用三级实时性分层策略：

T+0 准实时（秒级～分钟级）：用于拦截类场景，如跨境大额拆分、新账户异常快进快出。要求数据从交易发生到进入推理引擎延迟 ≤ 30 秒。
T+1 近线（小时级）：用于团伙挖掘、账户关联图谱构建。允许批量采集窗口为 1～4 小时，侧重数据完整性而非绝对时效。
T+7 离线（天级）：用于回溯分析、模型训练与监管报表。数据经过全量校验与补录，延迟不超过 7 个自然日。

实战建议： 银行核心系统通常只支持 T+1 批量接口，准实时数据需通过旁路日志采集（如 Kafka 监听数据库变更日志 CDC）实现。虚拟资产链上数据则可通过 WebSocket 订阅 mempool 达到秒级延迟。

2.4 采集链路中的常见陷阱

⚠️ 避坑清单：

时间戳漂移：银行核心系统与支付网关时间不同步，导致交易顺序错乱。必须统一使用 NTP 服务器时间，并在采集层记录采集时间与交易时间两个字段。
重复数据：CDC 日志在故障恢复时可能重复推送同一笔交易。需要在采集管道中引入幂等去重机制（基于 tx_id + 批次号）。
字段截断：部分老旧系统对备注、IP 等字段长度有限制，导致关键信息丢失。采集前需做字段长度预检与告警。
虚拟资产地址误关联：同一用户可能使用多个链上地址，仅靠地址无法关联。必须结合 KYC 映射表与链上行为聚类进行实体对齐。

2.5 采集层输出物与下游接口

经过清洗与标准化后的数据，以统一消息格式写入 Kafka 或 Pulsar 主题，供下游特征工程与规则引擎消费。典型输出主题包括：

主题名称	数据内容	分区策略	保留周期
`aml_tx_instant`	准实时交易流水（T+0）	按 sender_hash 哈希分区	7 天
`aml_tx_nearline`	近线批量交易（T+1）	按时间窗口分区	30 天
`aml_tx_offline`	离线全量交易（T+7）	按日期分区	180 天
`aml_entity_mapping`	实体对齐映射表（地址→用户）	按 entity_id 哈希分区	永久（增量更新）

数据采集层输出的每一个消息都必须包含 schema 版本号，以便下游消费者在字段变更时自动兼容。建议使用 Avro 或 Protobuf 作为序列化格式，配合 Schema Registry 实现契约化管理。