Verification of Payee compares the intended recipient’s name with the account details used for a bank transfer. It helps detect mistakes and some fraud attempts, but a matching result does not establish that an invoice is genuine, a supplier is honest or the payment is appropriate. Treat it as one check in a payment decision.
The distinction matters most when someone asks you to change bank details or hurry a transfer. A successful account-name check can be useful evidence about the destination while leaving the underlying request completely unverified. This guide explains how to respond to that evidence without asking it to prove more than it can.
Know what is being compared
The payment provider takes the recipient information supplied by the payer and checks it against information associated with the destination account. The practical purpose is to identify whether the name and account details correspond before the transfer is initiated.
The ECB’s 10 March 2025 announcement described the Eurosystem’s planned Verification of Payee service and the euro-area deadline of 9 October 2025. It explained that the check would support both instant euro payments and ordinary SEPA credit transfers.
That announcement concerns a payment-infrastructure service and the relevant regulatory obligations. It does not say that every account in every country participates in an identical way. Availability, interface wording and handling of particular situations should be checked with the provider you actually use.
For the person paying an invoice, the useful question is whether the supplied name matches the account intended to receive the money. It is not whether the name looks familiar in the email that carried the invoice.
A match answers a narrow question
Imagine that a fraudster persuades a customer to pay a fee for a nonexistent service. The bank account may genuinely belong to the named recipient. A name match would not establish that the service exists.
Likewise, an employee could select a real supplier’s account for an invoice that has already been paid. The name check may succeed even though the transfer is a duplicate. The system cannot infer the company’s purchasing decision from the name alone.
Separate destination verification from transaction approval. Destination verification asks where the money is going. Transaction approval asks whether the company owes the money, whether the amount is correct and whether the proposed timing is authorised.
This is not a reason to ignore a match. It is a reason to use it accurately. A useful control can still have a limited scope, and understanding that scope makes the rest of the payment process easier to design.
Handle a mismatch before trying to make it disappear
A mismatch can have an innocent explanation: an incomplete legal name, a trading name, a typographical error or a different account holder than expected. It can also expose altered payment details. Do not choose the reassuring explanation without checking it.
Return to the original supplier record or an independently established contact route. Confirm the legal account-holder name and the account details. If the invoice requests payment to a different entity, ask why and obtain appropriate documentation before proceeding.
Avoid repeatedly changing the name until the interface produces a match. That can turn a warning into a guessing exercise. The correct name should come from verified business information, not from experimentation with the bank’s response.
Record the result and the reason for any correction. A future reviewer should be able to distinguish a spelling correction from a decision to pay a different legal entity.
Treat unavailable checks as missing evidence
A provider may be unable to complete a check in a particular situation. That is not equivalent to a match, and it is not proof of fraud. It means that this source of evidence is unavailable.
Use the provider’s explanation to determine whether the issue is temporary, outside coverage or related to the supplied details. If the payment is urgent, apply an agreed exception process rather than allowing urgency to erase the uncertainty.
| Result or situation | Sensible next step | Unsupported conclusion |
|---|---|---|
| Clear match | Continue other invoice checks | The transaction is genuine |
| Similar name or suggested correction | Verify the expected legal name | Any suggested name is acceptable |
| Mismatch | Confirm details independently | It is only a harmless typo |
| Check unavailable | Establish why and use other controls | The account has been validated |
| Newly changed details | Confirm through an existing contact route | A matching new account proves the change was authorised |
Provider wording varies. Use the actual meaning described in your bank’s guidance rather than assuming that every interface uses these labels.
Verify changed bank details outside the incoming message
An email thread can look authentic because an account has been compromised or because the attacker has copied familiar details. Calling the telephone number in the same suspicious message does not create an independent check.
Use a number already held in a trusted supplier record, or another route established before the change. Ask the known contact to confirm the change and the payment details. For a significant payment, follow the business’s approval process for changing supplier master data.
Do not read out confidential authentication codes or follow remote-access instructions during such a call. The purpose is to verify the supplier’s payment information, not to let someone operate your bank account.
If the usual contact is unavailable, record the payment as awaiting verification. A real deadline may require escalation, but the person approving an exception should understand exactly which check could not be completed.
Work through a supplier-change example
Suppose a small design company owes €7,800 to a longstanding contractor. Two days before payment, an email asks for a new IBAN and gives an account-holder name that passes the bank’s check.
The match establishes useful information about that destination. It does not establish that the contractor authorised the change. The finance person therefore calls the contractor using the number saved when the relationship began.
If the contractor confirms the change through the agreed process, the company updates the supplier record, records who verified it and obtains the normal payment approval. If the contractor denies the change, the company preserves the message and stops the transfer.
Now change one fact: the account name does not match because the contractor has incorporated a company. The correct response is not simply to override the warning. The contracting entity, invoice and bank details may all need to be reconciled before the company decides whom it owes.
This is an illustrative workflow, not a claim that one callback prevents every fraud. The point is that a name check and independent confirmation answer different questions.
Keep approval separate from data entry
In a small team, one person may enter payment details and another approve the transfer. The second person should see the information needed to make a decision: supplier, invoice, amount, due date, account details and any verification exception.
If the approver sees only a total and a green status indicator, the separation may be largely cosmetic. They need to know whether the account is new, whether the name was corrected and who confirmed the change.
For a sole operator, perfect separation may be impossible. A deliberate pause, a saved supplier record and an independent confirmation route can still improve the process. The arrangement should fit the business rather than imitate controls that nobody can maintain.
Avoid making the name-check result the only stored evidence. Keep the invoice and the business reason for payment. That helps resolve ordinary mistakes as well as attempted fraud.
Understand what faster payment changes
An instant transfer can leave less time to notice and act on a mistake. That makes checks before authorisation particularly valuable. It does not mean that every ordinary transfer can be recalled successfully or that every instant transfer is irrecoverable in every circumstance.
Ask the provider how to report a suspected mistaken or fraudulent payment and keep the official contact route accessible. Do not wait for a dispute with the recipient to be resolved before informing the bank.
The relevant operating decision is when to release the payment. If verification is unfinished, selecting a faster rail does not solve the uncertainty. A business should agree how urgent exceptions are handled before a high-pressure request arrives.
Likewise, do not assume that a successful name check changes legal liability or guarantees reimbursement. Those questions depend on the payment, provider terms and applicable rules. A general explanation of the check cannot determine the outcome of a particular claim.
Review the process after a warning
A mismatch is useful information even when the payment turns out to be legitimate. It may reveal outdated supplier records, inconsistent legal names or an unclear process for changing account details.
After resolving it, update the source record so that the next payment does not require the same investigation. Keep the old details where necessary for accounting history, but clearly identify which details are current.
Review exceptions periodically. If staff routinely bypass the check because legitimate payments produce warnings, investigate the cause. A control that creates repeated unexplained friction is likely to be worked around.
The practical goal is a payment record that explains the decision: what was owed, who was to receive it, what the check returned, how any uncertainty was resolved and who authorised the transfer.
Keep the payment batch readable
Batch payments deserve the same destination checks as individual transfers. Before approving a batch, make new or changed recipients easy to identify. A total of twenty ordinary invoices can hide one altered account, so the reviewer needs the exceptions as well as the total.
If the bank or payment software offers different handling for uploaded payment files, read that process specifically. Do not assume the checks shown during a single manual transfer are reproduced in exactly the same way for a batch. Confirm the results available to the person releasing the payments and retain them with the batch record.
Questions
Does a Verification of Payee match mean a payment is safe?
It means the name and account details correspond within the check’s scope. It does not validate the invoice, the supplier’s conduct or your reason for paying.
What should I do with a name mismatch?
Confirm the expected legal name and account details through an independent, established contact route before deciding whether to proceed.
Can I rely on a telephone number in the invoice email?
Not as an independent verification route if that message is the information you are trying to verify. Use contact details established separately.
Does a match guarantee a refund if the payment is fraudulent?
No such guarantee follows from the check itself. Reporting, liability and reimbursement depend on the relevant facts and rules.
