You asked
No. VoP and sanctions screening are different checks built for different questions, and they can return opposite answers on the exact same query. A VoP “no match” means the payee name doesn’t closely match the account holder’s registered name under EPC288-23’s close-match rules — it says nothing about whether that name appears on a sanctions list. Running VoP instead of a sanctions check, rather than alongside it, is how a genuinely sanctioned counterparty gets waved through a payment.
Two checks, one question each
Fitting, for a rubric literally called “You asked” — this one arrived close to word for word from a payments team. VoP answers “does the name on this payment instruction match who actually holds the account it’s going to” — a fraud and misdirection control, built for Regulation (EU) 2024/886, comparing one written name against one registered name under a defined set of close-match scenarios: exact, small edit distance, initial-plus-surname, phonetic. Sanctions screening answers a completely different question: “does this name, in any of the forms it’s known to use, appear on an official restricted list” — comparing against every list entry, every alias, every transliteration.
Nothing about the words “verification” or “payee” implies either check covers the other. A payment control built for speed at the point of transfer and a sanctions engine built for exhaustive recall are solving opposite problems: one is trying not to bother a legitimate payer with false alarms, the other is trying not to miss a real one.
Where the two checks genuinely diverge
Run “Sberbank” — a bank that has sat on OFAC’s SDN list since 2022 — through ordinary sanctions screening, and it matches at the maximum score against the full registered name on file, “Public Joint Stock Company Sberbank of Russia.” Run the identical query through VoP, and the result is NMTC — no match. Not a bug: VoP’s close-match rules compare the short payee name against the full legal name almost verbatim, and “Sberbank” alone doesn’t clear that bar the way a fuzzy sanctions search does.
The gap runs the other way too. A payee name can pass VoP with a close-match code precisely because it’s a near-exact string match to a registered account holder, while that same account holder has never been checked against a single sanctions source — VoP carries no sanctions data at all.
What actually covers both questions
Running both checks, not choosing between them. VoP for the account-holder-identity question a payment provider is regulated to ask before authorizing a transfer; sanctions screening — with score, source list and regulation cited — for the restricted-party question VoP was never built to answer.
A screening platform that offers both behind the same API means neither check has to stand in for the other: one call for VoP, one call for sanctions, one combined decision for the operator.
Reading a VoP result correctly
- A VoP code (MTCH/CMTC/NMTC/NOAP) describes name-to-account-holder closeness, not sanctions status
- A sanctions-clean VoP result is not evidence the counterparty is unsanctioned — VoP was never asked that question
- Run VoP and sanctions screening as two checks, not as a substitute for each other
- Where a name diverges between the two, trust each result only on the question it actually answers