Sanctions name matching: understand fuzzy matches and evidence

Start with the original name and verified details

Enter the full name in SanctionsKit New screening, choose the subject type and add known country, birth-date or ID facts. Use the required available sources or policy. API requests send those facts in subject to POST /screenings, with sources or a versioned package and the policy reference when needed.

Keep the original spelling and script. There is no need to make a name look like a list entry or run a second fuzzy matcher first. SanctionsKit finds candidates and returns evidence about the comparison. That evidence gives the reviewer a starting point for the identity question.

What is fuzzy name matching?

Fuzzy matching looks beyond exactly identical text. It can find names that differ in order, spacing, spelling or script. A found record is still a candidate. Two people can have the same name; one person can also use several names.

OFAC's own tool uses a name-similarity score. SanctionsKit uses its own search and scoring methods, so the numbers are not interchangeable. A SanctionsKit score ranks evidence under a saved policy version. It is not the chance that a person is sanctioned or has done something wrong.

Separate listed aliases from software search aids

An alias supplied by the authority is part of the source record. A spelling or word order derived by software is a search aid. Keep the labels clear. A Latin spelling generated from another script should not look like an alias the authority published.

SanctionsKit accepts a full name without forcing it into Western first-name and last-name fields. It keeps original names and uses derived forms to help search. Transliteration support is limited. Test the names and scripts your team needs. The methodology explains how records become match evidence.

Know which spelling variants are supported

SanctionsKit compares German sharp-s (ß/ss), Arabic/Persian kaf (ك/ک) and yeh (ي/ی) variants. These can help find a record when a submitted name uses a different supported spelling, including a changed name order.

The original source name remains intact. Evidence marks a derived spelling comparison separately from an exact source-name match. This does not create a new official alias or prove identity. These specific comparisons also do not prove quality for every language. Include your relevant variations in testing.

Examples: a close name and an exact name both need review

These names are fictional. Mira Calder and Calder, Mira show a changed word order. North Lantern Trading and North Lantern Trading Ltd show a company suffix. If either pair produces a candidate, compare IDs and other source facts. The text alone does not prove that the two parties are the same.

Now imagine two people called Rowan Ellis with reliably different birth dates. Their exact names agree while their identity evidence conflicts. If a source gives only a birth year, though, it may still agree with a known full date. Use the false-positive checklist to record the difference between a conflict and a gap.

Treat broad aliases and missing facts with care

OFAC marks some generic aliases as weak because they can produce many false hits. A weak alias can still help alongside other facts. Preserve the source's label and explain what caused the candidate to appear, rather than making every alias look equally specific.

Compare ID values only when their types and issuers are suitable for comparison. A missing ID remains unknown. Do not guess nationality from a name, invent a full birth date or replace the original script to fill a form. The request guide lists the inputs the API accepts.

Ask for the next fact that could help

With retained inputs and unexpired evidence, SanctionsKit can suggest a missing country, more date detail or a typed ID to compare. It uses the facts present in candidate records to help a reviewer choose the next question in case review. Minimal-retention checks do not keep the inputs this checklist needs.

The checklist follows fixed rules and reports candidate-record counts, not identity probabilities. It favors the least extra birth-date detail that helps and does not ask for a document image. Collect only facts you are allowed to obtain, preferably from a verified record you already hold. The checklist cannot clear a subject or decide identity. The reviewer still interprets agreement, gaps and conflicts.

Investigate an unexpected result before changing settings

Open the saved check in Screening history. Inspect submitted facts, coverage, warnings and versions. In the case, use Potential matches to read matched fields, source names and conflicts. Correct verified input errors through the review flow, then review the new screening.

A score cannot rank a record that the search never found. Test whether expected candidates were found as well as how they scored. SanctionsKit bounds candidate retrieval for safe processing. If a request exceeds that bound, it returns an error instead of presenting a cut-short search as complete.

A permitted editor can choose Standard or Focused in Screening policies. Read the sensitivity guide before changing it. Compare known expected outcomes. Fewer returned candidates can mean less noise, missed useful matches, or both.

Synthetic examples test behavior; they do not prove recall for every real population. Use Sandbox to check how your application handles results and errors. Assess the actual names and source scope you need before changing a Production policy.

Measure missed matches as well as extra alerts

Save source, engine and policy versions with each test. Define expected candidates before inspecting the output. Count the expected records that were missed and the unrelated records that caused work. A smaller queue is not enough evidence that matching improved.

• Preserve original names and identify every transformation used in the comparison.
• Include positive and negative examples with independently established identities.
• Check weak aliases, common names, and partial dates as separate cases.
• Inspect candidate-bound errors and coverage failures rather than counting them as no matches.
• Review changed outcomes after source, engine, policy, or input changes.
• Document the limits of the sample before applying its findings to another population.

Do not turn one score into a universal clearance rule

OFAC does not recommend a single threshold for all searches. Its FAQ 250 leaves that choice to the facts, risk assessment and established practices. Understand what any vendor's score measures before using it in an approval rule.

SanctionsKit applies its matching policy and returns an explicit result. Your application handles it and your reviewers assess the evidence. Version records and saved results make it possible to explain which policy produced an earlier outcome when the system later changes.

Frequently asked questions