How Bank Sanctions-Screening Algorithms Match Names and Ownership: Fuzzy Similarity, Transliteration, Aliases, OFAC 50 Percent Rule, False Positives and Human Review

Quick answer: sanctions screening compares customers, counterparties, payment parties and related entities with applicable sanctions data. Exact name matching is not enough because names can contain spelling variants, aliases, reordered words, abbreviations and transliterations from different writing systems. A robust screening engine therefore combines normalized names, fuzzy similarity, phonetic or transliteration-aware matching, dates of birth, addresses, identification numbers and other contextual attributes. It must also screen ownership relationships where the applicable sanctions regime treats an unlisted entity as blocked because of who owns it. Potential matches are routed for investigation; a similarity score by itself is not a legal conclusion.

A screening hit means “these records may refer to the same sanctioned person or entity.” It does not mean the system has proved that they do.

Safety and jurisdiction boundary: this article explains defensive compliance architecture. It intentionally does not publish bank-specific thresholds, suppression rules or techniques for evading sanctions filters. OFAC references are United States examples; other jurisdictions use different sanctions lists, ownership/control tests and legal requirements.

Why this belongs in mathematics

Sanctions screening is an entity-resolution problem. It uses string similarity, set matching, transliteration, graph ownership, classification, precision/recall trade-offs and human decision queues. It is also a strong example of why one identifier can never carry the whole meaning: “John Smith” is too broad, while a perfect passport number can be decisive when lawfully available.

The current FFIEC BSA/AML manual tells US bank examiners to assess whether a bank’s OFAC screening is risk-based, whether its criteria can identify misspellings and name derivations, whether potential matches are investigated appropriately, and whether false hits and list updates are handled effectively. See FFIEC — Office of Foreign Assets Control Overview.

1. Exact matching fails surprisingly quickly

Suppose the sanctions list contains:

Mohammed Abd al-Rahman

A bank record might contain:

• Mohammad Abdulrahman;
• Muhammad Abd Al Rahman;
• M. A. Rahman;
• a transliteration from Arabic using another spelling convention;
• an alias listed separately.

Exact equality would miss many plausible matches. The system therefore needs a controlled way to tolerate variation without treating every similar-looking name as identical.

2. Normalisation removes irrelevant formatting variation

Before fuzzy matching, names can be normalised:

• case-folding;
• standardising punctuation and whitespace;
• separating titles from core names;
• normalising diacritics where policy permits;
• handling common corporate suffixes;
• standardising ordering conventions carefully.

Normalisation should remove formatting noise without erasing meaningful distinctions. “ABC Holdings Ltd” and “ABC Bank Ltd” share words but are not interchangeable entities.

3. Fuzzy similarity measures edit distance, character order and sound

A fuzzy matcher assigns a similarity measure rather than requiring exact equality. Public OFAC search documentation itself demonstrates this principle: its list-search tool combines more than one character- and phonetic-similarity method when ranking potential name matches.

See OFAC’s public Sanctions List Search methodology FAQ.

The bank’s own production criteria should remain governed and private. The educational point is that several similarity measures can fail differently:

• character edit distance catches insertions/deletions;
• order-sensitive similarity catches nearby transpositions;
• phonetic methods catch names that sound similar but are spelled differently;
• token methods can compare multi-part names whose order varies.

4. Transliteration is a many-to-many mapping

Names written originally in Arabic, Cyrillic, Chinese or other scripts can be represented in Latin characters in several legitimate ways. There may be no one perfect transliteration.

A sanctions engine can therefore maintain:

• original script where available;
• official list transliterations;
• known aliases;
• standard transliteration variants;
• language/country metadata.

The safest system does not “correct” one spelling into a single canonical spelling and discard the alternatives. It preserves the uncertainty and uses other attributes to resolve it.

5. Names are weak identifiers; combinations are stronger

Two people can share the same name. A potential hit therefore needs additional evidence:

• date or year of birth;
• nationality;
• passport or national identifier;
• address;
• city/country;
• occupation or entity type;
• known associates or ownership;
• aliases and alternate spellings.

A simple evidence score can be conceptualised as:

Match evidence = name similarity + identifier consistency + date/location consistency + relationship evidence.

It is better interpreted as a routing score than as a probability of legal guilt.

