如何设计可扩展的 KYC 审核队列

KYC 审核队列是后台的工作流程，将机器无法独立通过的身份核验交给人工处理。大多数申请应自动通过；队列只为那些没通过的而存在。它的整个设计目标是保持精简——只容纳真正模棱两可的情形，别无其他——因为一个塞满本应由机器裁决的案件的队列，不是一种控制手段，而是一个随注册量线性增长的瓶颈。把队列做对，后台的规模就取决于异常的数量，而不是业务量。

“有意保持精简”这一个特性，决定了后面的每一项设计。先从保持精简的那道分流说起。

直通处理是目标，队列是例外

直通处理（STP）指一份申请从头到尾无需人工介入即可通过：证件已读取、身份已匹配、制裁和 PEP 筛查无异常、活体检测通过、决定已记录。这应当是常态路径，而走这条路径的申请占比——即 STP 率——是决定队列能否扩展的唯一关键数字。如果九成多的申请自动通过，人工队列只会有可控的涓涓细流；如果有一半掉入审核，你就得随业务增长同步招聘审核员。队列不是 KYC 发生的地方，而是自动化 KYC 承认自己拿不准的地方。把 STP 率提上去，其他所有指标都会随之改善：排队案件更少、等待时间更短、需要招的审核员更少。这值得直接攻坚——客户端更好的证件拍摄、拍照前更清晰的指引、调校匹配阈值以免正常客户被过于谨慎的规则拒之门外——因为在这里每挽回一个百分点，就意味着少一个占用某人整个下午的案件。

哪些案件会进入队列，为什么

案件被转入审核，都有具体、可命名的原因，而原因是案件最重要的属性。证件照片太模糊，无法辨认。证件上的姓名与申请上的姓名不一致。制裁或 PEP 筛查返回了可能命中的结果，需要人工确认或排除。地址无法通过任何来源核实。活体检测未通过，或者同一张面孔或同一份证件已存在于另一个账户。这些情形各是不同类型的工作，需要不同类型的判断——而把它们混成一堆不加区分，是审核队列犯的第一个错误。同一个原因的分量也可能大不相同：姓名不一致可能只是再普通不过的婚后改姓差异，也可能是身份被盗的最初迹象，队列的职责是把它交给能分辨两者的人，而不是对本应审慎对待的案件仓促下结论。

一个队列不够：按原因分段

单一队列迫使每位审核员都做通才，也让每个案件都得排在无关案件之后。按原因分段可以同时解决这两个问题。可能命中制裁的队列，由受过筛查与处置培训的人员处理；证件质量队列是快速的目视检查，初级审核员几秒钟就能完成；重复账户队列则是一项欺诈调查。每个分段都有自己的路由、所需技能和服务水平目标，因为模糊的照片应在几分钟内解决，而真正的制裁命中则值得从容、审慎地处置。分段让吞吐量与严谨性得以并存，而不是此消彼长。

靠增加审核人员，审核队列是扩不起来的。真正的扩展，在于正确判断哪些案件根本不需要人工审核，并确保需要审核的案件一到就已按原因分好类。

必须填写原因、全程可审计的操作

审核员做出的每一个决定，无论是通过、拒绝、升级还是要求补充材料，都必须填写原因并留下记录。原因不是事后随手补的自由文本，而是在操作发生的那一刻，通过结构化选项记录下为何这样处理。这不是官僚作风，而是让审核队列经得起检验的基础。当监管机构、审计人员或后来的审核员追问“为什么带着风险标记的账户仍被通过”时，答案应当是明确的审核员、时间戳和写明的原因，而不是一句含糊其辞。审计轨迹只可追加，决定无法事后悄悄改写；更正只能是新增条目，而不是覆盖旧记录。在我们的技术栈中，这个队列及其审计模型位于 Protocore Center（/products/center）。它是运营人员使用的控制台，每一项特权操作都必须填写原因，并写入无法被悄悄篡改的日志。

四眼原则案件

有些决定影响重大，不应由一个人说了算。例如清除一条真实的制裁命中、通过高风险客户档案，或推翻系统的自动拒绝，都应由第二位审核员确认，也就是 maker-checker，即四眼原则。第一位审核员提出处理意见并写明原因；第二位具备相应权限的审核员确认或驳回，并写明自己的原因。两次操作都会记入日志。这并非不信任审核员，而是因为风险最高的批准，恰恰是一次失误代价最大的地方，而多一双眼睛是成本最低的保险。队列设计应按原因自动把这类案件路由到两步处置流程，而不是指望审核员自己记得。不过，两步流程要有意只留给影响重大的案件；如果全部套用，整个队列的成本会翻倍，还会让审核员对第二道签名习惯性盖章，使它形同虚设。

为高吞吐而设计：账龄、优先级与 SLA

只增不减的队列，就是失败的队列。要把推动队列前进的压力设计进去。案件的账龄清晰可见，不会有案件被遗忘；每个客群都有各自的服务水平目标，因此照片模糊、SLA 只有几分钟的案件超时，与 SLA 较长的制裁案件，会以不同方式浮现。优先级是一项真正的取舍：先进先出公平且简单，但风险优先，即潜在敞口最大的排在最前，往往才是正确选择，同时用账龄作为平局裁决，让低风险案件也能被清掉而不至于饿死。审核员的屏幕应直接呈现已路由、已排好优先级的下一个案件，而不是一份任人挑选的清单，因为人工挑拣的队列，棘手的案件永远没人去碰。看不到账龄的队列会悄悄腐烂：难办的案件沉到底部，简单的在上层不断流转，而本可以暴露问题的那项指标，即最早未结案件的账龄，恰恰是在客户投诉之前没人盯着的数字。

衡量队列

四个数字可以告诉你设计是否有效。STP 率反映有多少案件根本无需人工介入；队列深度及其趋势反映你是在跟上还是在落后；按客群对照 SLA 跟踪的决策耗时，反映客户等待开户的时间是否过长；而重开率，即后来被推翻的决定占比，反映审核员是做得对，还是只是做得快。这些指标要放在一起看，因为它们彼此制衡：决策耗时降下来的同时重开率在上升，说明你是用错误换来了速度。健康的队列规模小、流转快、决定正确，并且对仍未结案的案件保持坦诚。

人们想象中的后台，是一屋子员工逐份录入申请，这是自动化清理得太少、队列又是一整堆不加区分的案件时的结果。真正能扩展的后台恰恰相反：大多数申请根本不会到达人工，到达的也已按原因和优先级分好类，每个操作都带着原因写入只可追加的日志，四眼原则则守住那些值得把关的决定。把队列建给例外情况，它会随业务增长而保持小规模；把它建成 KYC 发生的地方，每多一个注册用户它就会跟着变大。