2. KYC与客户主数据基础
在进入实体去重与主数据合并的技术实现之前，必须先厘清三个基础概念：KYC是什么、监管对KYC提出了哪些硬性要求、客户主数据如何组织。这三者构成了后续所有匹配、合并、治理动作的业务前提。如果概念边界不清，去重规则就会失去判断依据，合并结果也无法通过合规审计。
一、KYC的定义与核心目标
KYC（Know Your Customer，了解你的客户）是金融机构在建立业务关系前及关系存续期间，对客户身份、背景、风险状况进行识别、核实与持续评估的一整套制度与流程。它的核心目标不是“收集资料”，而是回答三个问题：客户是谁、客户是否可信、客户风险是否可接受。
从数据视角看，KYC产出的是一组关于客户的权威属性集合，包括法定名称、证件类型与号码、注册地址、实际控制人、受益所有人、业务性质、风险等级等。这些属性正是客户主数据的核心来源。因此，KYC与客户主数据不是两件事，而是同一客户信息链条上的“采集端”与“管理端”。
关键理解：KYC是业务与合规动作，客户主数据是这些动作沉淀下来的结构化结果。去重与合并，本质上是在维护KYC结果的唯一性与准确性。
二、监管要求对数据治理的约束
不同司法辖区的KYC监管细则不同，但共同要求可以归纳为以下几条，它们直接决定了主数据合并的规则设计：
- 身份唯一性：同一客户在同一机构内不应存在多个相互矛盾的档案，监管检查时要求能说明“为什么这两个记录是同一人/同一实体”。
- 可追溯性：每一次客户信息的创建、修改、合并都必须留痕，包括操作时间、操作人、变更前后值。
- 受益所有人穿透：对法人客户，必须识别并记录最终受益所有人，这意味着合并时不能只看公司名称，还要看股权与控制关系。
- 持续更新：客户风险等级、证件有效期、地址等信息需定期复核，合并后的主数据必须支持版本管理与时效标记。
- 数据最小化与保密：合并过程中不得随意扩散敏感字段，权限控制需覆盖合并操作。
常见误区：把“去重”简单理解为删除重复记录。监管要求的是“可解释的合并”，而不是物理删除。被合并的记录通常需要保留为历史版本或关联引用，否则无法通过审计追溯。
三、客户主数据的概念与数据域
客户主数据（Customer Master Data）是企业在多个业务系统中共享、关于客户的核心一致性数据。它不等同于某个业务系统里的客户表，而是经过标准化、清洗、合并后形成的“黄金记录”（Golden Record）。
客户主数据通常划分为以下数据域：
| 数据域 | 典型字段 | 在去重合并中的作用 |
|---|---|---|
| 身份标识域 | 证件类型、证件号码、统一社会信用代码、LEI | 强匹配键，优先级最高 |
| 名称域 | 法定名称、英文名、简称、别名 | 模糊匹配主战场，需处理缩写与音译 |
| 地址与联系方式域 | 注册地址、经营地址、电话、邮箱 | 辅助匹配，注意地址标准化 |
| 关系域 | 母公司、子公司、受益所有人、担保关系 | 集团客户合并与穿透识别的关键 |
| 风险与合规域 | 风险等级、制裁名单命中、PEP标识 | 合并后需取最高风险，不可简单覆盖 |
| 生命周期域 | 创建时间、最后更新、状态、来源系统 | 决定哪条记录优先、如何留痕 |
理解数据域的意义在于：去重时不同域的匹配策略不同。身份标识域适合精确匹配，名称域适合模糊匹配，关系域适合图算法，风险域适合规则合并而非字段级覆盖。
四、实体类型与合并场景
KYC中的“实体”不只有个人，还包括各类法人及非法人组织。实体类型直接决定了可用标识和匹配难度：
- 自然人：以身份证件为核心标识，但存在姓名重名、证件变更、多语言拼写差异等问题。
- 企业法人：以统一社会信用代码或注册号为核心标识，但集团内子公司名称高度相似，容易误合并。
- 个体工商户：介于个人与企业之间，常出现经营者与字号混用的情况。
- 信托、基金等非法人组织：缺乏统一标识，更多依赖名称与关系匹配。
下面是一个简化的实体匹配优先级配置示例，用于说明不同实体类型下各数据域的权重差异：
entity_type: LEGAL_PERSON
match_rules:
- field: unified_social_credit_code
type: exact
weight: 1.0
mandatory: true
- field: legal_name
type: fuzzy
algorithm: jaro_winkler
threshold: 0.92
weight: 0.6
- field: registered_address
type: normalized_exact
weight: 0.3
- field: beneficial_owner_id
type: exact
weight: 0.5
merge_policy:
risk_level: max
status: active_over_inactive
audit: full_snapshot实践提示：强制匹配键（mandatory）一旦命中，通常可直接判定为同一实体；非强制键用于打分，累计超过阈值才进入人工复核。这样可以在准确率与召回率之间取得平衡。
五、案例与复盘：一次误合并的教训
某机构在合并企业客户时，仅依据“企业名称相似度”进行匹配，结果将两家名称相近但统一社会信用代码不同的公司合并为一条主数据。后果是：一家公司的制裁名单命中被错误地关联到另一家正常公司，导致后者业务被冻结，同时监管报送数据失真。
复盘结论有三点：
- 强标识字段必须作为合并的前置校验，名称相似只能作为辅助证据。
- 合并前应设置人工复核队列，尤其是涉及风险域变更的场景。
- 合并操作必须生成完整快照，支持一键回滚与审计取证。
这个案例说明，KYC与客户主数据基础不是理论铺垫，而是去重合并规则设计的直接约束。只有把监管要求、数据域特性和实体类型三者对齐，后续的匹配算法与合并策略才有可靠的业务依据。