EBA/GL/2024/14: The EU Regulation That Mandates Fuzzy Matching by December 2026

If your sanctions screening system only does exact name matching, the European Banking Authority has just given you a deadline: December 2026. After that date, exact-match-only screening is explicitly non-compliant under the new EBA guidelines. This is not a recommendation. It is a regulatory requirement that applies to every financial institution operating in the EU and EEA.

This article breaks down what EBA/GL/2024/14 says, who it applies to, what technical capabilities your screening system needs, and how to prepare before the deadline. If you are a CTO, compliance engineer, or technical decision-maker at a fintech, this is the regulation you need to understand right now.

What is EBA/GL/2024/14?

EBA/GL/2024/14 is a set of guidelines published by the European Banking Authority in 2024 as part of the broader EU Anti-Money Laundering (AML) legislative package. The guidelines address the use of remote customer onboarding solutions and, more broadly, the technical standards that financial institutions must meet for customer due diligence and ongoing monitoring.

The guidelines become effective in December 2026. They apply across the entire EU/EEA and are binding on national competent authorities, which means local regulators in each member state must integrate them into their supervisory frameworks. In practice, this makes them as enforceable as a directive for the institutions they cover.

The regulation sits within a larger context. The EU has been overhauling its AML framework since 2020, culminating in the creation of the Anti-Money Laundering Authority (AMLA), the new AML Regulation (AMLR), and the Sixth Anti-Money Laundering Directive (AMLD6). EBA/GL/2024/14 is the technical implementation layer that specifies how institutions should actually perform screening. It bridges the gap between high-level policy ("screen your customers against sanctions lists") and operational reality ("here is what your screening system must be capable of").

The fuzzy matching mandate

The most consequential technical requirement in EBA/GL/2024/14 is the mandate for name screening systems to use techniques beyond exact string matching. The guidelines specifically state that screening systems must be capable of identifying matches despite variations in name spelling, transliterations from non-Latin scripts, phonetic equivalents, and common abbreviations.

This is not buried in a footnote. It is a core requirement. The EBA has recognized what practitioners have known for years: exact-match-only screening produces an unacceptable rate of false negatives. When a sanctioned individual is listed as "Muammar al-Qadhafi" and your customer enters "Moammar Gaddafi," an exact-match system returns zero hits. That is a compliance failure, and under the new guidelines, it is also a regulatory violation.

The guidelines do not prescribe specific algorithms. They do not mandate Jaro-Winkler over Levenshtein, or Soundex over Double Metaphone. What they require is demonstrable capability. Your screening system must be able to show, under audit, that it can catch name variants that an exact-match system would miss. The burden of proof is on the institution.

Specifically, the regulation expects screening systems to handle:

• Spelling variations. Mohammed vs. Muhammad vs. Mohamed. These are not typos. They are legitimate transliterations of the same Arabic name, and your system must recognize them as potential matches.
• Transliterations from non-Latin scripts. Names originally written in Arabic, Cyrillic, Chinese, or other scripts can have multiple valid Latin-alphabet representations. A screening system must handle this inherent ambiguity.
• Phonetic equivalents. Names that sound the same but are spelled differently. "Schmidt" and "Smith" share phonetic roots. "Khadafi" and "Gaddafi" are phonetic variants. The system must catch these.
• Name reordering. Different cultures place given names and family names in different orders. "Kim Jong Un" might appear as "Jong Un Kim" in some databases. Screening must be order-independent.
• Common abbreviations and initials. "Wm." for "William," "Chas." for "Charles," or "Intl." for "International" in entity names. The system should not miss a match because of standard abbreviations.

Who must comply?

The scope of EBA/GL/2024/14 is broad. It applies to all "obliged entities" under the EU AML framework, which includes:

• Credit institutions. Banks and building societies operating in the EU/EEA, including branches of third-country banks.
• Payment institutions. Any entity licensed under the Payment Services Directive (PSD2) to provide payment services in the EU.
• E-money institutions. Issuers of electronic money, including prepaid card providers and digital wallet operators.
• Crypto asset service providers (CASPs). Under the Markets in Crypto-Assets Regulation (MiCA), CASPs are now subject to the same AML obligations as traditional financial institutions. If you operate a crypto exchange, custody service, or DeFi gateway serving EU customers, you must comply.
• Investment firms. Broker-dealers, asset managers, and other firms authorized under MiFID II.
• Insurance undertakings. Life insurance providers and intermediaries distributing life insurance products.

The critical detail: you do not need to be headquartered in the EU. If you serve EU/EEA customers, you are in scope. A U.S.-based fintech with European users, a Singapore-based crypto exchange accepting EU sign-ups, or a UK payment processor still handling euro-denominated transactions post-Brexit -- all fall under the regulation's reach if they serve EU customers through passporting or direct provision of services.

