Verification of Payee for Corporates: Understanding The Real Impact On Payments

• WHAT VOP ACTUALLY IS—AND WHAT IT IS NOT

Regulatory Context

The Verification of Payee (VoP) scheme was developed by the European Payments Council (EPC) as part of the EU Instant Payments Regulation (IPR), adopted by the European Parliament on March 13, 2024. The regulation came into force for eurozone PSPs on October 5, 2025, with non-euro area countries following on July 9, 2027.

The mandate is unambiguous: Payment Service Providers must offer payers a real-time verification service that checks the payee's name against the registered account holder before a SEPA Credit Transfer or SEPA Instant Credit Transfer is executed. This requirement applies to single payments, where verification must be performed prior to execution and provided free of charge to the payer. PSPs shall provide payers that are not consumers with the means to opt out from receiving the service when submitting multiple payment orders in a batch. They shall also ensure that those that opted out from receiving the service have the right to opt in at any time.

How the VoP Scheme Works

When a payer initiates a SEPA credit transfer, the payer's PSP sends a verification request to the payee's PSP. This request includes the IBAN and either the payee's name or an identifier such as a VAT number or LEI. The Responding PSP checks the provided information and returns one of four outcomes:

 

 

The inter-PSP verification must be completed within 5 seconds, and ideally within 1 second. The Requesting PSP communicates the result to the payer, who then decides whether to proceed, investigate, or cancel the payment.

What VoP Is Not

VoP is a messaging framework between PSPs. It is not a guarantee of payment security. It does not validate the legitimacy of the underlying commercial transaction. It does not replace sanctions screening, AML controls, or fraud prevention.

Critically, the EPC has explicitly stated it has no plans to publish standards for customer-to-bank interaction in the context of VoP. This creates a fragmented landscape where each bank may implement VoP differently, creating a significant challenge for corporates with multi-bank relationships.

 

• THE CORPORATE OBLIGATION BANKS DON'T EMPHASIZE

The Vendor Master Data Problem

Although VoP is technically a PSP obligation, the reality is that the practical burden falls on corporates to ensure that payee data in their systems matches the legal identity registered with the payee's bank. Even small discrepancies—abbreviations, missing punctuation, "Ltd" versus "Limited"—may trigger a Close Match or No Match response.

Finance and treasury teams frequently face internal barriers that make this deceptively difficult, such as fragmented ERP systems, outdated vendor records, and manual verification processes. More than 70% of payment exceptions already stem from formatting errors or invalid account details.

While many banks currently offer corporates the option to opt out of verification for batch payments and, in practice, sometimes extend this flexibility to single payments, the regulatory direction under VoP introduces increasing constraints. As requirements evolve and opt-in verification becomes more strictly enforced, these exceptions may carry clearer regulatory and liability consequences, making it critical for corporates to strengthen data quality and validation processes in advance.

 

What Corporates Must Do to Their Vendor Data

To be VoP-ready, corporates must:

• Ensure the beneficiary's name in ERP or TMS matches the official account holder name on file with their bank, requiring validation not just of IBAN format, but legal entity naming conventions.
• Update vendor onboarding processes to collect the legal name as registered with the beneficiary's bank.
• Request that vendors include their legal name on invoices, exactly as registered with their bank.
• Conduct periodic audits of the entire vendor master data to identify records likely to produce a mismatch.
• Establish clear governance procedures for handling discrepancies and authorizing exception payments.

 

The Inbound Risk: Your Own Name

The obligation runs in both directions. Corporates receiving payments also need to ensure that their own official account name is clearly stated on sales invoices. If a customer attempts to pay and VoP returns a No Match because the invoice name differs from the legal account name, that customer may cancel or delay the payment. VoP creates an inbound payment risk that most organizations have not yet modeled.

 

• WHERE THE OBLIGATION SITS—ERP, TMS, AND THE CORPORATE INFRASTRUCTURE GAP

The Customer-to-Bank Gap

The European Payments Council’s VoP scheme governs inter-PSP communication, setting the rules for how verification requests and responses are exchanged between banks. However, the way VoP results are communicated to corporate clients is not entirely unregulated either.

