Skip to main content
An in-depth guide to how FrankieOne evaluates identity attribute matches, and the configuration decisions that determine whether a verification passes or fails.

​
What is Fuzziness?

Fuzzy matching is a technique for identifying correspondences between submitted identity data and records held by a data source, where an exact character-by-character match may not be present. FrankieOne applies fuzzy matching logic to three core identity attributes: name, date of birth (DOB), and address. A fuzziness threshold defines the minimum similarity score an attribute must achieve for FrankieOne to treat it as a match. Thresholds are typically expressed as a percentage (0–100), where 100 represents an exact match.
Relationship to rulesets: A KYC ruleset defines how many matches are required across which attributes. Fuzziness configuration determines whether a given attribute value from a data source is counted as a match at all. Both layers must be correctly configured for your workflow to produce the expected outcomes. See eKYC Rulesets for details on ruleset logic.
Fuzziness thresholds and address element requirements are configuration concepts managed by FrankieOne. They are not controlled via API request parameters. Changes to fuzziness configuration must be requested through your FrankieOne account team.

​
Why Fuzziness Configuration Matters

Fuzziness settings directly affect whether a verification passes or fails. Misconfigured thresholds can result in:
  • False negatives — legitimate customers failing verification due to minor data entry variations (e.g., “Jon” vs “John”, “St” vs “Street”)
  • False positives — near-matches being accepted where an exact match is compliance-critical, particularly for Date of Birth in age-restricted or regulated workflows
The three attributes each warrant distinct configuration decisions.

​
Date of Birth

DOB is one of the most compliance-sensitive attribute. A permissive threshold can allow an entity to pass verification with an incorrect date of birth — a material risk for age-restricted services and any workflow where age confirmation carries a regulatory obligation. For age-restricted services, DOB verification requires two distinct configuration layers to be in place. Both are necessary. Neither is sufficient on its own. Layer 1 — Fuzziness threshold: how closely the submitted DOB must match the source record DOB is commonly configured to require an exact match (100%). This is particularly important when using the two_plus_age ruleset or any workflow where a DOB match is a required component of the passing combination.
Age Verification: If you are using consumer or commercial data sources for age verification, confirm with your FrankieOne account team that your DOB fuzziness configuration enforces an exact match. Government-issued ID sources are generally the most reliable for DOB verification as they match against official records and use exact match.
Layer 2 — Entity age as a risk factor: what happens after the DOB is matched A successful DOB match confirms that the submitted date of birth corresponds to a record in a data source. It does not by itself determine whether the verified age is acceptable for your use case. FrankieOne’s risk framework evaluates entity age as a risk factor following a successful verification. For age-restricted services, the entity age risk factor should be configured to treat any age range that is unacceptable for your use case — for example, under 18 — as an unacceptable risk. This ensures that an entity whose verified age falls below the defined threshold will receive a failed outcome, regardless of whether the KYC ruleset conditions were otherwise met.
Entity age risk factor evaluation is a configuration concept managed by FrankieOne. It is not controlled via API request parameters. If your use case requires age-based risk gating, discuss this with your FrankieOne account team during onboarding to ensure the correct age ranges are configured as unacceptable risk in your workflow.
Complete age verification configuration checklist: LayerConfiguration RequiredRisk if MissingeKYC rulesetSelect a ruleset that mandates a DOB match (e.g., two_plus_age, gov_id_only)DOB may not be evaluated as a required match componentDOB fuzzinessSet to exact match (100%)A DOB with minor discrepancies may be incorrectly counted as a verified matchEntity age risk factorSet unacceptable age ranges (e.g., under 18) to unacceptable riskAn underage entity may pass KYC and proceed to onboarding All three must be correctly configured for age verification to function as intended.

​
Name

Name matching applies fuzzy logic to account for common real-world variations: nicknames, transliterations, middle name differences, and minor spelling discrepancies. FrankieOne uses Levenshtein distance as the primary similarity measure for name elements. Our vendors use their own fuzzy logic that can be provided during onboarding. A name element generates a match when the submitted value falls within the configured similarity threshold relative to the record returned by the data source. Example: An input of “Christophel” may match a data source record of “Christopher” at an 85% threshold, as the character difference falls within the acceptable range. Name matching is assessed across the following elements, where available from the data source:
  • Full given name
  • Surname
  • First initial + surname