6. False positives are inevitable in broad names

Suppose a sanctions list contains a very common surname and first name. Hundreds or thousands of legitimate customers may resemble that name. If the filter is extremely broad, analyst queues explode. If it is too narrow, real aliases can be missed.

The FFIEC manual explicitly notes that a high volume of false hits can indicate a need to review the interdiction programme and that screening sensitivity should reflect the bank’s risk, products and transaction volume.

This is the classic precision-recall trade-off:

• broader matching catches more possible variants but creates more false positives;
• narrower matching reduces analyst volume but can increase missed-match risk.

There is no universally safe public threshold. The correct setting is risk-based, tested and governed.

7. Human review resolves identity, not just spelling

An analyst reviewing a potential match should ask whether the customer and listed person are actually the same legal or natural person—not whether their names merely look alike.

Review can compare:

• name and aliases;
• date of birth;
• address and geography;
• government identifiers;
• entity registration details;
• ownership structure;
• transaction role;
• list programme and sanctions scope.

The FFIEC examination procedures tell examiners to sample potential OFAC matches and assess how the bank resolved them, including false hits. That makes analyst reasoning an auditable part of the system rather than an informal workaround.

8. Screening a transaction means screening parties, not just the account holder

A payment can involve:

• originator;
• beneficiary;
• originating bank;
• beneficiary bank;
• intermediaries;
• guarantors;
• beneficial owners;
• free-text references or vessels where relevant.

The FFIEC manual specifically expects banks to consider screening account parties beyond the named accountholder and to screen relevant transactions before execution according to the bank’s OFAC-risk framework.

This connects with ISO 20022 message validation: sanctions screening is only as good as the party information preserved in the payment message.

9. Ownership can block an entity even when the entity name is absent from the list

This is the most important reason sanctions screening cannot be reduced to string matching.

Under OFAC’s US 50 Percent Rule, an entity that is directly or indirectly owned 50% or more in the aggregate by one or more blocked persons is itself treated as blocked even if the entity is not separately named on the SDN list.

OFAC FAQ 399 makes the aggregation explicit: if blocked Person X owns 25% and blocked Person Y owns 25%, the entity reaches 50% aggregate blocked ownership. See OFAC FAQ 399 and the broader 50 Percent Rule guidance.

This is a graph problem, not a name problem.

10. Ownership graphs require recursive reasoning

Represent people and companies as nodes. Ownership stakes are directed weighted edges.

The engine must ask:

• Who owns this company directly?
• Which owners are themselves owned by blocked persons?
• Which indirect ownership paths count under the applicable rule?
• Do several blocked owners aggregate to the relevant threshold?
• Has the ownership changed since the last review?

A company can therefore move into a blocked state without its own name changing at all—only the graph changes.

11. Ownership and control are not identical under every regime

OFAC’s 50 Percent Rule is specifically an ownership rule; its FAQ states that control below the ownership threshold does not by itself automatically block an entity under that rule, although other sanctions authorities or future designation can still matter.

Other jurisdictions can use broader ownership-and-control concepts. A multi-jurisdiction bank therefore needs regime-specific legal logic rather than one global “50%” switch.

12. List updates are data events with immediate consequences

Sanctions lists change. New people and entities are added, names and identifiers are updated, and entities can be removed.

The screening system therefore needs:

• authoritative list source;
• version/timestamp;
• change detection;
• timely ingestion;
• rescreening policy for existing customers and relevant relationships;
• audit trail of which list version supported each decision.

The FFIEC manual expects timely list updates and risk-based rescreening of existing customers after additions or changes.

13. Third-party screening software does not transfer responsibility

A bank can use specialist sanctions software, but the bank still needs to understand what is screened, when lists update, how potential matches are escalated and whether testing demonstrates that the system works for the bank’s own data.

The FFIEC manual explicitly states that banks remain responsible for compliance when a third party performs OFAC screening and should maintain written agreements, controls and review procedures.

14. Model testing should include known difficult variants

A sanctions filter can pass a test set containing only exact names and still fail real operations. Testing should include controlled synthetic cases such as:

• spacing and punctuation changes;
• word-order changes;
• transliteration variants;
• known aliases;
• common-name false positives;
• missing secondary identifiers;
• ownership chains;
• list-version updates.

