KYC的规则冲突
了解客户（KYC）规则为金融科技企业制造了真实的张力。监管机构要求严格的身份核验，要求企业收集并验证个人文件；而数据法规则反向施压，要求企业在收集数据后尽量减少保留。
一家银行在开立新账户时会收集大量文件：国家身份证、护照和驾照，以及地址证明和财务文件。这些文件包含大量个人数据，GDPR、反洗钱规则和银行监管机构均要求对其进行严格处理。
当这些数据流向欺诈系统或数据分析环节时，还需遵守额外规则——GDPR的数据规定随即生效，个人数据必须经过脱敏或去识别化处理才能用于二次使用。
两天积压问题
一家数字银行每天在15个欧盟国家处理5,000份KYC申请，PII扫描步骤导致了严重问题：误报率过高，审查队列持续增长，最终形成两天的积压。
根本原因很明确：其基于ML的工具将约8%的非PII文本标记为个人数据。每份文件多页，每日误报量已超过团队当天的处理能力，积压由此持续累积。
误报主要集中在三类情况：
- 公司名称被标记为人名（模型混淆了专有名词）
- 参考编码被标记为身份证号码（未进行校验位验证）
- 银行名称中的常见名字如「Chase」被标记为人名PII
每个误报都需要人工审查。按8%误报率乘以每天5,000份文件，每日产生数千个待处理任务，无一能够自动清除。
ACL研究的发现
ACL 2024年研究测试了多语言NLP模型在PII检测中的表现，结论触目惊心：仅5%的多语言NLP模型在所有24种欧盟语言中对非英语PII的F1分数超过85%。
F1分数综合了精度和召回率：精度低意味着大量误报，召回率低意味着大量遗漏，两种结果得分均差。95%的模型无法达到85% F1的门槛，揭示了跨语言PII扫描在实践中有多难。
相比之下，XLM-RoBERTa在PII任务上实现了91.4%的跨语言F1分数（来自HuggingFace 2024年基准测试）。91.4%与中位模型之间的差距，正是解释现成工具在多语言KYC场景中失效的关键。
高吞吐量KYC的混合架构设计
误报问题是可以解决的，三项设计选择即可做到。
带校验的正则表达式： 国家身份证号码遵循固定规则——德国Steuer-ID、荷兰BSN和波兰PESEL均使用校验算法。若一个数字未通过校验，则不是国家身份证号码。格式加校验可将这类证件的误报率降至接近零。
上下文感知NLP识别人名： KYC文件中的人名出现在已知位置——「姓名：」、「姓氏：」等固定表单字段。要求在标记姓名前必须存在上下文词汇，可以有效减少误报，阻止公司名称触发人名警报。
按文件类型调整阈值： KYC文件与客服邮件或医疗记录的PII构成不同，每种类型对应不同的PII组合。按文件类型设置阈值，允许团队针对各自需求进行调优：高吞吐量KYC追求更高精度，医疗去识别化则追求更高召回率。
两天积压并非PII扫描不可避免的代价，而是将通用工具应用于特定工作流的成本。解决方案在于配置优化，而非扩充团队规模。
我们的GDPR合规指南覆盖数据最小化规则，我们的安全与合规概述说明了支持合规KYC工作流的技术控制措施。