Note on synonyms: Some data sources maintain synonym tables (for example, “Matt” ↔ “Matthew”). Where a name matches only via synonym, the source may return a partial match result rather than a full match. This can affect the overall component score and should be factored into your threshold decisions. Synonym behaviour varies by data source.

​
Address

Address fuzziness operates at two distinct layers, both of which affect verification outcomes.

​
Layer 1 — Element Inclusion: Which Address Components Are Required

This is the more consequential configuration decision. An address match is not assessed against the address as a single string. It is assessed against the individual components of the address — street number, street name, city, state or province, and postal code. For an address match to be registered, a configurable subset of these components must each individually meet their threshold. Requiring only postal code and state produces a materially looser address match than requiring street number, street name, city, and postal code. The required combination directly determines both verification pass rates and the strength of identity assurance. The following table illustrates how the same address input can produce different match outcomes depending on which elements are configured as required:
Elements RequiredExample: “12 Main St, Austin, TX 78701”Match Outcome
Street + City + State + Postal CodeAll four present and within threshold✅ Match
Street + City + Postal CodeStreet, city, and postal code within threshold✅ Match
City + State onlyCity and state present; street absent✅ Match (lower assurance)
Street onlyStreet present; city and postal code absent❌ No match
A configuration requiring all four components offers the strongest address assurance. A configuration requiring only two provides the most permissive match. The appropriate combination depends on your use case, the reliability of the data source for a given country, and your compliance obligations.

​
Layer 2 — Element-Level Similarity Threshold: How Closely Each Component Must Match

A similarity threshold is applied to each included address element individually. For example, at a 70% threshold, an input of “200 Kingslee Court” may match a provider record of “200 Kingsley Court”, because the character difference between the two values falls within the acceptable range. These two layers — which elements are required, and how strictly each must match — should be considered together when assessing the identity assurance quality of an address match for your use case.

​
Address Element Requirements by Country

Address structures vary significantly across markets. Elements that are reliably populated and structurally meaningful in one country may be absent, unstandardised, or unreliable in another. Where a data source cannot consistently populate a required address element for a given country, requiring that element will increase false negatives without improving identity assurance. FrankieOne can configure address element requirements at the country level for supported connectors. Illustrative example — country-level address element configuration:
CountryStreetCityStatePostal Code
United Arab Emirates✅✅❌❌
Netherlands✅✅❌✅
United States✅✅✅✅
Global default✅✅❌✅
In this example, a US address requires all four components. A UAE address requires only street and city, reflecting the structural characteristics of address data available in that market. Only included elements are assessed; excluded elements do not affect the match outcome.

​
Fuzziness and Data Sources

Each data source integrated with FrankieOne applies its own underlying matching and scoring model. The degree to which fuzziness thresholds are configurable varies by provider — some providers expose fine-grained control over individual element thresholds; others apply a fixed proprietary algorithm that cannot be modified. This means the effective fuzziness behaviour for a given verification depends not only on FrankieOne’s configuration, but on the specific characteristics of the data source being queried.
During your onboarding engagement, discuss the following with your FrankieOne account team for each data source in your workflow:
  • What fuzziness controls are available for name, DOB, and address?
  • What is the default threshold for each attribute, and is it appropriate for your use case?
  • Which address elements are required for each country you intend to verify in?
  • Does the data source apply any proprietary filtering (e.g., synonym tables, middle name tolerance) that may affect match behaviour beyond the configured threshold?
Understanding these specifics per data source is necessary to accurately predict verification outcomes and tune your workflow configuration before going live.

​
Summary: Key Configuration Decisions

The following questions should be answered for each data source in your workflow before going live:
AttributeKey Question
DOBMust the match be exact (100%), or is a tolerance threshold acceptable for your use case?
NameWhat threshold is applied to given name and surname? Is first-initial matching enabled? How are synonyms handled by this source?
Address — elementsWhich components (street, city, state, postal code) are required to match? Are country-specific overrides needed?
Address — thresholdsHow closely must each address component match? Is the same threshold applied to all elements, or are they weighted differently?

​
Next Steps

  • See eKYC Rulesets to understand how match counts feed into your verification pass/fail logic.
  • Contact your FrankieOne account team to review your fuzziness configuration for each active data source.