Global Payments and Verification of Payee: What Changes

If you search for 'global payments', most of what comes back is about one company: Global Payments Inc., a US-listed payment technology business. That is a company profile, and it is not what this article is about. For a payments team, 'global payments' is a category: money moving between countries, across currencies and across payment systems. The practical question is not who the company is, but how a payment is verified when the payer's bank and the payee's bank sit in different countries.

That question now has a regulatory answer in Europe. The EU Instant Payments Regulation requires payment service providers (PSPs) to run a name-to-IBAN check - Verification of Payee (VoP) - before a euro credit transfer is sent. This article explains where that check reaches across borders, what it returns, and what to build.

What 'global payments' means - and why the search results confuse two things

Two different things share the phrase. The first is Global Payments Inc., a company with its own history, share price and reviews. The second is global payments as a category: any payment where the payer and the payee are not in the same country, or where the money crosses a payment system, a currency or a scheme boundary.

A payments professional searching the term usually needs the second meaning. You are not looking for a company profile; you are looking for how cross-border flows are routed, verified and controlled. This article stays on that side of the line, and deliberately does not cover the company's history, leadership or stock.

Global payments vs SEPA payments: what actually crosses a border

It helps to separate three kinds of flow, because the rules differ for each.

• Domestic payments stay inside one country and one payment system - for example a euro credit transfer between two banks in the same Member State.
• SEPA payments move euros between accounts anywhere in the Single Euro Payments Area, which covers EU Member States plus a number of neighbouring countries that have joined the schemes. A SEPA payment can be cross-border and still sit inside one shared rulebook.
• Global (cross-border) payments leave SEPA or leave the euro: a payment to a bank outside the scheme, a payment in another currency, or a payment that travels through correspondent banks and currency conversion.

The distinction matters because Verification of Payee is a SEPA-scheme construct. It works because the requesting PSP and the responding PSP both participate in a shared scheme with standardised messages and standardised outcomes. Inside SEPA, that is true by design. Outside it, there is no shared scheme to ask the question through.

So the honest answer to 'does VoP apply to cross-border payments?' is: it applies to cross-border payments that are SEPA payments. A euro transfer from a bank in one Member State to a bank in another is exactly the case the check was built for. A payment to a bank that does not participate in the scheme is not covered, and the check returns a 'not available' outcome rather than a match.

Where Verification of Payee fits into a global payment flow

VoP is one step in the payment journey, not a separate product. The flow is short and the same whether the two banks are in the same country or not.

1. 1 The payer enters or selects a payee name and an IBAN.
2. 2 The payer's PSP - the requesting PSP - sends the name and IBAN to the payee's PSP.
3. 3 The payee's PSP - the responding PSP - compares the name with the account holder's record and answers.
4. 4 The answer is one of four outcomes: match, close match, no match, or not available.
5. 5 The payer's PSP shows the result and the payer decides whether to continue, correct the details or stop.

The four outcomes are worth knowing precisely. A match means the name you supplied is consistent with the account holder. A close match means the names are similar but not identical - a missing middle name, a trading name instead of a registered name - and the responding PSP usually returns the name it holds so the payer can confirm it. A no match means the name does not belong to that account. Not available means the payee's PSP could not answer, for example because it is unreachable or does not participate.

This is also where global payments get harder than domestic ones. In a domestic flow, the two banks are usually in the same system and the routing is trivial. In a cross-border flow, the check depends on the payee's PSP being reachable, being in scope, and answering in time. Design for the case where it cannot.

Who has to implement VoP - and by when

The obligation comes from the EU Instant Payments Regulation, which amends the SEPA Regulation and requires PSPs that offer euro credit transfers to verify the payee before sending. In practice that means banks and PSPs handling euro instant payments, and the responding side too: if you hold customer accounts, other PSPs will send you requests about your own account holders, so you need to be able to answer them.

• PSPs in the euro area have had to offer Verification of Payee since 9 October 2025.
• PSPs in non-euro EU Member States follow by 9 July 2027.
• Both directions - asking and answering - are part of the build, not just the user-facing check.

The full timeline, including how the dates apply country by country, is on the dedicated deadline page. The point for a cross-border provider is simpler: the obligation follows the payment, not your head office. If you send euro credit transfers into SEPA, the check is in scope.

What global payment providers and PSPs must build

The build list is the same whether you are a domestic bank or a cross-border provider. What changes is the number of counterparties you have to reach.

1. 1 A requesting direction: the ability to send a name and IBAN to the payee's PSP and receive a standardised outcome before the payment is released.
2. 2 A responding direction: the ability to receive requests about your own account holders, match the name against your records and return the right scheme code.
3. 3 Name-matching logic that handles legal forms, initials, accents and trading names, and that returns the held name on a close match so the payer can confirm it.
4. 4 Latency and availability targets: the check runs while the payer waits, so it has to answer in well under a second and stay up.
5. 5 Logging and audit: store the outcome, the responding institution and the processing time, without keeping more personal data than you need.

Two design decisions save a lot of pain later. First, treat 'not available' as a normal outcome, not an error - it is what you will see for counterparties outside coverage, and it should lead to a clear message rather than a failed payment screen. Second, keep the check in the payment path rather than bolting it on afterwards, so the result is available at the moment the payer confirms.

What corporates and treasury teams should do about global payee data

If your company pays suppliers, staff or tax authorities in several countries, you hold beneficiary data that was captured at different times, in different formats and by different teams. Some of it is out of date. A name check is only as good as the name you send it.

• Clean before you check: reconcile stored beneficiary names against the legal or registered name, not a nickname or a shortened trading name.
• Verify at onboarding: run a check when a supplier or employee is first set up, and store the verified name that comes back.
• Verify before payment runs: run the same check across a payment file so a single mismatched account is flagged before cash leaves.
• Re-verify on change: a new IBAN or a changed name is the moment to check again, not every payment to a trusted payee.

For a treasury team, the value is not only compliance. A payment to the wrong account is expensive to recover, especially when it is instant and crosses a border. A name check before release is far cheaper than the recovery process.

How to choose a Verification of Payee provider for cross-border coverage

When payments cross borders, the questions you ask a VoP provider change. Coverage and reachability come first; the API shape comes second.

• Reach: which responding PSPs can the provider actually contact, and how does it behave for the ones it cannot?
• Both directions: can it answer requests about your own account holders as well as send them?
• Latency and availability: what response time do you get in practice, and what happens on a timeout?
• Fit with your stack: one REST contract, standardised outcomes and scheme codes, plus a dashboard for the teams that do not write code.
• Audit and data protection: what is logged, where it is stored, and how long it is kept.

RoxPay delivers Verification of Payee on the SEPA scheme through one REST API and a dashboard, covering both the requesting and the responding direction, and returning the standardised outcomes - match, close match, no match and not available - in well under a second, with the responding institution and processing time attached to each result.