EBA/GL/2024/14: The EU Guidelines That Raise Sanctions-Screening Expectations from 30 December 2025

If your sanctions screening system only does exact name matching, the European Banking Authority has raised the bar. Since the EBA guidelines (EBA/GL/2024/14 & GL/2024/15) began to apply on 30 December 2025, exact-match-only workflows may create regulatory risk under those guidelines for covered institutions.

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 now that it applies. If you are a CTO, compliance engineer, or technical decision-maker at a fintech, these are the guidelines 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 apply from 30 December 2025 on a comply-or-explain basis. They apply across the entire EU/EEA and are addressed to national competent authorities, which are expected to integrate them into their supervisory frameworks or explain why they do not. In practice, this raises supervisory expectations for the institutions they cover, without being a directly binding regulation or directive.

These guidelines sit 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 name-matching expectation

The most consequential technical implication of EBA/GL/2024/14 is that name screening systems need to use techniques beyond exact string matching. Effective screening under the guidelines means being able to identify 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 the kind of gap supervisors expect firms to close.

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 guidelines expect 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 guidelines' reach if they serve EU customers through passporting or direct provision of services.

What supports an EBA-aligned fuzzy matching workflow?

Since the guidelines are algorithm-agnostic, teams should focus on documented outcomes rather than a single implementation. The industry has converged on a set of techniques that can support defensible fuzzy matching. Your screening system should employ multiple 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 "Aleksadr Petrov" (a typo) as similar to "Aleksandr Petrov" (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

This is not a distant concern — the guidelines already apply. 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 adopted and documented suitable controls. Being able to show that you adopted fuzzy matching before the deadline can support a stronger audit narrative.
• 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 supports aligned workflows

Verifex screens against the name-variation categories the guidelines address. What follows is the retrieval and evidence behaviour a compliance team can rely on and verify; the algorithm-level detail, and the date it was measured, live on the matching methodology page, because that detail changes as the engine does:

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. Corroborating and contradicting identity evidence. A name similarity is a candidate, not an identity. Contextual fields — date of birth, country, government or registration identifiers — are recorded as evidence that either corroborates or contradicts the match, and a name-only candidate is never reported as a confirmed identity. Screening runs deterministically and offline: no customer screening data is sent to a large language model.

This is what runs in production today, processing real screening requests. The latest internal benchmark numbers are 0 severe false positives across 5,000 adversarial negatives (95% ci ≤ 0.077%) Recall is the most critical metric for compliance because it measures how many true matches the system catches — this is a synthetic, self-administered benchmark, disclosed in full (including remaining false negatives and precision gaps) on the benchmark page. 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_your_api_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 now that the guidelines apply:

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 (Aleksadr/Aleksandr), 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 guidelines apply 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 guidelines expect 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 set out in EBA guidelines, applied on a comply-or-explain basis with supervisory 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 should upgrade without delay, because the guidelines already apply.

The cost of upgrading can be modest compared to the cost of regulatory gaps. A modern sanctions screening API with fuzzy matching built in can be integrated incrementally, tested against known cases, and documented before a supervisory review makes it urgent.

Frequently asked questions