2. 反洗钱数据基础:交易数据、客户数据、账户数据、外部黑名单数据的数据结构与常见字段
反洗钱(AML)系统的核心是数据。无论是规则引擎、特征工程还是机器学习模型,其输入都依赖于高质量、结构化的基础数据。本章将系统梳理AML领域四大核心数据源:交易数据、客户数据、账户数据和外部黑名单数据,并详细解析其数据结构与关键字段。
💡 数据质量原则:在AML特征工程中,原始字段的完整性、准确性和时效性直接决定后续特征的有效性。缺失率超过30%的字段通常需要谨慎处理或剔除。
2.1 交易数据(Transaction Data)
交易数据是AML分析的第一手素材,记录了资金流动的完整轨迹。交易数据通常来源于核心银行系统、支付网关、清算系统等。
2.1.1 核心字段结构
| 字段分类 | 字段名称 | 数据类型 | 示例值 | 说明 |
|---|---|---|---|---|
| 交易标识 | transaction_id | VARCHAR(64) | TXN2025030112345678 | 全局唯一交易流水号 |
| 交易时间 | transaction_time | TIMESTAMP | 2025-03-01 14:23:10 | 精确到秒的交易发生时间 |
| 交易金额 | amount | DECIMAL(18,2) | 150000.00 | 交易本币金额 |
| 交易币种 | currency | VARCHAR(3) | CNY | ISO 4217 标准币种代码 |
| 交易类型 | transaction_type | VARCHAR(32) | 转账 | 如:转账、汇款、消费、取现、换汇 |
| 交易渠道 | channel | VARCHAR(32) | 网上银行 | 如:柜面、网银、手机银行、ATM、POS |
| 付款方账号 | payer_account | VARCHAR(32) | 6222021234567890 | 付款方账户标识 |
| 收款方账号 | payee_account | VARCHAR(32) | 6217009876543210 | 收款方账户标识 |
| 付款方客户ID | payer_customer_id | VARCHAR(32) | CUST00012345 | 付款方客户主键 |
| 收款方客户ID | payee_customer_id | VARCHAR(32) | CUST00067890 | 收款方客户主键 |
| 交易状态 | status | VARCHAR(16) | 成功 | 如:成功、失败、待审核、已撤销 |
| 交易IP地址 | ip_address | VARCHAR(45) | 192.168.1.100 | 发起交易的设备IP(IPv4/IPv6) |
| 交易设备指纹 | device_fingerprint | VARCHAR(128) | a1b2c3d4e5f6... | 设备唯一标识(可选) |
2.1.2 交易数据特征工程要点
- 时间序列特征:交易频次、交易间隔、夜间交易占比、节假日交易模式。
- 金额分布特征:单笔金额、累计金额、整数金额占比、接近阈值的金额(如49999元)。
- 对手方网络特征:对手方数量、对手方地域分布、对手方行业分布、循环交易检测。
- 渠道偏好特征:渠道切换频率、非常用渠道交易占比。
📌 实战案例:某银行发现,洗钱分子倾向于在凌晨2:00-5:00通过手机银行进行多笔接近5万元(反洗钱监测阈值)的整数转账。通过构建“夜间整数交易占比”特征,模型召回率提升了12%。
2.2 客户数据(Customer Data)
客户数据是AML分析的身份基础,用于评估客户固有风险等级(KYC)。客户数据通常来源于CRM系统、身份认证系统、风险评级系统。
2.2.1 核心字段结构
| 字段分类 | 字段名称 | 数据类型 | 示例值 | 说明 |
|---|---|---|---|---|
| 客户标识 | customer_id | VARCHAR(32) | CUST00012345 | 客户唯一主键 |
| 客户姓名 | customer_name | VARCHAR(128) | 张三 | 实名认证姓名 |
| 证件类型 | id_type | VARCHAR(16) | 身份证 | 如:身份证、护照、军官证 |
| 证件号码 | id_number | VARCHAR(32) | 110101199001011234 | 脱敏存储,用于身份核验 |
| 国籍/地区 | nationality | VARCHAR(3) | CHN | ISO 3166-1 国家代码 |
| 职业 | occupation | VARCHAR(64) | 企业高管 | 用于评估职业风险 |
| 行业 | industry | VARCHAR(64) | 房地产 | 用于评估行业风险 |
| 客户风险等级 | risk_level | VARCHAR(16) | 高风险 | 低/中/高/极高 |
| 客户开户日期 | open_date | DATE | 2020-06-15 | 首次开户时间 |
| 客户状态 | customer_status | VARCHAR(16) | 正常 | 如:正常、冻结、销户、休眠 |
| 是否政治公众人物 | is_pep | BOOLEAN | FALSE | PEP标识 |
| 联系地址 | address | VARCHAR(256) | 北京市朝阳区... | 常住地址 |
2.2.2 客户数据特征工程要点
- 身份特征:年龄、性别、国籍风险系数、证件有效期剩余天数。
- 职业与行业特征:高风险职业(如珠宝商、古董商)、高风险行业(如赌场、货币兑换)的编码。
- 行为特征:开户时长、信息变更频率、多证件关联检测。
- 关联网络特征:同一地址关联客户数、同一联系电话关联客户数、同一IP关联客户数。
⚠️ 数据隐私合规:客户数据涉及个人隐私,在特征工程中必须遵循数据脱敏、最小化原则。证件号码、手机号等敏感字段在建模阶段应使用哈希或加密处理,严禁明文存储。
2.3 账户数据(Account Data)
账户数据是连接客户与交易的桥梁。一个客户可能拥有多个账户(储蓄、理财、信用卡等),账户数据反映了资金存放和流动的载体属性。
2.3.1 核心字段结构
| 字段分类 | 字段名称 | 数据类型 | 示例值 | 说明 |
|---|---|---|---|---|
| 账户标识 | account_id | VARCHAR(32) | 6222021234567890 | 账户唯一标识 |
| 所属客户ID | customer_id | VARCHAR(32) | CUST00012345 | 账户持有人 |
| 账户类型 | account_type | VARCHAR(32) | 储蓄卡 | 如:储蓄卡、信用卡、理财账户、对公账户 |
| 账户币种 | account_currency | VARCHAR(3) | CNY | 账户本币 |
| 账户余额 | balance | DECIMAL(18,2) | 500000.00 | 当前可用余额 |
| 账户开户日期 | account_open_date | DATE | 2021-03-10 | 账户开立时间 |
| 账户状态 | account_status | VARCHAR(16) | 正常 | 如:正常、冻结、挂失、销户 |
| 账户日均余额 | avg_daily_balance | DECIMAL(18,2) | 320000.00 | 近90天日均余额 |
| 账户交易限额 | daily_limit | DECIMAL(18,2) | 500000.00 | 单日累计交易限额 |
| 开户机构 | branch_code | VARCHAR(16) | BJ001 | 开户网点代码 |
2.3.2 账户数据特征工程要点
- 账户活跃度特征:近30天交易笔数、近30天交易金额、账户休眠天数。
- 资金沉淀特征:余额波动率、大额资金快进快出模式、余额与交易量不匹配检测。
- 账户关联特征:同一客户下账户数量、账户类型多样性、账户间转账频次。
- 账户生命周期特征:账户年龄、近期信息变更(如联系方式、密码重置)次数。
2.4 外部黑名单数据(External Blacklist Data)
外部黑名单数据是AML合规的底线防线,用于筛查交易对手方是否涉及制裁、洗钱、恐怖融资等非法活动。数据来源包括联合国制裁名单、OFAC名单、FATF高风险国家名单、国内监管黑名单等。
2.4.1 核心字段结构
| 字段分类 | 字段名称 | 数据类型 | 示例值 | 说明 |
|---|---|---|---|---|
| 名单标识 | list_id | VARCHAR(64) | UN_SANCTION_2025_001 | 黑名单条目唯一ID |
| 名单类型 | list_type | VARCHAR(32) | 制裁名单 | 如:制裁名单、通缉名单、高风险国家 |
| 匹配实体名称 | entity_name | VARCHAR(256) | John Doe | 个人或机构全名 |
| 匹配实体类型 | entity_type | VARCHAR(16) | 个人 | 个人/机构 |
| 证件类型 | id_type | VARCHAR(16) | 护照 | 匹配使用的证件类型 |
| 证件号码 | id_number | VARCHAR(32) | AB1234567 | 匹配使用的证件号码 |
| 国籍/地区 | nationality | VARCHAR(3) | IRN | 实体国籍 |
| 列入日期 | listed_date | DATE | 2024-06-01 | 被列入黑名单的日期 |
| 名单来源 | source | VARCHAR(64) | UN Security Council | 发布名单的权威机构 |
| 匹配规则 | match_rule | VARCHAR(32) | 精确匹配 | 精确匹配/模糊匹配/拼音匹配 |
| 风险等级 | risk_level | VARCHAR(16) | 极高 | 制裁名单通常为极高风险 |
2.4.2 黑名单匹配特征工程要点
- 匹配结果特征:是否命中黑名单、命中名单数量、命中名单类型分布、最近命中时间。
- 相似度特征:名称相似度分数(Levenshtein距离)、证件号相似度、地址相似度。
- 时间衰减特征:命中时间距今天数,用于评估风险时效性。
- 聚合特征:同一客户/账户历史命中次数、同一对手方命中次数。
📌 实战案例:某支付机构在交易对手方筛查中,发现一个客户名称与OFAC制裁名单中某实体名称的Levenshtein相似度为0.92(阈值0.85)。经人工复核确认是拼音拼写差异导致的误命中,但该特征被纳入模型后,有效降低了人工复核的漏报率。
2.5 四大数据源关系与融合架构
在AML系统中,四大数据源并非孤立存在,而是通过客户ID和账户ID形成关联网络。下图展示了数据源之间的核心关系与融合路径。
2.6 数据融合实践:特征向量构建示例
以下是一个简化的SQL示例,展示如何将四大数据源融合为一条用于模型训练的特征记录:
-- AML特征融合查询示例
SELECT
t.transaction_id,
t.amount,
t.transaction_type,
t.transaction_time,
-- 客户特征
c.risk_level AS customer_risk_level,
c.is_pep,
c.occupation,
-- 账户特征
a.account_type,
a.balance,
a.avg_daily_balance,
-- 黑名单特征
CASE WHEN bl.list_id IS NOT NULL THEN 1 ELSE 0 END AS is_blacklist_hit,
COUNT(bl.list_id) OVER (PARTITION BY t.payer_customer_id) AS blacklist_hit_count,
-- 衍生特征
DATEDIFF(DAY, a.account_open_date, t.transaction_time) AS account_age_days,
CASE WHEN t.amount >= 50000 THEN 1 ELSE 0 END AS is_above_threshold
FROM transaction_data t
LEFT JOIN account_data a ON t.payer_account = a.account_id
LEFT JOIN customer_data c ON a.customer_id = c.customer_id
LEFT JOIN blacklist_data bl ON (
c.customer_name = bl.entity_name
OR c.id_number = bl.id_number
)
WHERE t.transaction_time >= '2025-01-01';
💡 特征工程提示:上述SQL仅展示基础字段拼接。在实际项目中,特征工程通常需要构建窗口聚合(如近7天交易频次)、时间衰减统计、图网络特征等,这些将在后续章节详细展开。
2.7 数据质量检查清单
在开始特征工程之前,建议对四大数据源进行系统性质量检查:
| 检查维度 | 交易数据 | 客户数据 | 账户数据 | 黑名单数据 |
|---|---|---|---|---|
| 完整性 | 交易ID、金额、时间是否必填 | 客户ID、证件号是否必填 | 账户ID、客户ID是否必填 | 实体名称、名单类型是否必填 |
| 唯一性 | 交易ID无重复 | 客户ID无重复 | 账户ID无重复 | 条目ID无重复 |
| 时效性 | 交易时间在合理范围内 | 客户信息更新时间是否最新 | 账户状态是否实时 | 名单更新日期是否在有效期内 |
| 一致性 | 金额与币种匹配 | 证件类型与证件号格式匹配 | 账户余额与交易流水一致 | 实体名称与证件号关联一致 |
| 准确性 | 交易类型枚举值合法 | 国籍代码符合ISO标准 | 账户类型枚举值合法 | 名单来源权威可追溯 |
通过本章的学习,您应能够清晰识别AML四大数据源的核心字段、理解其业务含义,并掌握数据融合的基本方法。这些基础数据能力是后续特征工程和A/B测试实践的基石。