Although EBICS offers a structured, secure framework for transmitting payment files and VoP results, its adoption remains regionally concentrated—particularly in Germany, France, Austria, and Switzerland—limiting its effectiveness. As a result, corporates cannot rely on a single, uniform approach to VoP integration and must instead adapt their internal systems to manage variability across banks, channels, and jurisdictions.

For corporates using automated payment channels—EBICS, SWIFT, Host-to-Host, or Bank API—the integration challenge is non-trivial. In SAP S/4HANA Cloud environments running EBICS, new BTF parameters and order types are required (CTV for SCT opt-in, CIV for SCT Inst opt-in), and the bank must be specifically enabled to accept these.

 

The Opt-In vs. Opt-Out Decision

VoP is generally optional for bulk payments, meaning a corporate that does not use the new order types is treated as having opted out. For single payments, the Instant Payments Regulation considers VoP opt-in mandatory—though implementation varies by PSP.

Opting out of VoP may preserve workflow continuity in the short term but shifts liability to the corporate in the event of a misdirected payment. Opting in requires ERP and TMS configuration changes, testing, and bank alignment—across every bank in the corporate's network.

The Multi-Bank Complexity

For multinational corporations with connections to dozens of banks across SEPA countries, each bank may implement VoP differently. Some banks return free-text descriptions; others use structured match codes. Some have published rollout timelines; others have not. This variability means there is no single configuration that addresses every banking relationship—corporates must conduct a bank-by-bank assessment.

 

The TMS/ERP Adjustment Requirement

TMS and ERP systems must be updated to:

• Capture and display VoP responses for each payment.
• Gate payment authorization on VoP result handling (where opted in).
• Log VoP responses and user actions—proceed, cancel, override—in audit trails for compliance traceability.
• Handle bulk VoP requests and results at the transaction level, not just the batch level.

Organizations that have not begun this configuration work are at risk of disruption when their banks begin enforcing VoP across all payment channels.

 

• WHAT HAPPENS TO OUTBOUND FLOWS WHEN VERIFICATION FAILS

The Four Responses and Their Operational Cost

Each VoP response carries a different operational consequence:

The Bulk Payment Trap

One of the most consequential—and least discussed—aspects of VoP for corporates is how bulk payments are handled under EBICS. The Deutsche Kreditwirtschaft specification requires that bulk payments must be fully authorized or fully rejected. Corporates cannot selectively remove suspicious transactions from a bulk payment file without reversing the entire batch.

This means a single Close Match or No Match within a multi-transaction batch could block an entire payment run—affecting hundreds or thousands of suppliers simultaneously. For treasury teams managing month-end payables or payroll runs, this is an operational risk of the first order.

 

The Liability Question

When a corporate proceeds with a payment after a No Match or Close Match result, the responsibility for the outcome shifts substantially. In the event of opting out of VoP or overriding a No Match result, the allocation of responsibility in the event of a misdirected payment becomes less straightforward.

Regulatory guidance acknowledges that such decisions can have implications for liability and potential refund rights. As a result, VoP introduces a layer of uncertainty in how accountability is determined when warnings are overridden, particularly in cross-bank or multi-jurisdictional scenarios.

 

Fraud Scenarios That VoP Does Not Prevent

VoP verifies the name against the IBAN at the payee's bank. It does not detect: 

• Business Email Compromise (BEC) scenarios where both the name and IBAN are genuine but belong to a fraudulent account set up in advance. 

• Insider manipulation of vendor master data within the corporate's own ERP before the payment reaches the bank. 

• Fraud where the attacker has already changed the payee's bank records.

VoP also does not extend beyond the geographic scope of its implementation. As a regional control anchored in the SEPA framework, its effectiveness is inherently limited in global payment environments where equivalent verification mechanisms may not exist. This creates the potential for fraud risk to shift rather than diminish, particularly as attackers target payment flows or counterparties outside the scope of VoP coverage.

VoP is a necessary control, but it is not sufficient as a standalone fraud prevention mechanism. It must be layered with vendor master data screening, anomaly detection, and proactive transaction screening to form an effective defense.

 

• GETTING AHEAD — A CORPORATE READINESS FRAMEWORK

Five Actions for VoP Preparedness

