第三章 · 根基| 银行核心业务系统专栏建议阅读时间16 分钟关键词主数据管理、客户关系维护、客户分层运营、风险合规、标签体系一、数据模型之外的能力建设上一篇我们讲了客户信息的数据模型——表怎么建、字段怎么设计、关系怎么关联。但光有数据模型不够CIF 系统还必须具备四大核心能力┌──────────────────────────────────────────┐ │ CIF 系统的四大核心能力 │ │ │ │ ① 主数据管理 — 数据的唯一权威来源 │ │ ② 客户关系维护 — 人与人/企业的关联网络 │ │ ③ 客户分层运营 — 等级与标签驱动的精准服务 │ │ ④ 风险合规管控 — 黑名单/制裁名单/KYC │ └──────────────────────────────────────────┘这四个能力不是可选的锦上添花而是缺一不可的基础能力。二、能力一主数据管理MDM2.1 什么是主数据在银行的数据体系中数据分为很多类型——交易数据、配置数据、日志数据……其中有一类数据特别重要它被多个系统共享、被多条业务线依赖、一旦出错影响面极大。这类数据就叫主数据Master Data。客户信息就是银行最重要的主数据。2.2 主数据管理的核心原则原则一Single Source of Truth唯一真实来源客户数据只能有一个权威版本存放在 CIF 系统中。其他系统不存客户主数据的副本或者说存的只是缓存权威数据永远以 CIF 为准。❌ 错误做法 储蓄系统存一份客户数据 信贷系统存一份客户数据 信用卡系统存一份客户数据 → 三个系统数据不一致 ✅ 正确做法 CIF 系统是唯一权威数据源 储蓄/信贷/信用卡系统只存客户号外键引用 需要客户详情时实时调用 CIF原则二集中维护、分散使用维护权集中在 CIF 系统——开户、修改客户信息、变更状态都通过 CIF 的标准接口使用权分散到各业务系统——查客户、校验证件、取联系人信息通过 CIF 的查询接口原则三变更审计客户信息的每一次修改都必须留下审计记录┌────────────────────────────────────────┐ │ CUST_CHANGE_LOG客户变更日志 │ │ ────────────────────── │ │ log_id 变更流水号 │ │ cust_id 客户号 │ │ field_name 变更字段 │ │ old_value 变更前值 │ │ new_value 变更后值 │ │ change_type 变更类型 │ │ change_time 变更时间 │ │ operator 操作人/操作渠道 │ │ approval_flag 是否需要审批 │ └────────────────────────────────────────┘2.3 唯一性校验的工程实现新建客户时必须做唯一性校验——确保同一个自然人不会创建多个客户号。校验流程 1. 接收开户请求姓名 证件类型 证件号码 │ 2. 查询 CIF证件号是否存在 │ ├── 存在 → 返回已有客户号不开新号 │ └── 不存在 → 创建新客户号 │ ▼ 3. 写入 CIF 4. 返回新客户号难点同一人可能因录入差异被判断为不同人差异类型示例解决方案姓名音近字不同张三 vs 张叁引入相似度算法拼音匹配证件号中有空格110108...1234 vs 110108... 1234标准化清洗后再比对证件号码位数差异15位老身份证 vs 18位新身份证身份证升位规则转换后比对更名原名张三→改名张四以证件号为判断依据而非姓名工程实践唯一性校验不能仅靠精确匹配证件号一模一样还需要引入模糊匹配 人工审核的机制来发现疑似重复。三、能力二客户关系维护3.1 关系的类型客户之间的关系远比想象中复杂。在 CIF 系统中需要管理以下几类关系┌──────────────────────────────────────────────────┐ │ 客户关系图谱 │ │ │ │ 家庭关系 企业关系 业务关系 │ │ ───────── ───────── ───────── │ │ 配偶 母子公司 担保关系 │ │ 父子 总分公司 授权关系 │ │ 兄弟姐妹 关联公司 委托关系 │ │ 祖孙 实际控制人 共同借款人 │ │ 继承人 一致行动人 连带责任人 │ └──────────────────────────────────────────────────┘3.2 关系数据管理的关键问题问题一关系的方向性关系是有方向的张三是李四的丈夫 ≠ 李四是张三的丈夫A公司控股B公司 ≠ B公司控股A公司数据模型中需要同时存储正向和反向关系或者用方向字段区分。问题二关系的时效性关系会变化昨天的配偶今天是前配偶上个月的子公司这个月被卖了张三 ──[配偶]──→ 李四 生效日期2015-06-01 失效日期2024-12-31离婚 当前状态已终止问题三关系的来源关系信息可能来自多个渠道客户主动申报业务办理时发现如担保合同中发现关联外部数据工商登记信息、征信报告人工审核标注每条关系都应该记录数据来源以便后续追溯和审计。问题四关系的传递性如果 A 控股 BB 控股 C那么 A 是否间接控股 C答案是看穿透层数和持股比例。银行通常只穿透到最终受益人UBOUltimate Beneficial Owner一般是穿透 3-4 层。A公司 ──持股70%──→ B公司 ──持股60%──→ C公司 │ A公司对C公司的间接持股 70% × 60% 42% 如果监管要求最终受益人持股≥25% → A是C的最终受益人42% 25% → 需要把A和C合并计算授信敞口3.3 关系图谱的应用应用场景使用的关系类型集团授信管理控股关系、一致行动人反洗钱调查家庭关系、资金往来关系营销交叉推荐家庭成员、同事关系风险传染预警担保关系、供应链关系继承/遗产处理家庭关系、继承人关系四、能力三客户分层运营4.1 为什么要分层银行有几千万甚至上亿客户不可能给每个人都提供相同的服务。客户分层运营的核心思想是把有限的资源分配给最有价值的客户。4.2 等级体系大部分银行采用类似航空公司的会员等级体系等级客户画像权益普通客户日均资产 5 万基础服务银卡客户日均资产 5-50 万优先排队、免跨行费金卡客户日均资产 50-300 万专属客服、贵宾厅白金客户日均资产 300-1000 万私人经理、定制理财钻石客户日均资产 1000 万顶级礼遇、家族信托关键设计点等级计算规则伪代码 1. 每日日终汇总客户在全行的总资产 总资产 活期余额 定期余额 基金市值 理财余额 - 贷款余额 2. 按日均资产计算过去 3 个月或 6 个月的平均值 日均资产 Σ(每日总资产) / 统计天数 3. 根据日均资产匹配等级阈值 if 日均资产 1000万 → 钻石 else if 300万 → 白金 else if 50万 → 金卡 else if 5万 → 银卡 else → 普通4.3 标签体系等级是一维的只看资产但客户画像需要多维的。标签体系就是在多个维度上为客户打标签┌──────────────────────────────────────────────────┐ │ 客户标签体系 │ │ │ │ 基础属性标签 行为标签 预测标签 │ │ ───────────── ────────── ──────── │ │ 年龄段25-30 活跃度高活跃 流失风险 │ │ 性别女 渠道偏好手机银行 购买意向 │ │ 职业IT 产品偏好基金 信用评分 │ │ 城市北京 交易频率月均15笔 生命周期 │ │ 收入段30-50w 消费场景餐饮 潜在价值 │ │ │ │ 生命周期标签 风险标签 营销标签 │ │ ───────────── ────────── ──────── │ │ 新客期3个月 AML等级低风险 活动响应度 │ │ 成长期3-12个月 逾期记录无 渠道敏感度 │ │ 成熟期1-5年 征信评分优秀 价格敏感度 │ │ 衰退期活跃下降 投资偏好稳健型 产品偏好度 │ │ 流失期6个月未动 黑名单无 推荐拒绝率 │ └──────────────────────────────────────────────────┘4.4 标签的技术架构数据源层 标签计算层 标签服务层 ────────── ────────── ────────── 交易流水 Spark/Flink 标签查询 API 账户余额 实时/离线计算 标签批量导出 登录行为 规则引擎 标签变更推送 产品持仓 ML模型 标签可视化 外部数据 客群筛选工具 │ │ │ └────────────────┴────────────────┘ │ ▼ 标签存储Redis HBase 支持千万级客户的毫秒级查询4.5 分层运营的实际应用场景使用的能力具体操作新客促活生命周期标签新开户 30 天内未交易自动推送首笔转账免手续费流失预警活跃度标签 交易频率连续 60 天未登录手机银行触发短信/电话回访交叉销售产品偏好标签 资产标签持有活期大额但不持有理财推荐稳健理财风险防控交易行为标签突然出现大额境外交易触发实时风控五、能力四风险合规管控5.1 制裁名单筛查银行在建立客户关系之前必须检查客户是否在国际/国内制裁名单上名单类型来源说明OFAC 制裁名单美国财政部SDN 名单制裁个人和实体UN 制裁名单联合国安理会全球范围内的制裁对象EU 制裁名单欧盟欧盟制裁的个人和实体人行制裁名单中国人民银行国内制裁名单涉恐名单公安部/国际刑警恐怖组织关联人员筛查时机客户开户时必须客户信息变更时姓名、证件号变更后重新筛查交易发生前高风险交易实时筛查定期批量筛查全量客户至少每月一次筛查逻辑输入客户姓名 证件号 ↓ 精确匹配姓名和证件号完全一致 ↓ 未命中 模糊匹配 - 姓名拼音相似如 Zhang San vs Chang San - 姓名去掉空格/特殊字符后匹配 - 部分证件号匹配如生日部分 ↓ 未命中 别名/曾用名匹配 ↓ 输出命中 / 未命中 / 疑似命中需人工审核5.2 反洗钱黑名单除了制裁名单银行还需要维护自身的反洗钱黑名单类型说明行内黑名单曾在我行发生洗钱/欺诈行为的客户行内灰名单有可疑交易但尚未确认的客户人行可疑交易报告向人行报送过的可疑交易涉及的客户高风险行业名单特定行业如赌场、贵金属交易的客户需加强审查5.3 KYC 持续审查KYC 不是开户时做一次就完了而是持续审查客户风险等级审查频率审查深度低风险每 3 年简化审查确认基本信息仍正确中风险每 2 年标准审查更新身份信息、交易目的高风险每 1 年增强审查核实资金来源、实际控制人、交易合理性PEP政治公众人物每 1 年增强审查 资金来源详细核实系统支撑┌────────────────────────────────────────┐ │ KYC 审查管理模块 │ │ │ │ ① 审查计划自动生成 │ │ - 每日扫描到期需审查的客户列表 │ │ - 按风险等级分配审查任务 │ │ │ │ ② 审查任务执行 │ │ - 柜员/客户经理按任务列表执行审查 │ │ - 记录审查结论和发现 │ │ │ │ ③ 审查结果应用 │ │ - 更新客户风险等级 │ │ - 高风险发现 → 触发可疑交易报告 │ │ - 信息过期未更新 → 限制业务办理 │ └────────────────────────────────────────┘5.4 个人信息保护近年来《个人信息保护法》对客户信息管理提出了严格要求CIF 系统需要支持要求技术实现最小必要收集不同业务场景只获取必要的客户字段数据脱敏展示柜员看到手机号是 138****1234全号需要额外授权数据加密存储证件号等敏感字段加密存储AES 或国密 SM4访问控制不同角色只能查看不同级别的客户信息数据导出/删除支持客户发起的个人信息导出和注销请求操作审计所有对客户信息的查询、修改、导出操作全部留痕六、四大能力的协作关系┌─────────────────┐ │ ① 主数据管理 │ ← 所有能力的基石 └────────┬────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ ┌────────────────┐ ┌────────┐ ┌──────────────┐ │ ② 客户关系维护 │ │③分层运营│ │ ④ 风险合规 │ │ │ │ │ │ │ │ 集团/家族关系 │←─│ 集团 │→ │ 集团授信管控 │ │ 个体/企业关联 │ │ 客群 │ │ 制裁名单筛查 │ └────────────────┘ │ 标签 │ │ KYC 审查 │ └────────┘ └──────────────┘主数据管理是基石——没有准确、唯一的客户数据后面一切都做不了关系维护连接了分层运营和风险合规——集团客户的统一营销、统一风控都依赖关系数据分层运营和风险合规看似对立一个想拉客一个想防风险但在系统层面需要数据共享和流程协同七、本篇小结主数据管理的核心是唯一真实来源——客户数据只在 CIF 系统维护一份唯一性校验不能只靠精确匹配还要处理音近字、身份证升位、更名等场景客户关系是有方向、有时效、有来源的——需要专门的图谱管理客户分层运营依赖等级体系一维和标签体系多维的协同风险合规的核心是制裁名单筛查 KYC 持续审查 个人信息保护四大能力需要数据共享和流程协同不能各自为政下一篇也是第三章的最后一篇——我们将跳出理论看看客户信息管理在真实项目中的那些坑。上一篇文章 9 · 客户数据模型设计下一篇文章 11 · 客户信息管理的实战案例本系列开篇 → 第一章 → 第二章 →第三章 · 根基→ 第四章 → ...© 2026 Fintech.Ren · 银行核心业务系统专栏