快速开始
集成 / SDK
用户验证
企业验证
交易监控
更新日志partialMatchAction 和 noMatchAction 的决策逻辑。
1×1 匹配
该方法涉及将一个输入数据项（通常是国民身份证号或类似标识符）与我们的数据库进行匹配。如果找到直接匹配，我们将确认身份。但是，如果首次尝试失败，我们可能会按瀑布序列尝试备用可信数据源。这意味着我们将通过后续的服务提供商继续验证，直到实现匹配或用尽所有选项。重要的是，部分匹配不会终止流程——我们仅在找到完全且确凿的匹配，或确定不存在匹配时才会终止。 1x1 匹配逻辑要求将用户的个人数据与一个来源进行匹配，以对其身份获得 完全匹配。*
*系统会持续筛查适用的国家/地区数据源，直到对该身份实现完全匹配。如果未找到完全匹配，系统随后会重复筛查这些数据源，以寻找该用户身份的部分匹配。
上方的 1×1 表格和下方的 2×2 表格描述的是通用模型，并不构成对每个服务都适用的保证。决定性的字段因服务以及您发送的选填输入而异：登记处只能比对其保存的字段以及您提供的字段，并且服务的结果由其实际比对的字段决定。并非每个服务都会比对证件号码，某些服务仅在您发送证件号码时才会进行比对。例如，西班牙 - DNI/NIE 验证（
esp_dni）需要姓名、出生日期和地址，并将 national_id 作为选填输入。它始终比对姓名、出生日期和地址，并且在您发送 national_id 时还会比对证件号码。必填字段不一定是决定性字段，而选填字段可能是决定性字段。必须发送必填字段才能使请求被接受，而在 source_data 中列出的字段是登记处返回的数据。两者都无法表明是哪些字段决定了最终结果。每个服务页面上的响应示例展示了一种可能的响应，因此其 validation 对象的键并不是该服务所比对字段的完整列表。支持的国家/地区与服务下列出的每个服务的 API 参考页面，在输入下罗列了其必填和选填输入。2×2 匹配
此方法要求将两个输入数据项（例如姓名 + 出生日期，或身份证号 + 电话号码）与我们数据库中的两个对应字段进行比对。与 1x1 相同，我们采用瀑布流模式，按顺序查询多个数据源。我们会逐步继续查询，直到在两个数据字段上都找到完全匹配。部分匹配或单字段匹配均不符合要求；核验流程会一直持续，直到实现明确的 2 字段匹配或已检查所有数据源。 2x2 匹配逻辑要求将用户的个人数据与两个数据源进行比对，从而在其身份验证中获得 完全匹配。*
*系统将对适用的国家/地区数据源进行筛查，直至找到身份的完全匹配。如果未找到完全匹配，系统随后会重复筛查这些数据源，以寻找用户身份的部分匹配。
数据类别与属性匹配
以下是姓名、出生日期和 ID 数据类别产生 完全匹配 的场景。部分匹配 仅适用于姓名类别。姓名类别匹配
当满足以下任一数据属性匹配场景时，即视为姓名类别 完全匹配：- 姓名拼接 完全匹配（名 + 姓合并，相似度阈值为 85%）
- 名 完全匹配 + 姓 完全匹配
- 名 完全匹配 + 母姓 完全匹配
- 名 完全匹配 + 父姓 完全匹配
- 名 完全匹配
- 姓 完全匹配
- 父姓 完全匹配
- 母姓 完全匹配
- 母姓 完全匹配 + 父姓 完全匹配
出生日期类别匹配
仅当满足以下数据属性匹配场景时，才视为出生日期类别 完全匹配：- 出生年份 完全匹配 + 出生月份 完全匹配 + 出生日 完全匹配
ID 类别匹配
仅当满足以下数据属性匹配场景时，才视为 ID 类别 完全匹配：- 证件号码 完全匹配
数据属性的模糊匹配
以下是针对不同国家/地区数据源进行数据属性模糊匹配的标准。- 姓名数据属性 姓名类别的数据属性若要生成 完全匹配，与数据源中的记录相比，其 Levenshtein 字符相似度应至少达到 70%。对于全名拼接（名 + 姓组合），则使用更高的 85% 相似度阈值。例如，如果输入的姓名属性为“Christophel”，而实际姓名为“Christopher”，基于模糊匹配逻辑将返回 完全匹配。该系统适用于 First Name（名）、Last Name（姓）、Paternal Name（父姓）和 Maternal Name（母姓）数据属性。
- 出生日期和证件数据属性 我们不对出生日期或证件数据类别内的数据属性使用任何类型的模糊匹配。这些字段必须完全匹配。
示例
以下是满足模糊匹配逻辑标准并生成 完全匹配 的数据属性输入示例。另请参阅
- 数据库核验概述 — API 的端到端工作原理、支持的登记机构与定价。
- 结果代码 — 提供商响应代码的完整列表（已故、未成年人、未找到证件、生物识别不匹配）。
- 警告 — 因缺少输入而导致服务无法运行时我们提示的内容。
- 支持的国家/地区与服务 — 所有已上线的登记机构、必填字段及每次调用价格。
- 报告 — 每月按服务生成的计费导出。