Is this really your supplier's account? Ask before the payment run, not during it

Sending money to the wrong account is one of the oldest frauds in business. In private banking, there is now a simple safeguard against it: before a transfer goes out, the bank checks the payee name against the account and tells you whether it matches, almost matches or does not match at all. 

That small signal is Verification of Payee (VoP). Since 9 October 2025, banks in the euro area must check the payee before they execute a euro credit transfer. The obligation comes from Regulation (EU) 2024/886, the Instant Payments Regulation, which amended the SEPA Regulation and introduced VoP. 

For consumers, it works well. For corporate payments, it arrives at the wrong moment, in the wrong place, and it stops at the borders of the euro area. 

What does Verification of Payee actually do? 

Before a transfer is authorised, the payer's bank asks the payee's bank a simple question: does the name entered belong to this account? The answer is match, close match or no match. 

VoP does not block a payment. It informs the payer, who then decides. And that decision carries weight: a payer who goes ahead despite a warning bears the risk if the money reaches the wrong recipient. 

The aim is clear and sound: stop misdirected payments and authorised push payment fraud before the money leaves. 

But the design assumes one person, one payment and one decision, made on the spot. That is how private payments work. It is not how payments work in a typical group. 

Why doesn't it fit corporate payment runs? 

In larger companies, a payment is the last step of a long chain. A business department raises a purchase order. Procurement backs it. Goods or services are received. The invoice is approved. Accounts payable then collects the approved items and, in the interest of working capital, pays them as late as the contracted payment terms allow, usually in bulk files. 

VoP sits right at the end of that chain. The check runs when the payment file reaches the bank, often days before the due date or on it. 

Now picture a single no match or close match. It can hold up an entire batch and require manual review. Resolving it means chasing answers across several teams: the purchase order owner, the supplier, and the master data team that maintains bank details. Modern ERP systems offer little support for that loop. There is rarely a structured way to feed a VoP result back to the people who own the record, and rarely the time to do so before payment terms are breached. 

The Euro Banking Association makes the same point: the person authorizing a payment file is often not best placed to assess the VoP result, and the underlying ERP systems can take up to 18 months to update. 

At its core, the issue is organizational. Bank details are maintained in master data, not in the payment run. The people who see the VoP result cannot correct the account. And the people who maintain the account never see the VoP result. 

What happens when companies opt out? 

The regulation anticipates part of this. Businesses that submit several payment orders as a package may opt out of VoP for those bulk payments, and the European Payments Council has confirmed that processing VoP for bulk files is outside the scope of its scheme. In our projects and customer conversations, we see that nearly all large corporates have done so. 

Opting out is a rational response to a process mismatch. But it comes at a price: the protection VoP was designed to provide does not reach most corporate payment volume. 

The fraud risk has not gone away. It has simply moved upstream, to the moment an account enters or changes in master data. 

What if you could ask the question before the payment? 

That is exactly what Bank Account Prevalidation does. Now available in the Trust Score Check of CDQ Fraud Guard, it separates the question VoP asks from the payment itself. 

It asks the account holding bank, live, three things: does the account exist, is it open or closed, and does it belong to the named owner? The answer comes straight from the horse's mouth: from the bank's own records at the moment of the query. Not from a reference database. Not from pooled data. Not from a score inferred from past transactions. 

The party that answers, the responder, is either the bank itself or a national scheme or specialist provider connected to it. CDQ is your single access point, and your contract is with CDQ alone. 

The decisive difference is where the check happens. It runs in master data, when a supplier is created or its bank details are changed, in the team that is responsible for that data and able to act on the answer. A mismatch is resolved before the account is ever used, not under pressure in a payment run. 

One Trust Score Check call returns two independent answers: reliability, from the payment history in the CDQ Data Sharing Community, and identity, from the account holding bank. The identity answer does not alter the trust score. 

What about suppliers outside Europe? 

The Instant Payments Regulation was the trigger, and its scope sets the limits of VoP: it covers credit transfers in euro within the SEPA area. A payment to a supplier in the United States, Canada, China or Australia is outside its reach. 

But companies with a global supplier base need the same certainty everywhere they pay. A check that ends at Europe's borders falls short of that. 

That is why we built Bank Account Prevalidation beyond the reach of the EU regulation. As of October 2026, it covers 75 countries with at least one active responder, in Europe and around the world. The question, the call and the answer format are the same in every country. 

Do you need a new integration? 

No. Many members of the CDQ Data Sharing Community have integrated the Trust Score Check deeply into their processes. That is why we did not launch prevalidation as a separate service. It is part of the existing Trust Score Check. (New to the Trust Score? Our webinar on combating fraud with data collaboration explains how it works.) 

For an existing integration, the step is small: add the account owner's name and switch the bank check on for the request. The update does not break anything. Integrations that do not request the bank check receive exactly the response they receive today. Those that do get the identity answer as additional content in the same response, beside the reliability answer they already use. 

One updated API. No new service to integrate. 

Where does it fit in everyday processes? 

Creating a new supplier. Before the first payment, the bank confirms that the account exists, is open and belongs to this supplier. 

Changing a supplier's bank details. A request arrives by email or through a supplier portal, and it looks genuine. Prevalidation adds an independent confirmation from the account holding bank, alongside the established call back on a known phone number. That matters where call backs reach their limits: a supplier that cannot be reached by phone, or a language barrier on the line. 

Reactivating a dormant supplier. The payment history is real, but old. A fresh check shows whether the account is still open and still belongs to that supplier today. 

Prevalidation complements, rather than replaces, VoP and existing controls such as segregation of duties. It fits into the wider finance and accounting processes CDQ supports. 

Every answer carries a traffic light (green, amber, red or grey), a status with a plain language reason and the time of the bank's answer, so the check is documented for internal control and audit. Grey means unanswered: never a warning, never a confirmation. 

One honest note: the answer is decision support, not a guarantee. It is a snapshot rather than a monitoring service, so we recommend a fresh check before every decision. 

How can you get started? 

Coverage grows as new banks join, with no change needed on your side. Bank Account Prevalidation is available as a single check in CDQ Cloud Apps and through the API. Production use requires a contract or contract addendum. 

Ready to ask the right question at the right moment? 

VoP brought the right question to the wrong moment for corporate payments. Bank Account Prevalidation asks it where bank details are maintained, before any payment is due, and in 75 countries rather than one currency area. 

See it in action on your own supplier data: book your free demo.