Verification of Payee: Increasing Security for Bank Transfers

Since October 2025, payment service providers and banks in the EU must verify the recipient before every SEPA transfer using Verification of Payee (VoP). This means checking whether the account holder and IBAN match. Recipient verification is now an integral part of the payment process. Its purpose is to prevent misdirected payments and fraud, increasing transfer security. For banks and payment service providers (PSPs), this reduces returns and support efforts.

For e-commerce merchants, this means: VoP protects payments—but can slow them down if the name and IBAN are not provided consistently. In such cases, warnings appear more frequently at checkout, prepayments get delayed, and customer inquiries increase. We explain recipient verification, how it works, and how merchants can provide VoP-compliant payment data while keeping invoice payments attractive.

Key Points at a Glance

• Mandatory Verification: Since October 2025, payment service providers are required to verify the match between name and IBAN via VoP before every SEPA transfer.
• Preventive Security: VoP prevents misdirected payments, hinders fraud, and provides clear frontend indicators such as “match” or “please check.”
• Merchant-Focused Data Quality: Consistent legal entity names and clean spelling reduce false warnings and keep invoice payments flowing.
• Error-Free Data Entry: Photo-based transfers and EPC/GiroCodes automatically transfer name, IBAN, amount, and reference into the banking app, minimizing unnecessary errors.
• Measurable Business Impact: Fewer payment interruptions and inquiries lower process costs and strengthen trust in account-to-account payments.

What is Verification of Payee (VoP)?

Verification of Payee is the process of checking the recipient before executing a SEPA transfer, including instant payments. The payer’s payment service provider matches the details entered by the payer with the data stored by the recipient’s institution. The focus is on the IBAN in identifying information such as the account holder’s name.

Additional identifiers (e.g., LEI, tax number, or EUID) can be included for businesses. Unlike previous processes, where payments were processed primarily based on the IBAN alone, VoP incorporates these identifiers in the IBAN-name check and returns a standardized result.

Benefits of Recipient Verification

VoP closes a known gap in the SEPA process, where name and account number were not systematically matched. This creates adequate protections before execution—with tangible effects on security, trust, and operations.

• Enhanced Fraud Protection: VoP reduces invoice diversion, CEO fraud, fake invoices, and authorized push payment fraud because payments only go through if recipient data and IBAN match plausibly.
• Fewer Misdirected Payments: Recipient verification detects incorrect account data before execution, reducing errors, returns, and costly reclamations.
• Improved Payment Security: Name-IBAN matching adds a pre-check layer to existing controls, demonstrably increasing transfer security.
• More Efficient Processes: Early detection of discrepancies reduces manual checks, investigations, and support tickets, cutting processing times and operating costs.
• Wider Use of Real-Time Payments: The EU is promoting instant payments. VoP makes standardized verification visible, providing the confidence needed for consumers to use it more frequently.

Recipient verification improves master data (e.g., legal or alias names) and stabilizes payment flows—especially for first-time transfers, higher amounts, and B2B invoices. For banks and PSPs, this means less operational friction, more predictability in risk/finance, and better user perception of account-to-account payments. For merchants, cancellations and chargebacks decrease if payment data is VoP-ready and the IBAN-name check passes on the first attempt.

Technical Process: How VoP Works

Before executing a SEPA transfer, the payer’s PSP initiates a quick recipient check. Based on the entered data, a standardized request is sent to the recipient’s institution:

1. Data Entry: Payers provide the IBAN and recipient name. Optionally, references like the end-to-end ID are included. These details form the basis of the VoP request.
2. Request from Requesting PSP: The payer’s PSP (Requesting PSP) generates a VoP request and sends it to the recipient’s PSP (Responding PSP). The request contains only the fields needed for verification (IBAN, name/identifier, optional reference).
3. Verification by Responding PSP: The Responding PSP compares the submitted data with the recipient account information and returns a standardized assessment of the plausibility of the name/identifier relative to the IBAN.
4. Response to Requesting PSP: The Responding PSP sends the result back, categorized internally as Match, Close Match, No Match, or No Response (e.g., unreachable/timeout).
5. Payment Decision: The payer decides whether to proceed or cancel based on the frontend feedback. A clear warning is displayed for No Match, and the payment is authorized only if the payer consciously confirms it.

VoP operates in real time, ideally under 1 second, and no later than 5 seconds. For bulk payments, VoP checks can be grouped shortly before execution, with the result at initiation being decisive.

Delivery and Response Times

VoP requests are delivered between the payer’s and recipient’s PSPs via established interfaces. Availability and latency determine whether the response arrives within the maximum 5-second window. Important: No Response/Timeout means “verification not currently possible” and is not the same as a No Match. Reliable results require stable interfaces, fallback procedures, and monitoring (e.g., availability SLOs, latency percentiles, no-response rates).

Security and Data Privacy: GDPR Compliance

VoP involves personal data, so GDPR principles apply: minimal data usage, only for payment verification, and clear deletion policies. Communication between PSPs must be strongly authenticated and encrypted, using qualified web certificates (QWAC) for mutual identification and secure transport channels. Role-based permissions, thorough logging, audits, and separation of sensitive components are also required.

Liability risks should be managed carefully: a False Match may allow a wrong payment, while a False Non-Match may block legitimate payments. Institutions should define clear rules and escalation paths, review sensitive cases, and communicate frontend messages calmly but clearly, e.g., “match” or “please check.”

Name Matching for Merchants: Data Quality as a Lever

In e-commerce, warnings like “IBAN and recipient do not match” often appear even when payments are correct. This usually happens when brand and legal entity names differ or due to variations in spelling (e.g., “Müller/Mueller”) or collective/factoring accounts. Reliable recipient verification requires clean master data and accurate payment information—from shop to invoice.

• Consistent Legal Entities: The official account holder should appear consistently across the shop, receipts, and QR codes. This ensures VoP recognizes the intended recipient.
• Correct Spelling: Standardize capitalization, umlauts (e.g., “ä”/“ae”), and legal form suffixes to prevent mismatches.
• Secure Payment Data Delivery: Online IBAN and account holder information should be available in the logged-in customer account. Emails and PDFs should link to it instead of showing plain IBANs. Paper invoices may include the IBAN, ideally with EPC/GiroCode and clear legal entity information, reducing manipulation risks.
• Standardized Data Transfer: Users should be able to import payment fields directly into banking apps to ensure consistent data for matching.
• Targeted VoP Signal Management: Brand and short names should be clearly assigned to the legal entity in ERP/CRM systems and maintained when updated. For repeated Close Match warnings, an onsite prompt like “check payment info in account” is better than immediately generating a support ticket.

Result: Merchants reduce unnecessary warnings, increase match rates, and prevent cancellations in prepayment flows, while service inquiries decrease. Invoice payments remain reliable and conversion-friendly even with VoP.

VoP: How Photo Transfers and QR-Code Payments Reduce False Alarms

Warnings in IBAN-name matching are helpful, but user input errors cause many. A single misplaced character in the name or a wrong digit in the IBAN triggers a VoP warning. Photo transfers and QR-code payments solve this: invoice data—account holder, IBAN, amount, and reference—are transferred directly from the document or code. Typos causing false alerts are eliminated, so the check only flags real discrepancies.

Conclusion: More Security with Verification of Payee

VoP is not a bottleneck—it supports invoice payments. When name and IBAN are accurate and users can transfer payment data without typing, unnecessary warnings disappear. Alerts occur only for actual mismatches, increasing security and trust.

With photo-based transfers or QR-code payments, prepayments feel safe again for customers and merchants. VoP ensures smooth account-to-account payments, reduces inquiries, and improves conversion rates.