• VENDOR MASTER DATA AUDIT 
  Conduct a systematic review of all vendor records to identify entries where the stored legal name is likely to produce a VoP mismatch. Prioritize high-value, high-frequency vendors and cross-border SEPA relationships. 
• ERP AND TMS CONFIGURATION REVIEW 
  Assess which payment channels are in use for each banking relationship and what VoP configuration is available. Define opt-in/opt-out policies per channel, per bank, and per payment type. 
• BANK DIALOGUE 
  Initiate conversations with each banking partner to understand their VoP rollout timeline, response format, and handling of edge cases. Document agreements centrally. 
• EXCEPTION HANDLING WORKFLOW 
  Define procedures for Close Match, No Match, and Verification Not Possible results. Who reviews the alert? Who authorizes the override? How are exceptions logged for audit? 
• INVOICE AND ONBOARDING PROCESS UPDATES 
  Update vendor onboarding templates and invoice requirements to capture the legal account holder name. Communicate to key trading partners that their name on invoices must match their bank-registered legal name. 
• VERIFY YOUR CORPORATE DETAILS 
  Verify that your legal entity name is used correctly on invoices and payment instructions. Any mismatch between the payer’s records and your registered corporate name can lead to payment delays or, in some cases, cause incoming payments to be flagged or stopped for verification. 

 

• HOW TIS ACCOUNT VALIDATION ADDRESSES THE CORPORATE VOP GAP

The five readiness actions above represent genuine internal work. But one of the most direct steps a corporate can take is shifting account validation upstream—out of the bank's hands and into the payment workflow itself, before any instruction is sent. This is precisely where TIS Account Validation operates.

What Account Validation Does

TIS Account Validation is a proactive fraud prevention service that validates payment account details globally before transactions are executed. Rather than relying on each bank's VoP implementation—with its variable response formats, opt-in configurations, and EBICS-specific handling—TIS validates at the point of submission within the TIS platform. The check confirms two things: that the account exists, and that the payee name matches. If it does not, the payment does not proceed.

• Submit payment - Payment details are entered into the TIS platform as usual. 
• Validate account - Account existence and payee name match are verified in real time. 
• Execute safely - Only validated payments proceed to execution. 

 

ACCOUNT VALIDATION VERIFIES:

• The account exists
• The account matches the payee name
• Before any payment is executed

 

Account Validation vs. VoP: understanding the difference 

VoP is reactive—it confirms the payee after a payment instruction has been formed. Account Validation is proactive—it prevents the mismatch before it happens. The two are complementary, not competing.

 

Account Validation is PROACTIVE — it prevents fraud before payments execute, making it a superior first line of defense compared to reactive VoP checks alone.

 

Why TIS Account Validation for Multi-Bank Operations

The Complete Fraud Prevention Stack

Account Validation does not replace VoP—it complements it. Together they form a complete defense: Account Validation stops mismatches before execution; VoP provides the regulatory confirmation layer at the bank. For corporates managing complex multi-bank payment estates, TIS delivers both within a single platform.

 

• CONCLUSION: VOP IS A CORPORATE PROBLEM WEARING A BANK'S CLOTHES

VoP has been communicated primarily as a PSP compliance story. Banks are required to build the verification infrastructure; that is true. But the data that flows through that infrastructure, the workflows that must interpret its outputs, and the liability that accrues when something goes wrong—all of these sit with the corporate.

Organizations that wait for their banks to guide them through the VoP transition will find themselves managing payment disruptions, bulk payment rejections, and unresolved liability questions during their most operationally sensitive moments—month-end, payroll, and supplier payment runs.

The corporates that are best prepared are those that have already begun treating VoP as an internal process transformation, not an external banking update. And the most direct first step is ensuring that every payment is validated before it ever reaches a bank.

 

About TIS 

TIS helps CFOs, Treasurers, and Finance teams transform their global cash flow, liquidity, and payment functions. Since 2010, our award-winning cloud platform and best-in-class service model have empowered the entire office of the CFO to collaborate more effectively and attain maximum efficiency, automation, and control. TIS enables users to achieve superior performance in key areas surrounding cash forecasting, working capital, outbound payments, financial messaging, fraud prevention, payment compliance, and more. 

For more information, visit tispayments.com and begin reimagining your approach to global cash flow, liquidity, and payments.