2. 数据源与数据采集:内部数据、外部数据与三方数据合规

在风险控制评分沙盘中,特征工程的第一步并非算法或模型,而是数据源的识别与采集。数据的广度、深度与质量直接决定了评分卡的上限。本章将系统梳理风控建模中常见的三类数据源:内部数据、外部数据与三方数据,并重点讨论数据接入的合规红线。

2.1 数据源分类全景

风控数据源可按数据归属与获取方式分为三大类,其核心特征对比如下:

数据类别 典型数据 获取成本 数据稳定性 合规敏感度
内部数据 交易流水、用户行为日志、账户信息 低(自有系统) 高 中(需用户授权)
外部数据 人行征信、百行征信、黑名单库 中(按查询计费) 中 高(强监管)
三方数据 运营商数据、电商数据、社保公积金 高(商务合作) 低(依赖合作方) 极高(数据安全法)
特征工程视角: 内部数据是建模的“基本盘”,外部数据是“增强器”,三方数据是“差异化变量”。优先清洗内部数据,再按需引入外部与三方数据,避免过度依赖高成本数据源。

2.2 内部数据:交易与行为

内部数据是风控建模最可靠、最可控的数据来源。通常来自企业自有的核心系统、APP 埋点与日志服务器。

2.2.1 交易数据

  • 交易流水: 金额、时间、渠道、对手方、交易类型(消费/转账/提现)。
  • 账户余额: 日均余额、时点余额、余额波动率。
  • 交易频次: 日交易笔数、月交易笔数、夜间交易占比。

2.2.2 行为数据

  • 登录行为: 登录频次、登录时段、登录设备指纹。
  • 页面浏览: 停留时长、点击路径、功能使用深度。
  • 信息修改: 手机号/地址/密码修改频率,常为欺诈信号。
实战案例: 某消费金融平台发现,用户在申请日前 7 天内频繁修改绑定手机号且登录 IP 跨省,该行为特征在反欺诈模型中 IV(信息价值)达到 0.45,成为拒绝规则的核心变量。

2.3 外部数据:征信与黑名单

外部数据主要用于补充内部数据无法覆盖的信用历史与风险暴露信息。

2.3.1 征信数据

  • 人行征信: 信贷记录、逾期历史、查询次数、担保信息。
  • 百行/朴道征信: 互联网信贷、消费金融、租赁等替代数据。
  • 关键特征: 最大逾期天数、近 6 个月查询次数、信贷账户数。

2.3.2 黑名单数据

  • 内部黑名单: 历史逾期、欺诈确认、羊毛党标记。
  • 行业黑名单: 法院失信被执行人、网贷黑名单共享库。
  • 设备黑名单: 设备 ID 关联多个逾期账户、模拟器设备指纹。
合规红线: 征信数据必须通过持牌征信机构查询,严禁私自采集或买卖个人信用信息。黑名单共享需遵循“最小必要”原则,且需在用户协议中明确告知。

2.4 三方数据源接入与合规

三方数据源(如运营商、电商、社保、公积金)能提供丰富的替代信用特征,但接入流程复杂,合规风险最高。

2.4.1 常见三方数据源

数据源类型 典型特征 建模用途
运营商 在网时长、月消费金额、通话对象数 身份稳定性、社交关系
电商 消费等级、退货率、收货地址稳定性 消费能力、行为偏好
社保/公积金 缴纳基数、缴纳单位、连续缴纳月数 收入稳定性、职业真实性
多头借贷 近 7 天申请平台数、近 30 天放款机构数 共债风险、资金紧张度

2.4.2 接入合规流程

  1. 数据源准入评估: 数据源方资质(营业执照、数据安全认证)、数据来源合法性。
  2. 用户授权协议: 明确告知采集范围、用途、存储期限,获得单独同意。
  3. 数据脱敏与加密: 传输过程使用 HTTPS + 国密算法,存储时对身份证、手机号等敏感字段脱敏。
  4. 接口限流与监控: 设置 QPS 上限,记录每次查询日志,定期审计。
  5. 数据销毁机制: 用户注销或授权到期后,及时删除或匿名化处理。
