客户姓名与证件不一致，别因此拒绝了真正的本人。

姓名不一致时，团队应回到证据本身。不要因此自动批准申请，也不要让真实客户从头再来。先确认差异的原因，再检查其他证据是否支持同一个人。

某份记录把姓放在前面，另一份放在后面；表单去掉了重音符号；证件上有客户未填写的第二个名字。这些问题与提交完全不同的身份，需要不同的审查方法。

确认差异属于哪一类

区分空格与标点、姓名顺序、遗漏部分、不同文字之间的转写，以及客户声称的法定姓名变更。无法解释的差异应单独归类。

W3C的人名指南 （在新标签页中打开）说明，统一的“名加姓”模型无法适应所有地区。应据此设计审查流程，而不是把熟悉的姓名形式当成可信的前提。

保留来源中的原始拼写。用于比较的版本另行存储，并记录转换方式。如果直接从唯一副本中删除字符，就会破坏审查人员之后可能需要的证据。

交叉核实，但不要降低标准

比较相关且独立的属性：出生日期、证件信息、可获得的权威记录，以及将申请人与该身份关联的证据。看似合理的拼写变化，不能抵消出生日期矛盾或身份核验失败。

NIST的身份核验指南 （在新标签页中打开）区分了身份解析、证据验证和证据持有人核实。审查记录也应分别回答这些问题。

只向客户索取足以补全缺口的最少说明。如果未解决的问题是姓氏如何被记录，就不应再要求一张自拍。

让审查决定可以重复执行

记录两个姓名值、各自来源、差异类别、支持证据和剩余不确定性。结论可以是接受合理变体、需要更多证据，或矛盾尚未解决。

例如，姓名顺序不同而其他属性一致，可能支持接受申请。客户声称发生法定姓名变更时，仅做拼写标准化不够，应按既定证据流程处理。这些例子都不是通用的接受规则。

测试表单容易处理错误的情况

创建经过授权的测试，覆盖重音符号、多个名字、不同文字和姓名顺序。除了欺诈结果，还应衡量审查时间、后续更正和真实客户的完成率。

参考Toden身份验证概览，选择能回答证据问题的检查，再测试工作流。明确接受政策；产品结果本身并不能解释姓名为何不一致。