What counts as compliant fuzzy matching?

Since the guidelines are algorithm-agnostic, compliance is about outcomes, not implementations. That said, the industry has converged on a set of techniques that regulators consider adequate. Your screening system should employ at least two of the following approaches in combination:

Phonetic matching converts names to codes based on pronunciation, so names that sound alike produce identical or similar codes. Established algorithms include Soundex (the oldest, dating back to the 1920s), Metaphone and Double Metaphone (more accurate for English), and Beider-Morse (designed specifically for cross-language name matching). A system using phonetic matching would correctly identify "Qadhafi" and "Gaddafi" as potential matches because both produce similar phonetic codes.

String similarity algorithms measure how many edits are needed to transform one name into another. Jaro-Winkler distance is particularly well-suited to name matching because it gives extra weight to the beginning of strings, where names tend to be most distinctive. Levenshtein distance counts the minimum number of insertions, deletions, and substitutions needed. These algorithms would catch "Vladmir Putin" (a typo) as similar to "Vladimir Putin" (the correct spelling).

Token-based matching breaks names into individual words (tokens) and compares them independently, which handles name reordering and partial matches. TF-IDF (Term Frequency-Inverse Document Frequency) weighting is particularly effective here because it assigns lower importance to common name tokens like "Mohammed" or "International" and higher importance to distinctive tokens. Soft TF-IDF extends this by using string similarity within token comparisons, catching both reordering and spelling variations simultaneously.

N-gram matching breaks names into overlapping character sequences (bigrams, trigrams) and compares the overlap between two names. This is robust against transpositions and small spelling differences. A name like "Muhammad" and "Muhammed" would share most of their trigrams despite the spelling difference.

The strongest implementations combine multiple techniques. A phonetic match alone might produce too many false positives. A Levenshtein match alone might miss transliterations where the edit distance is large. But phonetic matching plus token-based similarity plus string distance, each contributing to a composite confidence score, provides robust coverage across the full range of name variations.

Why this matters for developers right now

December 2026 sounds distant. It is not. If you are building a fintech product that serves EU customers, the compliance requirement affects your technical architecture and vendor selection today.

Here is why timing matters:

• Vendor evaluation takes months. Evaluating sanctions screening providers, running proof-of-concept integrations, and getting procurement approval is a 3-6 month process at most organizations. If you start in Q3 2026, you are cutting it dangerously close.
• Integration is not trivial. Replacing a screening provider or adding fuzzy matching capabilities to an existing integration requires code changes, testing, and deployment. For regulated entities, changes to compliance-critical systems also require internal review and sign-off.
• Regulators audit retrospectively. When regulators examine your screening system, they will look at when you became compliant, not just whether you are compliant on the audit date. Being able to show that you adopted compliant screening well before the deadline demonstrates good faith.
• Your competitors are already moving. The largest banks and payment processors began upgrading their screening systems in 2025. If you wait until late 2026, you risk being the last institution in your market still running exact-match-only screening.

The most practical step you can take today is to audit your current screening provider. Ask them a direct question: "Can your system demonstrate, under regulatory audit, that it catches name variants including transliterations, phonetic equivalents, and common misspellings?" If the answer is anything other than an unqualified "yes" with documentation to back it up, you need to start evaluating alternatives.

How Verifex is already compliant

Verifex was built from the ground up to exceed the matching requirements in EBA/GL/2024/14. The screening engine uses a 4-stage matching pipeline that covers every category of name variation the regulation addresses:

1. Exact matching with token reordering. The first stage normalizes names (lowercasing, diacritic removal, whitespace normalization) and checks against all known aliases. Tokens are compared in all orderings, so "Kim Jong Un" matches "Jong Un Kim" automatically.
2. Fuzzy matching with Soft TF-IDF, Jaro-Winkler, and Monge-Elkan. The second stage uses a composite algorithm that combines token-level similarity (Soft TF-IDF) with character-level similarity (Jaro-Winkler) and set-level matching (Monge-Elkan). IDF weighting ensures that common names like "Mohammed" do not dominate the score while distinctive names get appropriate weight.
3. Phonetic matching with Double Metaphone. The third stage generates phonetic codes for both the query and all sanctions entries, catching transliterations that fuzzy matching might miss. "Qadhafi" and "Gaddafi" produce matching phonetic codes despite having large edit distances.
4. LLM-powered verification. The fourth stage uses a large language model to verify candidate matches in context, reducing false positives by applying world knowledge and semantic understanding that purely algorithmic approaches lack.