These cases are designed to test defensive robustness. Production sensitivity criteria should remain private and subject to independent validation.

15. Creative-work lens: The Bourne Identity and the danger of names without identity

The Bourne Identity is not a compliance source, but its identity theme offers a useful distinction: a name can be changed, borrowed or incomplete while the underlying person remains the same. Sanctions screening faces a bureaucratic version of that problem. The system must decide whether records with imperfect names point to the same underlying person or entity.

The creative work supplies the intuition. Real sanctions decisions require authoritative lists, identifiers, ownership and legal review.

16. The sanctions-screening algorithmic pipeline

1. Ingest authoritative sanctions-list versions.
2. Normalise names and identifiers without destroying meaningful distinctions.
3. Generate candidate matches using exact and governed fuzzy/transliteration-aware methods.
4. Compare aliases and secondary identifiers.
5. Screen all relevant payment/account parties.
6. Resolve ownership and beneficial-ownership graphs where required.
7. Apply regime-specific ownership/control legal rules.
8. Route potential hits for independent investigation.
9. Document false-hit or valid-match reasoning.
10. Block, reject, allow or escalate according to applicable legal instructions and authority.
11. Rescreen after list or ownership changes.
12. Independently test difficult name variants and graph cases.
13. Retain list version, inputs and decision evidence for auditability.

17. Failure modes

• Exact-match only. Transliteration and aliases disappear.
• Name-only matching. Common names generate false positives that identifiers could resolve.
• Over-normalisation. Distinct companies become indistinguishable after removing too much text.
• Threshold worship. A similarity score becomes a legal conclusion.
• List-only thinking. Owned entities are missed because their own names are absent.
• Stale-list risk. Screening uses yesterday’s list after a new designation.
• Ownership snapshot. A previously safe graph is assumed unchanged.
• Third-party opacity. Vendor screening is trusted without independent bank testing.

18. Diagnostics and falsifiers

• Can the system find controlled spelling and transliteration variants without exploding false hits?
• Can analysts explain why a potential name match was cleared?
• Which secondary identifier most often resolves common-name hits?
• Does the screening population include beneficiaries, guarantors and beneficial owners where required?
• How quickly does a new sanctions-list version reach production?
• Can the ownership engine aggregate blocked ownership correctly through multiple entities?
• Does the system distinguish US ownership rules from other jurisdictions’ control tests?
• Can independent testing reproduce the bank’s screening and escalation path?

Suppose someone claims, “The company is not on the sanctions list, so the transaction is clear.” A falsifier is an ownership graph showing that the company is directly or indirectly owned at a level that makes it blocked under the applicable regime. Name absence is not proof of legal absence.

19. Verification and update triggers

• test exact, alias and transliteration variants;
• sample false positives and valid hits;
• verify list-update latency;
• retest after screening-software changes;
• refresh ownership data after corporate events;
• review programme-specific legal rules when sanctions change;
• keep production sensitivity settings private but independently governed;
• retain decision evidence so a historical match can be reconstructed.

Connections across the finance-and-banking algorithms lane

• Customer identity matching — the general entity-resolution mathematics.
• AML transaction monitoring — a different compliance job that looks for suspicious behaviour rather than sanctioned identity.
• Correspondent-banking routing — cross-border paths contain multiple parties requiring compliant processing.
• LEI validation — structured entity identifiers can strengthen identity resolution but do not replace sanctions analysis.

Research anchors

• OFAC — A Framework for Compliance Commitments.
• FFIEC — OFAC Compliance Overview.
• FFIEC — OFAC Examination Procedures.
• OFAC — Entities Owned by Blocked Persons / 50 Percent Rule.
• OFAC — Public Sanctions List Search matching methodology.

The deeper lesson

Sanctions screening is the mathematics of identity under uncertainty. Names are noisy. Transliteration creates alternatives. Secondary identifiers reduce ambiguity. Ownership turns the problem into a graph. Human review reconnects similarity with legal reality. A strong system therefore does not ask only, “Does this name match?” It asks, “Do these records represent the same person or entity, which ownership relationships matter under this regime, and what evidence justifies the final decision?”

Educational note: This article explains defensive compliance and entity-resolution concepts. It is not legal advice and does not provide techniques for evading sanctions screening.