How Verification-of-Payee Algorithms Compare Account Names Before Payment: Exact/Fuzzy Matching, Normalisation, Match Categories, False Positives, Fraud Prevention and Human Choice

Quick answer: Verification of Payee (VoP) checks whether the account identifier a payer entered—typically an IBAN in the European scheme—corresponds with the intended payee name or another permitted identifying data element. The receiving payment service provider compares the payer’s supplied name with the name registered to the account and returns a structured result such as match, close match, no match or verification not possible. The paying bank shows that result before the payer authorises the transfer. The aim is to catch misdirected payments and certain forms of authorised push-payment fraud without pretending that a name-match algorithm can prove a transaction is safe.

Verification of Payee does not answer, “Is this payment legitimate?” It answers a narrower question: “Does the account identifier appear to belong to the person or entity the payer thinks they are paying?”

Jurisdiction boundary: this article uses the European Union’s Verification of Payee requirement and the European Payments Council (EPC) scheme as the main current public example, with UK Confirmation of Payee as useful background. Other jurisdictions use different designs.

Why this belongs in mathematics and algorithms

VoP combines string normalisation, exact and fuzzy matching, transliteration, classification thresholds, reference-data quality, API latency and human decision support. It is an entity-resolution problem operating under an unusual constraint: the answer must arrive before the customer presses Send.

The EU Instant Payments Regulation requires payer PSPs to offer a payee-verification service for credit transfers. In euro-area member states, the Verification of Payee requirement has applied since 9 October 2025. The ECB summarises the service as returning a result such as match, close match, no match or other before payment initiation. See ECB — Instant Payments Regulation.

1. The core inputs: account identifier plus intended payee

In the European scheme, a typical request contains:

• the payee’s IBAN;
• the payee name supplied by the payer;
• or, for some legal persons, another supported unambiguous identifier such as an LEI or tax identifier where available.

The payer’s PSP sends the request to the payee’s PSP, which compares it with the account-holder information in its own systems and returns the result.

The current EU legal text is Regulation (EU) 2024/886, which inserted the payee-verification requirements into the SEPA Regulation.

2. Exact matching is too brittle for real names

Suppose the bank’s registered account name is:

Alexandra Tan Wei Ling

The payer enters:

Alex Tan

An exact string comparison returns false. Yet the two records may still refer to the same person. Real payment systems therefore need controlled tolerance for abbreviations, word order, middle names, diacritics, punctuation and transliteration.

The EU regulation explicitly recognises that diacritics, transliteration and differences between habitual and formal names can create an “almost match” even when the intended payee is correct.

3. Normalisation removes formatting noise

A name engine can normalise inputs before comparison:

• case-folding;
• consistent punctuation treatment;
• whitespace compression;
• standard handling of accents/diacritics;
• corporate suffix handling;
• tokenisation of multi-part names;
• careful transliteration where necessary.

The key word is careful. Over-normalisation can erase meaningful differences. “ABC Trading Ltd” and “ABC Trading Bank Ltd” should not become identical merely because common words were stripped too aggressively.

4. Fuzzy similarity creates a score, not a verdict

A simplified name similarity engine might combine:

• edit-distance similarity;
• token overlap;
• initial-name equivalence;
• word-order tolerance;
• phonetic similarity;
• transliteration-aware comparison.

Conceptually:

Score = w₁×edit similarity + w₂×token similarity + w₃×alias/transliteration evidence + …

The score is then mapped into a response category. The production weights and thresholds should be tested and governed rather than published as universal constants.

5. Match categories create a decision boundary

The EPC Verification of Payee scheme uses response categories including:

• Match — supplied data correspond;
• Close Match — names almost match and the payer can be shown the account-holder name;
• No Match — supplied data do not match;
• Verification Check Not Possible / other — the check could not be completed in the expected way.

The EPC’s current published VOP rulebook v1.1 was published in March 2026 and becomes effective on 20 September 2026. As of this article’s date, 30 August 2026, the earlier scheme version remains the operative baseline while v1.1 is the imminent next version.

6. Close Match is a controlled information return

A close match is useful because it can help the payer recognise a minor variation without the bank silently overriding the payer’s input.

Example:

• Payer entered: Maria Gomez
• Registered name: Maria Elena Gomez

The system can return Close Match and show the registered name according to the scheme rules. The payer then decides whether that difference is acceptable.

The algorithm supports human choice rather than replacing it.

7. No Match should warn, not necessarily hard-block

The EU rule requires the payer to be informed that authorising after a mismatch can mean sending funds to an account not held by the intended payee. It also requires the service not to prevent the payer from authorising the transfer solely because of the verification step.

This creates a deliberate separation:

• algorithmic evidence: no match;
• human action: cancel, repair or proceed.

The system is therefore an informed-consent mechanism, not a universal transaction veto.

8. Legal entities can use stronger identifiers than names

Company names create many false positives because of trading names, legal suffixes and group structures. The EU framework allows certain channels to use other data elements that unambiguously identify the payee—such as an LEI or fiscal identifier—when the receiving PSP has the same identifier available.

This creates a hierarchy of evidence:

• name similarity;
• legal identifier match;
• account identifier match;
• entity reference data.

Where strong identifiers exist, they can reduce ambiguity that fuzzy name matching cannot eliminate.

9. Verification must happen before authorisation

The EU regulation requires the payer’s PSP to perform the verification immediately after the payer supplies the relevant data and before the payer is offered the opportunity to authorise the credit transfer.

This creates a latency constraint:

payment UX latency = local validation + request routing + receiving-PSP matching + response routing + display.