This pipeline is not theoretical. It runs in production today, processing real screening requests. The published benchmark numbers: F1 score 91.1%, recall 98.7%, precision 84.5%. Recall is the most critical metric for compliance because it measures how many true matches the system catches. At 98.7%, Verifex misses fewer than 2 in 100 sanctioned individuals. For a deeper look at how fuzzy matching works technically, see our guide to fuzzy matching for sanctions screening.

Here is what a screening request looks like:

const response = await fetch("https://api.verifex.dev/v1/screen", {
  method: "POST",
  headers: {
    "Authorization": "Bearer vfx_sk_live_your_key",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "Moammar Gaddafi",
    type: "person",
  }),
});

const result = await response.json();
// result.matches includes fuzzy, phonetic, and exact matches
// Each match has a confidence score and match type
console.log(result.matches[0]);
// {
//   name: "Muammar Muhammad Abu Minyar al-QADHAFI",
//   score: 0.87,
//   matchType: "phonetic",
//   source: "OFAC SDN",
//   entityId: "...",
// }

The API handles all four matching stages internally. You do not need to implement fuzzy matching yourself or configure phonetic algorithms. A single API call returns scored matches from all stages, deduplicated and sorted by confidence.

Preparing for compliance: a practical checklist

Whether you use Verifex or another provider, here is what you should do before December 2026:

1. Audit your current screening provider. Request documentation of their matching methodology. Specifically ask whether they support fuzzy matching, phonetic matching, and transliteration handling. If they cannot provide clear technical documentation, that is a red flag.
2. Test with known variants. Create a test suite of name pairs that your system should match. Include transliterations (Gaddafi/Qaddafi/Qadhafi), common misspellings (Vladmir/Vladimir), phonetic variants (Schmidt/Smith), and name reorderings (Kim Jong Un/Jong Un Kim). Run these against your current system and document what it catches and what it misses.
3. Evaluate match quality metrics. Ask your provider for published benchmark results. The key metrics are recall (percentage of true matches caught), precision (percentage of flagged matches that are actually true), and F1 score (harmonic mean of the two). If your provider does not publish benchmarks, ask why. For context on what good numbers look like, read our guide to OFAC sanctions screening.
4. Verify list coverage and sync frequency. The regulation applies to screening against all relevant sanctions lists, not just OFAC. Ensure your provider covers EU consolidated sanctions, UN Security Council sanctions, UK HMT, and any other lists relevant to your jurisdictions. Check how frequently the lists are updated. Daily is the minimum standard; hourly or real-time is better.
5. Document your matching configuration. Regulators want to see that you have made deliberate choices about your matching thresholds. Document what confidence score triggers a block, what triggers a manual review, and what is auto-approved. Be prepared to justify these thresholds.
6. Plan your integration timeline. If you need to switch providers, budget 2-4 weeks for API integration, 2-4 weeks for testing and validation, and 2-4 weeks for internal review and approval. Start no later than Q2 2026 to have comfortable margin.
7. Build an audit trail. The regulation requires that screening decisions be documented and retrievable. Ensure your system logs every screening request, the results returned, the decision made (block, review, approve), and who made that decision. This audit trail must be available for regulatory inspection.

What happens if you do not comply?

The enforcement consequences vary by member state, but the general framework is clear. National competent authorities can impose administrative penalties, require remediation plans, and in severe cases, restrict or revoke operating licenses. For payment institutions and e-money institutions, non-compliance with AML screening requirements can result in fines calculated as a percentage of annual turnover.

Beyond direct penalties, there is reputational risk. Regulatory actions are typically published, and being cited for inadequate sanctions screening is the kind of headline that damages customer trust and partnership opportunities. For startups seeking to partner with established banks or payment processors, demonstrating robust screening capabilities is increasingly a precondition for due diligence approval.

There is also personal liability. Under AMLD6, senior managers can be held personally responsible for systemic compliance failures. If your institution's screening system misses a sanctioned entity because it only does exact matching, and that was a known limitation that was not addressed, the responsible officers face individual accountability.

The bottom line

EBA/GL/2024/14 is not a radical departure. It codifies what the best-run compliance programs have been doing for years. Fuzzy matching, phonetic algorithms, and transliteration handling are not new technologies. What is new is that they are now explicitly required by regulation, with a hard deadline and enforcement consequences.

If your screening system already uses fuzzy matching, you are likely in good shape. Verify your matching methodology, document it, and ensure you can demonstrate it under audit. If your system only does exact matching, you have eight months to upgrade. That is enough time, but only if you start now.

The cost of upgrading is minimal compared to the cost of non-compliance. A modern sanctions screening API with fuzzy matching built in costs a fraction of what a single regulatory fine would be. The technical integration is measured in days, not months. The only real obstacle is inertia.