KYC 这三个字母，在业务侧待久了的人都懂，看着像是“实名认证”，拍证件、刷脸、过一下流程，实际上远远不止这些。尤其当系统开始对接支付通道、开放商家入驻、上线高客单交易功能时，监管、合作方、审计都会盯着你的客户识别机制。这篇“下篇”，我直接绕开概念，聊实战：怎么把 KYC 从“能用”推到“扛得住事”。
适合看这篇的人很明确：之前写过基础实名接口、现在要补风险分层和持续监控的同学，或者正在设计进件流程、被内部合规追着要方案的风控产品经理。读完之后，你至少能拿到一整套可落地的模块划分、核心参数设计和踩坑清单，而不是看完还停在“哦 KYC 就是核验身份”的层面。
1. 整体思路：不要把一个流程做成一个孤立功能
1.1 KYC 是一条链路，不是一次调用
很多团队一开始把 KYC 简化成“调用一次身份认证服务”。用户填了姓名和身份证号，或者扫了一张证件，第三方返回“一致”，就以为完成了 KYC。这套做法在前几年还能应付早期审查，但业务只要稍微做起来，问题立刻暴露：同一客户反复提交不同证件、证件是真的但人是代理而不是本人、客户进了黑名单但老账户还在正常交易。等出险了再回头补，成本直接翻倍。
我习惯把 KYC 拆成五个模块：信息采集、身份真实性核验、风险分类、名单筛查、持续监控。这五个模块不一定都由自家系统完成，第三方能力可以嵌入，但你必须在系统层面把它们串成一条链路。每个模块的产出都要落到同一个客户档案里，供后续任何一次交易、申诉、退款做辅助判断。
用生活里的例子说，KYC 就像是银行开户时的柜台服务。柜员先看你的证件像不像本人，再问你几个问题，然后查询系统里有没有异常记录，最后给你开户并给账户设定一个初始交易额度。开户动作结束了吗？账户以后每个月的大额存取、跨境转账，柜台和系统都还在盯着，这就是持续监控。开户只是“进门”，KYC 的完整链路是“进门之后一直认识你”。
1.2 分层设计比一刀切更现实
把 KYC 做成所有用户都走同一套最高标准流程，是另一种典型失误。既影响转化率，又浪费审核资源。正确思路是按风险分层，用不同强度的流程处理不同客户。
基础策略可以从四个维度展开：
- 客户身份：自然人或法人、本地或境外、是否涉及高风险管理行业。
- 业务场景：只充值消费的小额用户，还是能发起转账、提现、代付的角色。
- 资金特征：单笔金额、频率、往来对手方数量。
- 历史行为：是否有羊毛行为、短时间改绑、异常登录前科。
对应到实际配置，建议做三档：一般客户走基础尽调，拍证件加人脸，再校验一下姓名、证件号、手机号实名的一致性；中风险客户走增强尽调，补地址证明、资金来源说明或电话回访；高风险客户走高级尽调，在增强尽调基础上增加第二审核人复核、限制额度或人工面签。
分层不是人为设置无意义门槛，而是把有限的审核人力集中在真正有风险的地方。我见过一个平台，把所有用户统一要求上传手持证件照，结果新用户留存掉了十几个点，风控审核团队天天加班，查出来的问题却没几个，后来改成按风险分层，大部分普通用户通过 OCR 加活体秒级通过，少部分触发人工的客户才走手持有照流程，审核压力立刻降了下来。
2. 核心细节与实操要点：每个模块都要抠参数
2.1 身份信息采集不是“多填几个字段”那么简单
身份信息字段必须满足后续核验和监管要求，但也别贪多。基础字段至少包括：姓名、证件类型、证件号码、性别、出生日期、证件有效期、联系方式、居住地址。涉及企业账户或商户入驻时，还要追加工商注册信息、受益所有人、实际控制人信息。不要等到将来要上企业客户才临时补字段，那会让存量客户重新发起认证，体验极差。
采集阶段最容易被忽略的是地址。很多产品只让用户填一个省市区加街道，却不知道地址在洗钱风险评估里作用很大。地址是判断客户生活工作地点、是否涉及高风险地区、是否与交易对手之间住址重叠的关键信息。如果你现在的表单里没有地址字段，建议尽早加上，并做成“省市区级联选择+详细门牌”，不要做完全自由文本，否则后续名单筛查和数据分析都会因为脏数据变得很难办。
证件有效期也经常漏掉。身份证到期之后，客户的身份核验结果就过期了，如果系统没有对有效期做识别和任务提醒，客户会带着一张已失效的证件继续交易。实操上，KYC 服务返回证件有效期后，至少要存一个“证件过期时间”字段，并在到期前 90 天生成一个提醒任务，触发客户重新认证。
2.2 证件识别和人脸活体：理解“通过率”背后的陷阱
证件识别和人脸核身，是整个 KYC 链路里用户直观感受最强的部分。第三方服务选型时，统一看“通过率”“准确率”很容易踩坑，因为不同场景下的通过率口径差别很大。
先看证件识别。身份证图片在原始相机下，容易出现反光、倾斜、边角缺失、字迹模糊的问题。你需要关心的是：在用户真实拍摄环境下，人像面识别成功率是多少，而不是厂商在标准测试集上的准确率。选型时最好拿旧手机、暗光环境、翻拍屏摄的图片各测几十张。还有一个小细节：不是所有用户都能把证件放在纯色背景上，有些人的桌面、床单、书刊有复杂纹理，OCR 算法很容易误切边界，要专门测这一类。
活体检测的难点从来不是“照片能不能识别”，而是攻击手段。静态照片 P 图难防，视频重放难防，3D 头模更难防。纯 2D 单人脸方案已经不太够用，至少要做随机动作指令、多帧采集、设备环境检测。随机动作指令的意思是让用户完成系统即时下发的特定动作，比如“眨眨眼”“向左转头”“张嘴”，而不是固定提示某一套动作，因为固定动作可以被提前录好的视频破解。
设备环境检测也很重要。如果检测到用户是在模拟器环境下打开页面，或者调用摄像头的是虚拟摄像头设备，直接判定失败。不要只想着优化用户体验而把这个开关关掉。宁可让一小部分使用模拟器的合规用户走人工通道，也不能把活体校验变成摆设。
2.3 名单筛查：姓名匹配别指望完全相等
名单筛查在整个 KYC 流程里最容易被开发低估。有些团队直接拿用户输入的姓名去数据库里查字符串完全相等，结果要么漏报，要么在重名和繁体字上大量误报。
实际操作中，名单至少分为四类：监管类名单、司法涉案名单、内部历史不良名单、媒体负面名单。名字匹配时不能只比全名字符串，还要做同音字、繁体字、拼音转换、大小写归一化、少数族裔姓名通配符处理。
这里给一个可参考的匹配策略：
- 先做标准化：去掉全角空格、统一大小写、繁体转简体、中文转拼音。
- 再判断三个层次：精确匹配、首尾词匹配、近似匹配。
- 精确匹配直接命中；近似匹配给一个相似度分值，超过 80 分进人工复核，低于 80 分但涉及高危险名单时也进人工复核。
- 不允许出现“只有精确匹配才拦截”这种策略，因为名单中的姓名常常带别名、曾用名、音译差异。
顺带提醒一句，筛查不是一次性的。名单会更新，老客户之前不在名单上，不代表现在就不在。所以必须建立定期重扫任务，通常建议每天对新增黑名单做一次全量存量客户比对，增量名单更新后做实时比对。我见过一个平台因为只做下单时筛查，一个已经被列入黑名单的客户在系统里继续活跃了将近两个月，只是因为他的账户创建时间早于名单生效时间。
3. 实操过程与核心环节实现：把链路真正串起来
3.1 标准进件流程：从注册到结果回传
一个相对完整的 KYC 进件流程可以这样拆：
- 用户提交注册信息，系统生成唯一客户编号。
- 调用证件 OCR，返回结构化证件信息，同时留存证件图像用于审计。
- 调用活体检测接口，确认当前操作为真实本人。
- 将客户提交姓名与证件姓名做比对，要求一致性达到阈值。
- 将证件号码、手机号、银行卡信息（如有）做一致性核验。
- 将姓名、证件号、地址、公司信息送入名单筛查服务。
- 根据规则引擎输出风险等级和动作（通过、拒绝、人工复核、限额放行）。
- 返回结果给业务侧，写入客户档案，并启动持续监控任务。
这个流程里最关键的一点是异步化。很多团队把 KYC 做成了同步请求，页面一直转圈，用户等得焦头烂额。建议把风险评级、名单筛查这类可能耗时超过三秒的操作抛到消息队列里异步处理，用回调或轮询结果。用户看到“认证已提交，结果将在几分钟内通知”的文案，感受完全不一样。
3.2 接口设计示例：一个可复用的核身回调结构
数据怎么传，直接影响到排查效率。下面是一个简化但可落地的核身结果回调结构，项目里可以直接借鉴。
{ "verifyId": "KY202506071300001", "clientId": "USER-8839201", "status": "PASS", "level": "enhanced", "riskScore": 68, "riskLevel": "medium", "matchedRules": ["address_blacklist_region", "id_duplicate_device"], "verifyDetail": { "idOcr": { "name": "张**", "idNumber": "3*****************1", "expiryDate": "2032-04-18", "matchResult": "PASS" }, "liveness": { "result": "PASS", "attackType": null, "score": 0.96 }, "listCheck": { "riskMatched": false, "simScore": 0.0, "listName": null } }, "auditInfo": { "ocrImageId": "IMG-88213", "livenessVideoId": "VID-22931", "operator": "system" } }这里的 riskScore 是规则引擎输出的综合风险分，matchedRules 是触发规则标识。留存这些字段的最大价值在于后续复盘。比如某一天大量客户被拒绝，你可以快速查到是不是近期加了某条规则，或者活体攻击检测阈值被调高了。如果回调结构里只有“通过/拒绝”，后期回溯问题时会非常痛苦。
3.3 规则引擎配置：先做减法，再做加法
规则引擎不要一上来就堆几十条规则，建议最小闭环起步。第一版只要四条基础规则：
- 名单筛查命中：直接拒绝或转人工。
- 身份证件已过期：拒绝。
- 证件号与年龄不匹配：拒绝。
- 活体检测分数低于阈值：转人工复核。
上线跑两周，看数据，再逐步增加规则。比如设备指纹异常、IP 归属地异常、同一证件号在不同设备上大量出现、短时间内多个新用户关联同一手机号。规则爆炸往往是灾难的开始，因为规则之间会互相打架，出了问题你也分不清是哪条规则引起的。
这里提供一个运用于圈定的规则表示法，适合放在配置中心里维护。
| 规则编号 | 规则名称 | 输入字段 | 条件表达式 | 风险分 | 触发动作 |
|---|---|---|---|---|---|
| R01 | 证件过期 | expiryDate | expiryDate < now | 90 | 拒绝 |
| R02 | 名单命中 | listCheck.riskMatched | true | 100 | 人工复核 |
| R03 | 活体低分 | liveness.score | < 0.8 | 70 | 人工复核 |
| R04 | 年龄段不符 | birthYear | 不在 18-70 | 60 | 人工复核 |
在实际项目里，这些阈值要支持动态修改。因为客群、机型、地域季节变化都会影响指标。我一般会把阈值放进配置中心，而不是写死在代码里，这样可以做到临时调优不用发版。
3.4 数据存储与审计：别把 KYC 数据当普通业务数据
KYC 涉及客户的证件照、人脸影像、身份证号码等敏感信息，存储和传统的用户表完全是两个量级的要求。至少要做这几件事：
- 对证件号、手机号做加密存储，严禁明文落库。
- 证件图像和人脸视频要单独放对象存储，访问权限最小化，日志留痕。
- 所有 KYC 调用记录保留至少一套不可删除的审计日志，包括调用方、时间戳、IP、操作类型。
- 根据业务涉及的监管区域要求设置数据保留期限，到期后做可验证的删除。
这里想特别说一句：很多小团队为了省成本，把证件照片直接放在应用服务器目录里。一旦服务器被打穿，客户敏感信息全部泄露。即使正规的第三方核身服务会提供托管服务，你依然要确认图像存储的加密策略和访问控制。别以为“KYC 是第三方的，我就不用管数据安全”，合规责任永远在业务方。
4. 常见问题与排查技巧实录：那些文档上不写的事
4.1 证件识别大面积失败，问题往往不在算法
接到反馈说“客户上传身份证后识别失败率特别高”，第一个先别查识别服务的算法配置，先查你前端对图片的处理链路。常见原因有三个：一是 app 端直接把原图压缩到了几十 KB，证件上的文字完全看不清；二是 Web 端没有做 EXIF 方向矫正，拍照方向不对导致 OCR 读不出来；三是对用户相册里的截图做识别，屏幕上出现的是亮斑或摩尔纹。
建议前端统一做三项处理：限制最小边距和分辨率、自动校正方向、在拍照时引导用户避光。还有一招是把“身份证人像面/国徽面”的排序固定，在页面文案里写清楚“请拍摄人像面”，并在上传后自动识别正反面，避免用户拍错导致系统误判。
4.2 活体检测在低端机和弱网下“误杀”严重
这几年活体误杀最集中的场景不是攻击，而是老年用户、低端安卓机、弱网络环境。随机动作指令还没读完，用户动作已经做完，等视频上传完，系统判断动作不匹配。排查时关注几个点：
- 视频上传是否做了压缩，帧率和码率有没有自适应；
- 动作检测的超时时间是否太短；
- 是否有“失败后允许重试 2 次”“切至闪烁读数模式”的兜底机制；
- 是否支持服务端二次复核，而不是完全依赖端上判定。
我自己常用的兜底方案是：端上活体失败时，不直接拒绝，先走一次线上客服人工复核，或者引导用户切换为“读数模式”，在这种模式下用户只需要按屏幕提示念出动态数字，模型对视频质量的敏感度比动作指示模式低很多，普通旧手机也能通过。
4.3 名单误报率高：给“名字相似”单独建通道
名单筛查上线当天，你可能就会看到大量误报。最常见的是中文姓名天然重名，再加上拼音匹配把“马力”和“马莉”划成高相似，导致用户一注册就被转人工。
处理建议是不要把所有名单都套同一个阈值。高风险名单用比较严格的匹配条件，只对全名精确匹配或证件号匹配做拦截；普通负面名单则可以放低阈值、高复核。还有一个小技巧：把名单匹配结果拆成“强命中”“弱命中”两档。强命中进人工，弱命中只在风险画像里加权，不直接触发阻断。这样既控制风险，又不会让误报把客服团队淹没。
4.4 存量客户的风险档案更新
KYC 做完≠万事大吉。客户的风险是会漂移的，今天正常交易，三个月后可能变成高风险画面，比如频繁更换设备、多个账户共用一张银行卡、交易对手出现异常名单。
建议每个存量客户至少做两个定时任务：一个每天扫描新增名单，一个每周扫描频繁交易特征。扫描结果不一定要马上冻结账户，可以先生成“风险提醒”，让运营人员决定是否收紧额度。不要小看这一层，它是“事后追责”和“事前拦截”之间最大的差别。
5. 最后分享几个我自己的实操习惯
做了几年 KYC 类项目，体会最深的是这几点：
第一，KYC 核心不是“严”，而是“准”。有些团队把通过率压得很低，觉得拒绝得越多越合规，结果是把正常用户也挡在了门外，名声在渠道端迅速变差。合理的做法是把高风险用户找出来，而不是把所有用户都当成高风险来防。
第二，一定要保存好每一次规则调整前后的对比数据。没有数据就想调阈值，就是在赌博。至少记录调整前一周和调整后一周的通过率、人工复核率、拒绝后的申诉率，让每次调整都能量化成结论。
第三，把客户申诉通道当成 KYC 系统的一部分，而不是客服的附属品。误杀不可怕，可怕的是客户被误杀了之后找不到任何途径解释。哪怕只放一个在线工单，让客户上传补充材料，也能避免不必要的客诉和渠道损失。如果你正准备做或重构 KYC，建议从一开始就把这几件事纳入规划：风险分层、异步处理、数据加密、存量监控、申诉通道。这套组合下来，至少不会在业务量上来之后被各种后遗症追着跑。