工程建议: 三方数据接入建议采用“统一网关”模式,所有外部数据请求经过网关路由、鉴权、计费与熔断,避免各业务线直连数据源导致管理混乱。

2.5 数据采集架构示意

下图展示了一个典型的风控数据采集架构,涵盖内部数据、外部数据与三方数据的接入路径:

风控数据采集架构图 风控数据采集架构 内部数据源 交易系统 / 行为日志 账户信息 / 埋点数据 外部数据源 人行征信 / 百行征信 黑名单 / 多头借贷 三方数据源 运营商 / 电商 / 社保 公积金 / 设备指纹 数据采集网关 鉴权 / 限流 / 脱敏 / 路由 数据清洗与标准化 缺失值 / 异常值 / 格式统一 特征存储(Hive / ClickHouse) 合规要点 用户授权 → 最小必要 加密传输 → 定期审计

2.6 数据质量评估清单

在特征工程启动前,必须对采集到的数据进行质量评估。以下为常用评估维度:

评估维度 指标 合格标准 常见问题
完整性 缺失率 < 5% 字段未采集、传输丢包
准确性 异常值占比 < 1% 金额为负、时间戳为未来
一致性 跨系统字段匹配率 > 99% 用户 ID 格式不统一
时效性 数据延迟 < 1 小时(T+0) 批量任务延迟、接口超时
唯一性 重复记录率 < 0.1% 重复采集、主键冲突
实战经验: 某头部消金公司在接入运营商数据时,发现 30% 的用户授权后数据返回为空,原因是 SDK 版本未适配 Android 12 的隐私权限变更。建议在数据采集层增加“数据回执校验”机制,对空返回进行实时告警与重试。

2.7 数据采集代码示例

以下为 Python 伪代码,展示一个简单的数据采集网关核心逻辑:

import requests
import hashlib
import time

class DataCollectionGateway:
    def __init__(self, config):
        self.api_key = config['api_key']
        self.rate_limit = config.get('rate_limit', 100)  # QPS
        self._last_request_time = 0

    def _rate_limiter(self):
        now = time.time()
        if now - self._last_request_time < 1.0 / self.rate_limit:
            time.sleep(1.0 / self.rate_limit - (now - self._last_request_time))
        self._last_request_time = time.time()

    def _mask_sensitive(self, data):
        """对身份证、手机号进行脱敏"""
        if 'id_card' in data:
            data['id_card'] = data['id_card'][:4] + '****' + data['id_card'][-4:]
        if 'phone' in data:
            data['phone'] = data['phone'][:3] + '****' + data['phone'][-4:]
        return data

    def fetch_external_data(self, user_id, data_type):
        self._rate_limiter()
        payload = {
            'user_id': user_id,
            'type': data_type,
            'timestamp': int(time.time()),
            'sign': hashlib.md5(f"{user_id}{data_type}{self.api_key}".encode()).hexdigest()
        }
        # 实际请求外部数据源
        response = requests.post('https://api.external.com/v1/query', json=payload)
        if response.status_code == 200:
            raw_data = response.json()
            return self._mask_sensitive(raw_data)
        else:
            raise Exception(f"数据源返回错误: {response.status_code}")
合规提醒: 上述代码中的 _mask_sensitive 仅为示例,实际生产环境需使用更严格的脱敏算法(如 AES 加密、差分隐私),且脱敏操作应在数据落盘前完成,避免明文在内存中停留过久。

2.8 本章小结

数据源与数据采集是风控评分沙盘的基石。内部数据提供稳定且可控的特征基础,外部数据补充信用与风险维度,三方数据则带来差异化变量但伴随高合规成本。在特征工程实践中,建议遵循以下原则:

  • 先内后外: 优先挖掘内部数据潜力,再按需引入外部数据。
  • 合规前置: 数据采集前完成用户授权、协议签署与安全评估。
  • 质量优先: 建立数据质量监控体系,拒绝“脏数据进、脏特征出”。
  • 架构统一: 通过数据采集网关统一管理所有数据源的接入、鉴权与限流。