Verification of Payee: Engineering the Name-Matching Service Behind the Instant Payments Regulation

Verification of Payee is described in the regulation as a consumer-protection measure. To the people who have to build it, it is a fuzzy string-matching service with a latency budget measured in seconds and a false-positive rate that decides whether legitimate payments get through.

The Instant Payments Regulation, Regulation (EU) 2024/886, added Verification of Payee (VoP) to the credit-transfer flow. Since 9 October 2025, payment service providers in the euro area have had to offer payers a check of the payee name against the account identifier before the payment is authorised. Providers in non-euro member states have until 9 July 2027. Most of the commentary treats this as a compliance date to hit. The engineering reality is narrower and harder: you are being asked to run a name-matching decision inside the payment initiation flow, return one of a small set of results before the payer commits, and get the matching logic right enough that you neither wave through fraud nor block honest payments. That last part is the whole job.

What the service actually has to return

The European Payments Council’s VoP Scheme Rulebook, in force since 5 October 2025, standardises the answer the responding provider sends back. There are four outcomes: a full match, a close match, no match, and a case where verification cannot be performed at all. In the scheme’s message codes these are MTCH, CMTC, NMTC and NOAP. That is the entire vocabulary your matching engine is allowed to speak.

The interesting one is close match. A full match and a no-match are, conceptually, easy: the name is right or it is unrecognisable. Close match is the category that carries the fraud-prevention value and the customer-experience risk at the same time. It fires when the supplied name is nearly the account holder’s name — a missing middle name, a company abbreviated, a transposed word — and in that case the scheme returns the actual account holder’s name to the payer so they can judge for themselves. Your engine’s real design question is not “does this match” but “where do I draw the two lines that separate match from close match from no match.” Get those thresholds wrong and every downstream problem follows. How those three results land in the interface is a separate discipline, and one I have written about on the customer-journey side.

Why exact matching is the wrong instinct

The first engineering instinct is usually a normalise-and-compare: lower-case both strings, strip punctuation, compare for equality. It fails immediately against real name data. “Robert King” versus “Rob King”. “Sixteen Pillars Ltd” versus “Sixteen Pillars Limited”. “J. King” versus “John King”. “Muller” versus “Müller”. A payer who types the name exactly as it appears on an invoice will routinely differ from the name a bank holds on the account, because the two were captured by different people, in different systems, under different formatting conventions, sometimes in different scripts. An exact-match engine converts all of that legitimate variation into no-match responses, trains payers to ignore the warning, and defeats the purpose of the regulation within a week.

So the service has to be fuzzy. The EPC’s own guidance points implementers at established techniques — normalisation, tokenisation, edit distance, phonetic matching — without mandating a single algorithm, which sensibly leaves the choice to the provider. That freedom is also the trap. The algorithm is where your false-positive and false-negative rates are actually set, and there is no rulebook clause that will save you from choosing badly.

A worked minimum

Here is the shape of the decision, stripped to its core. It is not production code — it has no directory lookup, no message framing, no error handling — but it makes the three-way threshold decision concrete, which is the part teams argue about in the abstract and should instead argue about against data.

from rapidfuzz import fuzz

# Two thresholds define the three outcomes. These are illustrative;
# the correct values come from tuning against your own name data,
# not from a blog post.
MATCH_THRESHOLD = 90.0      # at or above this: full match (MTCH)
CLOSE_THRESHOLD = 70.0      # between the two: close match (CMTC)

BUSINESS_SUFFIXES = {"ltd", "limited", "plc", "gmbh", "sarl", "bv", "oy"}

def normalise(name: str) -> str:
    # Lower-case, drop common legal suffixes, collapse whitespace.
    tokens = [t for t in name.lower().split() if t not in BUSINESS_SUFFIXES]
    return " ".join(tokens)

def verify_payee(supplied: str, on_account: str) -> str:
    a, b = normalise(supplied), normalise(on_account)
    # token_sort_ratio tolerates word re-ordering and minor edits,
    # which is most of the legitimate variation you will see.
    score = fuzz.token_sort_ratio(a, b)
    if score >= MATCH_THRESHOLD:
        return "MTCH"
    if score >= CLOSE_THRESHOLD:
        return "CMTC"
    return "NMTC"

Everything that matters is in the two numbers and the normalisation step. Raise the match threshold and you push more genuine payees into close match, generating warnings on payments that are fine and slowly eroding the payer’s trust in the warning. Lower it and you start returning full match on names that are merely similar, which is precisely the gap an authorised-push-payment fraudster wants. The suffix list, the decision to sort tokens, whether you add phonetic keys for common name variants — each of those quietly moves your error rates. None of them can be set correctly from first principles. They are set by running the engine over a representative sample of real name pairs and reading the false-positive and false-negative curves.

The latency budget is not optional

The regulation puts this check between the payer entering the details and authorising the payment, and instant payments are supposed to complete in seconds. That collapses your matching decision into a synchronous, real-time call — resolve the payee’s provider through the routing directory, send the request, run the match, return the code, all fast enough that the payer does not abandon. A matching algorithm that is accurate but slow is not usable here. This is where the algorithm choice and the architecture stop being separable concerns; I have set out the service architecture for keeping name matching inside that window separately, and the routing and verification-mechanism connection is the other half of the same problem. The point to hold on to is that accuracy and latency are jointly constrained: you cannot tune one to perfection and treat the other as someone else’s job.

What to actually decide

If you are a provider in a non-euro member state, the 9 July 2027 date gives you room the euro-area firms did not have, and the non-euro member-state timeline is worth mapping against your own build. Use it to do the one thing that decides whether this service helps or harms: assemble a labelled set of real name pairs — matches and near-misses from your own book — and tune the two thresholds against them before you go live, then keep re-tuning as the data teaches you where the engine is wrong.

A Verification of Payee service that is too strict blocks payments people meant to make. One that is too loose passes the fraud it was built to stop. The regulation gives you the outcomes to return and the deadline to return them by. It does not, and cannot, give you the threshold that is right for your names. That number is the deliverable, and it is the one nobody outside your organisation can set for you.