It is tempting to read Verification of Payee as a customer-experience nicety: a reassuring tick before a transfer. Under the Instant Payments Regulation it is more than that. The regulation links the obligation to offer the check to where the loss falls when a euro payment reaches the wrong account, which turns VoP from an optional safeguard into a liability question.
Why liability is attached to the check
The logic is straightforward. If a PSP must warn a payer that a name does not match the account, and it fails to do so, then the payer was deprived of the information they needed to stop the payment. That failure is hard to push back onto the customer.
- If the check was never offered when it should have been, the PSP is exposed.
- If the check ran, returned a no match, and the payer was clearly warned but proceeded anyway, the picture is different.
- If the warning was buried, ambiguous, or shown after authorisation, the PSP's position weakens.
What good practice looks like
Because liability can hinge on what the payer was shown and when, the implementation details matter as much as the check itself.
- 1 Run the check before the payer authorises, not after.
- 2 Present the outcome in plain language, with a clear warning on close match and no match.
- 3 Record the outcome shown and the payer's decision against the transaction.
- 4 Keep those records long enough to support dispute and refund handling.
Evidence wins disputes
When a customer claims they were not warned, your logs are the answer. Storing the exact outcome surfaced to the payer, the timestamp, and their subsequent choice is the difference between a defensible decision and an expensive one.
This is not legal advice, and national implementations vary — but the direction is clear: treat VoP as a liability-relevant control and build the logging to match. RoxPay returns standardised outcomes and an auditable record for exactly this reason.