A statistically sophisticated matcher that takes twenty seconds can damage the payment journey. A fast but inaccurate matcher can flood users with warnings. The system must optimise both accuracy and response time.

10. API design is part of model reliability

The EPC VOP scheme uses inter-PSP APIs. Its 2026 API specification clarifies fields, character sets, timestamps and HTTP headers, and will become effective with rulebook v1.1 on 20 September 2026. See EPC VOP API Specifications v1.1.1.

A matching model can be correct while the service fails because:

• the request has a malformed IBAN;
• the wrong character set is used;
• a timestamp is inconsistent;
• the API response is lost;
• a retry creates conflicting results;
• the receiving PSP’s customer data are stale.

Model quality and message quality therefore need separate monitoring.

11. False positives and false negatives have different harms

A false mismatch warns on a legitimate payment. That can delay payroll, suppliers or family transfers and can train users to ignore future warnings.

A false match is more dangerous: the system tells a payer that a wrong or fraudulent account appears to belong to the intended payee.

The loss function is therefore asymmetric. A VoP system should not optimise raw classification accuracy without considering the consequences of each error type.

12. Verification of Payee is not proof against invoice fraud

Imagine a fraudster compromises a supplier’s email and instructs the payer to send money to an account held in the fraudster’s real legal name. VoP can correctly return a mismatch if the payer enters the supplier’s name.

But if the fraudster convinces the payer that the new account legitimately belongs to a different named entity, the name and account can match perfectly while the underlying story is false.

VoP therefore reduces one class of payment risk; it does not validate the commercial reason for the payment.

13. Corporate bulk payments create different friction

Checking thousands of supplier names one by one can create operational burden. EU rules permit non-consumer payment service users to opt out of receiving the verification service when submitting multiple payment orders as a package, while retaining the right to opt back in.

This is an important design lesson: a control that works well for one retail transfer may need a different interface for payroll or corporate batch files.

14. Singapore’s recipient-name display solves a related problem differently

Payment systems such as PayNow use recipient-name or proxy-resolution displays to help users confirm the intended recipient before sending. That is not identical to the EU VoP scheme, but it belongs to the same family of controls: show the payer more identity evidence before an irrevocable or fast payment leaves.

This is why implementation should preserve jurisdiction and scheme boundaries rather than forcing every recipient-confirmation mechanism into one global algorithm.

15. Creative-work lens: spell-check versus identity-check

A spell-checker can tell you that “Jon Smyth” resembles “John Smith.” It cannot tell you whether either person is the supplier you intended to pay. Verification of Payee works the same way: text similarity creates evidence, but account ownership and payer intent are separate layers.

16. The VoP algorithmic pipeline

1. Capture account identifier and intended payee data.
2. Validate IBAN or other identifier syntax.
3. Send a verification request to the payee PSP.
4. Retrieve the registered account-holder name or permitted identifier evidence.
5. Normalise both name representations.
6. Run exact and governed fuzzy/transliteration-aware comparison.
7. Map the result into Match / Close Match / No Match / Not Possible.
8. Return registered-name information where the scheme permits for Close Match.
9. Display the result before payment authorisation.
10. Record the payer’s decision to proceed, repair or cancel.
11. Log latency, errors and API outcome.
12. Backtest false matches and false mismatches.

17. Failure modes

• Exact-only matching. Legitimate abbreviations and transliterations generate false warnings.
• Over-normalisation. Distinct entities become falsely similar.
• Threshold worship. One similarity score is treated as proof of identity.
• Stale payee data. Account holder changed name but PSP reference data did not.
• Warning fatigue. Too many false mismatches train users to click through.
• False-match overconfidence. A match is treated as proof that the commercial instruction is genuine.
• Latency failure. Verification times out and the payment UX gives ambiguous guidance.
• Hard-block overreach. A mismatch result is confused with a mandatory fraud determination.

18. Diagnostics and falsifiers

• What percentage of legitimate payees produce Close Match rather than Match?
• Which name patterns create the most false mismatches?
• How often do users proceed after No Match?
• Are those proceeded payments disproportionately disputed?
• Can LEI or other legal identifiers reduce corporate false positives?
• What is median and tail API response time?
• Does the algorithm behave consistently across diacritics and transliterations?
• Can an independent test set reproduce the production match categories?

Suppose someone claims, “A Match means the payment is safe.” A falsifier is an authorised fraud in which the payer was socially engineered into paying a real account held in the correctly matched name. Identity consistency is not transaction legitimacy.

19. Verification and update triggers

• test common abbreviations, ordering and transliteration variants;
• separately measure false Match and false No Match;
• monitor API latency and timeout rates;
• revalidate thresholds after customer-data changes;
• update scheme/API handling when EPC versions change;
• retain result and payer-choice audit trails;
• review warning copy so users understand the meaning of each category;
• keep fraud controls separate from payee-name verification so one does not substitute for the other.

Research anchors

• Regulation (EU) 2024/886 — Instant Payments Regulation.
• ECB — Verification of Payee implementation overview.
• EPC — Verification of Payee Scheme Rulebook v1.1.
• EPC — VOP API Specifications v1.1.1.

The deeper lesson

Verification of Payee is the mathematics of useful uncertainty before payment. Exact strings are too brittle; fuzzy matching is too uncertain to become a verdict. Match categories compress the evidence into a form humans can act on. The strongest system therefore does not say, “We know this payment is safe.” It says, “Here is what the account-holder data says about the name you entered; here is how close the match is; now make the payment decision with better information than you had before.”

Educational note: This article explains public payment-verification and fraud-prevention concepts. It is not a live payee-verification service or legal advice.