> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Database Validation Matching Methods > How 1x1 and 2x2 outcomes are derived from per-service matches: fuzzy name thresholds, partialMatchAction rules, waterfall logic. From $0.05/check. Didit's [Database Validation](/core-technology/database-validation/overview) API checks identity data against the authoritative civil registry, tax authority or electoral roll for each country — RENAPER (Argentina), Receita Federal (Brazil), Tribunal Electoral (Panama), RENAPO (Mexico), Junta Central Electoral (Dominican Republic), Registraduría Nacional (Colombia) and more. Each query is billed per successful call, from **\$0.05/check** with no monthly minimums. Outcomes are derived from per-service results: **1×1** when a single registry returns a full match, **2×2** when two independent registries corroborate the data. This page documents how those outcomes are computed, the fuzzy-match thresholds applied to names, and the decision logic that governs `partialMatchAction` and `noMatchAction` in your workflow rules. ## 1×1 matching This method involves matching one input data point (typically a national ID or similar identifier) against our database. If a direct match is found, we confirm the identity. However, if the initial attempt fails, we may try alternate trusted data sources in a waterfall sequence. This means we continue validating through successive providers until we either achieve a match or exhaust all options. Importantly, a partial match does not stop the process—we only stop once we find a full and conclusive match or determine that no match exists. The 1x1 Matching logic requires matching a user’s personal data against one source to receive a Full Match on their identity.\* | Verification Result | Name Category | ID Category | Date of Birth Category | | :------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | :--------------------- | | Full Match | Full Match | Full Match | Any Value | | Partial Match | Partial Match | Full Match | Any Value | | No Match | All other combinations | | | *\*The applicable country sources are screened until a Full Match on the identity is made. If a Full Match is not found, the system then repeatedly screens those sources for a Partial Match on the user’s identity.* ## 2×2 matching This method requires matching two input data points (e.g., name + date of birth, or national ID + phone number) against two corresponding fields in our database. Just like with 1x1, we follow a waterfall approach, querying multiple data sources sequentially. We persist through each step until we find a complete match across both data fields. Partial or single-field matches are not sufficient; the validation process continues until a definitive 2-field match is achieved or all sources have been checked. The 2x2 Matching logic requires matching a user’s personal data against two sources to receive a Full Match on their identity.\* | Verification Result | 1st Data Source | 2nd Data Source | | :------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Full Match | Name Full Match + National ID Full Match | Name Full Match + National ID Full Match | | Full Match | Name Full Match + National ID Full Match | Name Partial Match + National ID Full Match | | Full Match | Name Full Match + National ID Full Match | Name Full Match + Date of Birth Full Match | | Full Match | Name Full Match + National ID Any Value | Name Full Match + National ID Any Value | | Partial Match | Name Full Match + National ID Full Match | | | Partial Match | Name Partial Match + National ID Full Match | | | Partial Match | Name Full Match + Date of Birth Full Match | | | Partial Match | Name Full Match + National ID Any Value | | | No Match | All other combinations | | *\*The applicable country sources are screened until a Full Match on the identity is made. If a Full Match is not found, the system then repeatedly screens those sources for a Partial Match on the user’s identity.* *** ## Data category and attribute matching The following are the scenarios that result in a Full Match for the Name, Date of Birth, and ID data categories. A Partial Match is only possible for the Name category. ### Name category matching A **Full Match** on the Name category is considered when any of the following data attribute matching scenarios is met: * Full Name Concatenation Full Match (First Name + Last Name combined with 85% similarity threshold) * First Name Full Match + Last Name Full Match * First Name Full Match + Maternal Name Full Match * First Name Full Match + Paternal Name Full Match A **Partial Match** on the Name category is considered when any of the following data attribute matching scenarios is met: * First Name Full Match * Last Name Full Match * Paternal Name Full Match * Maternal Name Full Match * Maternal Name Full Match + Paternal Name Full Match ### Date of birth category matching A **Full Match** on the Date of Birth category is considered only when the following data attribute matching scenario is met: * Year of Birth Full Match + Month of Birth Full Match + Day of Birth Full Match A Partial Match on the Date of Birth category is not possible. ### ID category matching A **Full Match** on the ID category is considered only when the following data attribute matching scenario is met: * Identification Number Full Match A Partial Match on the ID category is not possible. *** ## Fuzzy matching for data attributes These are the criteria for fuzzy matching on different data attributes against country sources. * **Name Data Attributes** For a Name category data attribute to generate a Full Match, it should be within 70% of the Levenshtein character similarity in comparison to the records in the data sources. For full name concatenation (First Name + Last Name combined), a higher threshold of 85% similarity is used. E.g., if the Name attribute input is 'Christophel' and the actual name is 'Christopher', a Full Match is returned based on the fuzzy matching logic. This system is applicable to the *First Name*, *Last Name*, *Paternal Name*, and *Maternal Name* data attributes. * **Date of Birth and ID Data Attributes** We do not employ any kind of fuzzy matching on data attributes within the Date of Birth or ID data categories. An exact match is required for these fields. ### Examples Below are examples of data attribute inputs that would satisfy the criteria of the fuzzy matching logic and generate a Full Match. | Data Attribute | Input | Data Source Record | Result | | :------------- | :---------- | :----------------- | :---------------------------------------------------------------------------------------------------------------------- | | first\_name | Christopher | Christopher | Full Match | | first\_name | Christophel | Christopher | Full Match | | first\_name | Chris | Christopher | No Match | | last\_name | Smith | Smith | Full Match | | last\_name | Smyth | Smith | Full Match | | last\_name | Smitty | Smith | No Match | ## See also * [Database Validation overview](/core-technology/database-validation/overview) — how the API works end-to-end, supported registries, pricing. * [Outcome Codes](/core-technology/database-validation/database-validation-outcome-codes) — full list of provider response codes (deceased, minor, document not found, biometric mismatch). * [Warnings](/core-technology/database-validation/database-validation-warnings) — what we surface when a service can't run due to missing input. * [Supported Countries & Services](/core-technology/database-validation/database-validation-supported-countries) — every live registry, required fields and per-call price. * [Reports](/core-technology/database-validation/database-validation-report) — monthly per-service billing exports.