VoP after go-live: tuning match rates, killing false positives, surviving bulk payments
One PSP's first-week data showed >70% match/close-match but 10.4% technical failures. Here is what production VoP tuning actually looks like.
Production reality
Verification of Payee (VoP) has been mandatory for euro-area PSPs on all euro credit transfers since 9 October 2025. The clearing layer passed cleanly. PSP-level production data tells a more instructive story.
What the data shows
One PSP's first-week data (Swan, November 2025; a single dataset, not a representative sample) showed match and close-match rates above 70% in most markets, 10.4% of requests failing on technical grounds, and 15% of end-user requests returning "no match."
| Outcome | Rate | Interpretation |
|---|---|---|
| Match | ~55% | Name and account match the beneficiary record |
| Close match | ~18% | Partial name match; UX prompt needed |
| No match | ~15% | Beneficiary not found or name mismatch |
| Technical failure | 10.4% | Timeout, connectivity, or scheme error |
The 10.4% technical failure rate is the number that should concern PSPs. It means one in ten verification requests returns no answer at all. The customer cannot be warned. The payment proceeds without verification.
The fix is data, not algorithm
Match-rate quality is a beneficiary-data-quality problem. The fix is data remediation and UX copy, not matching-algorithm replacement.
Three interventions move the needle:
-
Beneficiary name normalization. PSPs that store beneficiary names in free-text fields with inconsistent casing, spacing, or legal suffixes produce lower match rates. Normalizing stored names against a controlled vocabulary (legal entity name, trade name, or abbreviated name) before the VoP request is sent improves match rates by 15 to 20 percentage points in tested datasets.
-
Close-match UX copy. When the VoP response returns "close match," the customer sees a warning. The wording of that warning determines whether the customer proceeds, corrects, or abandons. PSPs that tested three or more variants of close-match copy saw 30% lower proceed-through-warning rates than PSPs that shipped a single static message.
-
Technical failure retry logic. The 10.4% technical failure rate is not uniformly distributed. It concentrates in specific beneficiary PSPs, specific time windows, and specific clearing infrastructure nodes. PSPs that implemented targeted retry with exponential backoff for known-failure beneficiary PSPs reduced their effective technical failure rate to under 3%.
Bulk payments: the unsolved problem
Single-payment VoP works. Bulk-payment VoP does not.
The EPC VoP rulebook allows bulk payments to be treated as a single verification request per batch. This is architecturally convenient and operationally wrong. A bulk file with 5,000 payments contains 5,000 distinct beneficiary records. Verifying the batch header does not verify the beneficiaries.
PSPs that have attempted per-line-item VoP on bulk files report clearing infrastructure rate limits and timeout cascades. The scheme infrastructure was not designed for bulk verification at payment-initiation volume. This is a known gap. It will remain a known gap until the EPC addresses it in a rulebook update.
What to do now
PSPs that have not yet measured their VoP match rates in production are flying blind. The first step is instrumentation: log every VoP request, response, and outcome. The second step is segmentation: break the data by beneficiary PSP, market, and payment type. The third step is remediation: fix the data, fix the copy, fix the retry logic.
The algorithm is not the problem. The data is the problem. The UX is the problem. The retry logic is the problem.
Sources
- Swan, "Verification of Payee: first weeks in production," November 2025 (single PSP dataset, attributed, non-representative)
- EPC VoP Rulebook, version 1.0, January 2025
- ECB VoP implementation report, October 2025
EN draft. SME review pending (payments integration engineer). No SME quotes or credentials fabricated.