信贷场景建模：客户-设备-联系人图谱构建
做信贷风控这些年，我最大的感触就是——单点看人，永远看不全。
你想想看，一个客户提交的资料再漂亮，征信报告再干净，你能保证他没有在别的平台借过钱？你能保证他填的联系人不是随便编的？
嗯，这就是传统风控的盲区。而图计算，恰恰能补上这块短板。
为什么需要客户-设备-联系人图谱？
说白了，我们要把「人」放到「关系网」里去看。
一个客户可能很老实，但他如果跟一群逾期老哥共用同一台设备，或者他的紧急联系人全是黑名单用户——你觉得他还安全吗？
我在项目中遇到过这样一个案例：有个客户征信评分挺高，但图模型一跑，发现他的设备ID跟三个逾期用户完全重合。后来一查，是个团伙作案的中介。嗯，单看征信根本发现不了。
图谱的核心要素
构建图谱，我们需要三类节点和三类边：
| 节点类型 | 属性示例 | 边类型 | 含义 |
|---|---|---|---|
| 客户（Person） | 身份证号、手机号、姓名 | 客户-设备 | 该客户使用过某设备 |
| 设备（Device） | IMEI、MAC地址、设备型号 | 客户-联系人 | 该客户填写的联系人 |
| 联系人（Contact） | 手机号、姓名、关系 | 设备-设备 | 设备间共享关系（如WiFi） |
我建议你特别注意设备节点。为什么？因为设备是团伙欺诈的「聚集地」。一个设备上注册过10个客户，这本身就是一个危险信号。
图谱构建的代码实现
这里我用Neo4j举个例子。我个人习惯用Cypher来建图，清晰又直观：
// 创建客户节点
CREATE (p:Person {
id: 'P001',
name: '张三',
id_card: '110101199001011234',
credit_score: 680
})
// 创建设备节点
CREATE (d:Device {
imei: '356938035643809',
device_model: 'iPhone 12',
first_seen: '2024-01-15'
})
// 创建联系人节点
CREATE (c:Contact {
phone: '13800138000',
relation: '配偶'
})
// 建立关系
MATCH (p:Person {id: 'P001'})
MATCH (d:Device {imei: '356938035643809'})
CREATE (p)-[:USED_DEVICE {timestamp: '2024-01-15'}]->(d)
MATCH (p:Person {id: 'P001'})
MATCH (c:Contact {phone: '13800138000'})
CREATE (p)-[:HAS_CONTACT]->(c)
这段代码看着简单，但实际生产环境里，数据量一上来，建图速度就是个大问题。我曾经在几千万节点的图上跑批量导入，结果跑了整整两天……后来改用批量CSV导入加索引优化，才把时间压到小时级。
图谱构建的避坑指南
我的做法是：建立一个设备指纹归一化表，把IMEI、IDFA、MAC地址、设备型号+系统版本组合成一个hash值，作为设备的唯一标识。
多头借贷关系建模
多头借贷，说白了就是一个人同时在多个平台借钱。这本身不违法，但借得太多，还款能力肯定跟不上。
传统做法是查征信报告，看近3个月查询次数。但征信报告有滞后性，而且有些小贷平台不上征信。这时候，图模型就派上用场了。
多头借贷的图模式
我们来看一个典型的「多头借贷」子图：
// 查询某个客户的多头借贷情况
MATCH (p:Person {id: 'P001'})-[r:APPLIED]->(l:LoanPlatform)
RETURN p.name, l.name, r.apply_time, r.amount
ORDER BY r.apply_time DESC
如果这个客户关联了超过5个贷款平台，而且申请时间集中在3天内——嗯，这基本就是多头借贷的典型特征。
多头借贷的量化指标
我建议你关注这几个指标：
- 平台数：客户关联的贷款平台数量，超过3个算预警
- 申请密度：单位时间内的申请次数，比如1天内申请5次
- 共债比例：客户在多个平台的总借款额 / 客户收入
- 平台重叠度：两个客户共同使用的平台数量，用于发现团伙
实战经验：我在某消费金融公司做过一个模型，把「平台数」和「申请密度」作为图特征输入XGBoost，AUC从0.72直接提到了0.81。说白了，图特征比传统特征好使多了。
多头借贷的图算法应用
这里我常用的是标签传播算法（LPA）。为什么？因为多头借贷的客户往往有相似的借贷行为模式，LPA可以自动把这些人聚类到一起。
// Neo4j GDS 中的标签传播
CALL gds.labelPropagation.write({
nodeProjection: 'Person',
relationshipProjection: {
SHARED_PLATFORM: {
type: 'SHARED_PLATFORM',
orientation: 'UNDIRECTED',
aggregation: 'SINGLE'
}
},
writeProperty: 'community'
})
跑完之后，每个客户都会被打上一个「社区标签」。如果某个社区里逾期率超过30%，那这个社区的新客户就得格外小心了。
担保圈识别
担保圈，是信贷领域的老大难问题。
你想想看，A给B担保，B给C担保，C又给A担保——表面上每个人都有担保人，实际上风险全在圈内循环。一旦一个人出问题，整个圈子就崩了。
我记得2012年长三角的互保圈危机，就是典型的担保圈暴雷。嗯，图计算就是用来提前发现这种圈子的。
担保圈的图模式
担保关系本质上是一个有向图：A担保B，就是A→B的一条边。如果存在A→B→C→A这样的环，那就是一个担保圈。
小技巧：担保圈不一定是简单的三角形。实际业务中，我见过几十个节点组成的大环，还有「领带结」结构的复杂担保圈。用肉眼根本看不出来，必须上算法。
担保圈检测算法
检测担保圈，核心就是找强连通分量（SCC）。一个强连通分量里的节点，任意两个都能互相到达——这就是一个担保圈。
// 使用 Neo4j GDS 检测强连通分量
CALL gds.alpha.scc.write({
nodeProjection: 'Company',
relationshipProjection: {
GUARANTEE: {
type: 'GUARANTEE',
orientation: 'NATURAL'
}
},
writeProperty: 'scc'
})
跑完之后，每个公司都会得到一个scc编号。同一个编号的公司，就属于同一个担保圈。
担保圈的风险分级
不是所有担保圈都要一棍子打死。我一般按以下标准分级：
| 风险等级 | 判定标准 | 处理建议 |
|---|---|---|
| 低风险 | 圈内节点≤3，且所有企业正常经营 | 正常审批，但需关注 |
| 中风险 | 圈内节点4-10，或有1-2家经营异常 | 提高担保要求，或要求解圈 |
| 高风险 | 圈内节点>10，或存在逾期企业 | 直接拒贷，或要求全额抵押 |
我曾经犯过一个错：只检测了直接担保环，忽略了间接担保关系。比如A担保B，B担保C，A和C虽然没有直接担保关系，但A实际上承担了C的间接风险。后来我改用可达性分析，把间接担保也纳入考量，才真正把风险兜住。
担保圈的可视化
光有算法还不够，你得能看得见。我习惯用SVG画担保圈的关系图，这样业务同事一眼就能看懂。
你看这张图，A担保B，B担保C，C又担保A。表面上每个人都有担保，实际上风险全在圈子里打转。一旦A出问题，B和C都得跟着遭殃。
担保圈的实际应用
在信贷审批中，我一般这样用担保圈检测结果：
- 准入过滤：高风险担保圈内的企业，直接拒绝准入
- 额度调整：中风险圈内的企业，降低授信额度20%-50%
- 担保要求：要求圈内企业提供额外的抵押物或第三方担保
- 动态监控：对已放款的担保圈企业，提高监控频率，一旦出现逾期立即预警
说句实在话：担保圈检测这件事，不做图计算之前，我们靠人工排查，一个月能查100家企业就不错了。上了图算法之后，一天能跑完10万家。效率提升的不是一星半点。
好了，以上就是信贷场景建模的三个核心方向。客户-设备-联系人图谱是基础，多头借贷建模是风险识别，担保圈识别是风险传导。三者结合起来，才能构建一个完整的信贷风控图体系。
公众号:蓝海资料掘金营，微信deep3321