Cross-Border Bank Account Verification: How to Pay Suppliers Worldwide Without Failed Transfers

Roughly one in eight cross-border payments fails. The cause is almost always the same — nobody verified the account before the money moved, because verifying internationally is harder than verifying domestically.

The numbers behind that single sentence add up to real money. Nium's research, reported in PYMNTS, places the cross-border payment failure rate at 10–15% of all international transactions. Roughly 70% of those failures trace to account information errors — wrong account numbers, name mismatches, outdated routing details. The Bank for International Settlements projects total cross-border B2B payment volumes will reach $250 trillion by 2027. Even at a conservative failure rate, that's tens of billions of dollars in friction every year — direct losses, reconciliation overhead, vendor disputes, and the time it takes finance teams to chase down what went wrong.

Domestic payments don't fail anywhere near this rate. Inside a single country the verification path is short: one banking system, one identifier scheme, one set of rules. The bank either confirms the account exists and matches the name, or it doesn't. Cross-border breaks every part of that. The payer's bank sends instructions through SWIFT or a correspondent network. The receiving country uses a completely different account identifier — IBAN in Europe, CLABE in Mexico, CPF or CNPJ in Brazil, IFSC in India, UnionPay in China. The receiving bank may credit funds based purely on the account number, ignoring the name entirely. Or the bank may use Latin-script characters internally while the actual legal name is registered in Cyrillic, Mandarin, Arabic, Thai, or Hindi.

This guide walks through how verification actually works in the ten markets most non-US companies pay into — what's possible in each, what isn't, and how to design a workflow that doesn't break the moment a supplier's country isn't in the EU. By the end you should know which markets give you real-time bank-level verification, which only support entity-level checks, and where the gaps need to be closed with operational controls.

The verification gap nobody is filling

The result of all this complexity is a verification gap that no single global system fills. SWIFT itself is a messaging network — it transmits payment instructions between banks but doesn't own the account databases needed to confirm whether an account exists or who owns it. National rails like VoP, CoP, PIX, UPI and ACH validation each handle one country well but stop at the border. Verification has to be assembled, country by country, from whatever infrastructure each market actually exposes.

That assembly is what this guide is about. The next section introduces the three-tier framework MonitorPay built around this reality, and the country sections that follow show what each tier looks like in practice.

The three-tier reality of global verification

Despite what most vendor marketing implies, cross-border verification is not one capability. It's three different ones — and most countries fall into different tiers.

The right strategy is to apply the highest tier the destination country supports, fall back to Tier 2 when bank-direct verification isn't available, and use Tier 3 only as a last resort with manual controls compensating for the gap.

This is the framework MonitorPay built its product around. Tier 1 direct bank verification is live in 49+ countries — including every market detailed in the sections below. Tier 2 registry-sourced entity verification covers 200+ jurisdictions through direct connections to government business registries. Tier 3 (SWIFT pre-validation) is the fallback for the small number of markets where neither rail is accessible to non-resident payers — and even there, the verification call returns a structured response so your AP system can apply consistent decision logic.

The country sections below detail what each tier looks like in practice.

European Union — Verification of Payee (VoP)

Since October 9, 2025, every euro-area Payment Service Provider has been required to offer Verification of Payee under the EU Instant Payments Regulation. Non-euro EU countries follow by July 9, 2027. For a buyer paying suppliers anywhere in the EU, this means a name-to-IBAN check is now part of the standard payment flow.

VoP returns one of four results: Match, Close Match, No Match, or Unable to Verify. The "Close Match" response is the one most teams underestimate — it surfaces when the legal name on file differs slightly from what was entered (Ltd vs Limited, abbreviations, accented characters). A close-match result is not automatic approval; it's the moment for manual review.

VoP is strong on bank-account-to-name validation. It does not verify that the company itself is real, active, or properly registered — for that, layer registry-sourced KYB on top. MonitorPay's complete guide to VoP covers the regulatory detail in depth.

United Kingdom — Confirmation of Payee (CoP)

The UK runs Confirmation of Payee through Pay.UK, with coverage extended dramatically by Specific Direction 17 from the Payment Systems Regulator. As of October 31, 2024, around 400 PSPs and building societies — including Group 1 banks (Barclays, HSBC, Lloyds, NatWest, Santander, Nationwide) and Group 2 expansion firms — have been required to provide CoP. Coverage now reaches 99% of all CHAPS and Faster Payments transactions.

CoP works similarly to EU VoP but operates over UK Faster Payments and CHAPS rather than SEPA. It uses a system called Secondary Reference Data for building societies (the "roll number") and standard sort-code-and-account-number for banks.

One operational note that catches non-UK payers off guard: CoP responses go to the bank initiating the payment, not to the corporate sender. If your treasury team is sending UK payments through a non-UK bank that doesn't surface the CoP result back to you, you can't see whether the name matched. The fix is to use a verification provider that calls the CoP system directly on your behalf and returns the result inline.

United States — ACH and the Nacha 2026 rules

US verification looks deceptively simple — routing number plus account number, ACH for low-cost transfers, wire for urgent. The complication is that the US ACH network historically did not require name validation: receiving banks could credit funds based purely on the account number, ignoring whether the name matched.

That changed with Nacha's 2026 risk management amendments. Phase 1 took effect March 20, 2026 for high-volume originators (≥6 million ACH entries in 2023); Phase 2 extends to all non-consumer originators on June 22, 2026. Both phases require documented, risk-based fraud monitoring — including verification that bank account information is real and owned by the named entity, not just self-reported.

For non-US companies paying US suppliers, the practical workflow is:

• Verify the supplier's EIN against IRS records — confirms the business legally exists. (See EIN verification.)
• Verify the routing number and account number through a real-time account validation provider — confirms the account is open and active.
• Match the registered account holder name against the supplier's legal name.

Payments routed through a non-US originating bank travel as IAT (International ACH Transaction) entries and carry additional OFAC screening obligations. For a deeper view, see MonitorPay's Nacha 2026 implementation guide.

Brazil — PIX, CPF, and CNPJ

Brazil has one of the most sophisticated real-time payment infrastructures in the world. PIX, operated by the Banco Central do Brasil, processes over 200 billion transactions a year and is the dominant payment rail across the country. Verification in Brazil uses three identifiers, and getting them right is the difference between a payment that lands instantly and a payment that disappears.

Two things break Brazilian payments more than anything else:

1. CPF/CNPJ status is not binary. Brazil's Federal Revenue (Receita Federal) classifies tax IDs as Regular, Suspended, Cancelled, or Pending Regularization. A CPF in any state other than Regular will cause invoice rejections, banking refusals, and payment failures — even if the number itself is structurally valid. CNPJs in inapta status (failed declarations for two consecutive years) cannot transact at all.

2. The PIX key has to map to the right tax ID. Banks must verify that PIX keys correspond to valid CPF or CNPJ records. A key linked to an inactive tax record gets removed. If a supplier gives you a PIX key tied to their CPF when they're invoicing as a CNPJ-registered business, the payment fails.

Verification for Brazilian suppliers should always include: structural CPF/CNPJ checksum (mod-11), Receita Federal status check, and PIX key validation against the correct tax ID type. All-same-digit CPFs (000.000.000-00 etc.) pass the checksum but are invalid — explicitly reject these.

India — IFSC, UPI, and NPCI Name Enquiry

India runs the world's largest real-time payment system. UPI processed roughly 20 billion transactions in August 2025 alone. Verification works through the National Payments Corporation of India (NPCI), and the country has unusually strong infrastructure for confirming both account existence and account ownership.

Three verification methods are available, and each has trade-offs:

• Penny drop — send ₹1 (or less) to the account; if it credits, the account is valid. Returns the registered account holder name. Cost: roughly ₹1 per check plus operational overhead. Best for one-off verification.
• UPI ID validation — query the supplier's Virtual Payment Address (VPA) against NPCI's database. Returns name match + bank + IFSC. No ₹1 transfer needed. Faster and cheaper than penny drop, but requires the supplier to have a VPA.
• NPCI Name Enquiry API — submit account number + IFSC + a name; NPCI returns whether the name matches the account holder on record. Live with select banks; this is the cleanest verification method available in India for high-volume corporate use.

One workflow trick worth knowing: any IFSC-and-account-number combination can be converted into a synthetic VPA in the format account@ifsc.ifsc.npci. That synthetic VPA can then be validated through standard UPI ID lookup, returning the holder name without making a payment. Many Indian fintechs use this internally as a zero-cost alternative to penny drop.

For B2B verification of Indian suppliers, also confirm the PAN (Permanent Account Number, 10 alphanumeric characters) for tax ID alignment. PAN-account-name matching through NPCI is binary — a definitive yes/no — which is more reliable than fuzzy name match alone.

Mexico — CLABE, SPEI, and the RFC tax ID

Mexican domestic payments run almost entirely through SPEI (Sistema de Pagos Electrónicos Interbancarios), the Banco de México's real-time interbank system. SPEI processes transactions 24/7 in seconds. Routing happens via the CLABE — an 18-digit account identifier that's uniquely Mexican.

The most important fact about SPEI for non-Mexican payers: SPEI credits funds based on the CLABE, not the recipient's name. If the CLABE is structurally valid and points to a real account, the money will land — even if the name on the account is completely different from what you entered. Name verification is not part of the SPEI settlement layer. It has to happen before the payment is sent.

For B2B verification, also collect and validate the supplier's RFC (Registro Federal de Contribuyentes) — Mexico's tax identifier. RFCs are 12 characters for legal entities, 13 for individuals, with a final check digit calculated from the rest. RFC validation against SAT (Servicio de Administración Tributaria) confirms the supplier's tax registration is active. Since January 2025, the RFC is mandatory for nearly all business operations in Mexico — invoicing, banking, contracts.

China — UnionPay and the language verification problem

China is structurally different from every other major market and is where most off-the-shelf verification platforms fail. Three things make Chinese verification hard:

1. Two parallel rails. Domestic Chinese payments run on UnionPay (CUP) and the China National Advanced Payment System (CNAPS). UnionPay debit card numbers — the typical destination for international payouts to individuals — start with 6, 62, or specific issuer prefixes. International payments arrive via SWIFT and route through a corresponding Chinese bank.

2. The character mismatch problem. Chinese companies are registered in the official commercial registry under their Chinese-character name. The international payment system, which is in Latin script, requires the company name in English (or pinyin). The English name often is not a direct phonetic translation — it's whatever the company chose for international business. Verification systems that match the registered name against the invoice often fail because they're comparing two different languages of the same legal entity.

3. Individual versus business accounts. Personal UnionPay cards belong to Chinese nationals only; the holder must be the registered owner. Cross-border verification of an individual account often confirms the card is valid but cannot confirm the holder identity through public records.

What works for Chinese supplier verification:

• Verify the legal entity through China's National Enterprise Credit Information Publicity System (NECIPS) using the Chinese-character name and the Unified Social Credit Code (USCC, 18 alphanumeric characters).
• Confirm that the English name on the invoice maps to the same registered entity — typically by cross-referencing both the Chinese-character name and the USCC.
• For UnionPay payments to individuals, verify card prefix and validity, but treat the name match as a soft check rather than authoritative.
• Avoid paying Chinese suppliers as individuals when possible — corporate accounts have stronger verification paths.

Singapore and UAE — direct bank verification

Singapore and the UAE have developed mature real-time domestic payment infrastructure with strong verification at the rail level. Both markets support direct bank account verification through their respective national networks.

Singapore uses PayNow, which links bank accounts to phone numbers, NRIC (national ID), or Unique Entity Number (UEN, 9–10 characters for businesses). Verification through PayNow returns the registered account holder name. Singapore also has a strong company registry through ACRA (Accounting and Corporate Regulatory Authority), which makes Tier 1 + Tier 2 verification straightforward.

UAE uses IBAN format (UAE IBANs are 23 characters) and the AANI instant payment platform. The UAE Central Bank's Regulated Entities Database confirms business identity. Verification in UAE is strong at the IBAN level but weaker at the name match — the local market still has gaps in real-time name validation for cross-border payers.

For both markets, payment failures most often occur when the IBAN or PayNow identifier is structurally valid but the company status has changed (license revoked, dormant, restructured). Pair real-time bank verification with a registry status check before payment.

Argentina, Colombia, and Peru — Latin America's regional patterns

Latin America beyond Brazil and Mexico shares a common pattern: each country has a national tax identifier that doubles as the primary entity verification key, plus a domestic payment rail with varying coverage.

The practical reality across Latin America: tax ID verification is robust and well-documented. Bank-account-level name verification is patchy. The strongest cross-border workflow into these markets pairs tax ID validation (Tier 2) with account format validation (Tier 3) and uses transaction-level controls — dual approval, payment hold for new vendors, callback to known phone numbers — to compensate for the gap.

Markets where only registry verification works

Roughly 150 countries have public business registries but no real-time bank verification infrastructure that's accessible to non-resident payers. Most of sub-Saharan Africa, large parts of Southeast Asia, and a handful of smaller European markets fall into this category.

For these markets, the verification workflow shifts to Tier 2 entity verification + structural account validation:

• Confirm the supplier company is registered with the local commercial registry, has a valid status, and the legal name and tax ID match.
• Validate the account number format (IBAN where applicable, or local format).
• Cross-reference the supplier's submitted bank account against any prior payments or vendor master file entries.
• Use SWIFT pre-validation where the receiving bank supports it.
• Apply higher manual controls — out-of-band callback, dual approval, payment hold for first transactions.

This is also where MonitorPay's coverage of 200+ government registries delivers the most value: even when bank-level verification isn't possible, you can confirm the supplier company itself is real and active before sending payment.

Building a cross-border verification workflow with one API

The country sections above show what's possible. The harder question is how to operationalise it across an AP team that pays into thirty markets without building thirty different processes — without becoming a part-time expert in PIX, NPCI, VoP, CoP, ACH, SPEI, and a dozen other rails.

This is the gap MonitorPay's API was built to close. The same request structure works for every country. The right verification rail runs under the hood. The response format is identical regardless of destination — so your AP system has one decision tree, not thirty.

The patterns that make this work in production

The unified API removes the integration burden. The patterns below remove the operational risk:

1. Default to the highest tier the destination supports. If the country has Tier 1 direct bank verification, use it. If only Tier 2 registry verification is available, fall back to that. Tier 3 (format-only) should never be the only check on a meaningful payment.
2. Verify at two events: onboarding and bank detail change. The verification call belongs at the moment a supplier is added and every time their banking information is updated. Verifying at payment time alone is too late — by then, the bank detail change has already entered your ERP and is being trusted.
3. Layer entity verification on top of bank verification. Even in Tier 1 markets, confirming the company exists in official registries catches shell entities and dissolved suppliers that the bank-rail check alone won't surface.
4. Use one API response format across all countries. Different verification rails return different data shapes — VoP returns Match/Close Match/No Match; PIX returns boolean; NPCI returns a status code. A unified API normalizes these into a single decision logic your code can act on.
5. Apply higher controls in lower-tier markets. For payments into countries where only Tier 2 or Tier 3 verification works, compensate with stricter operational controls — dual approval, payment hold for first-time vendors, mandatory callback through known numbers.

The compliance overlay

Cross-border verification is not just an operational question — it's a compliance one. Every payment that leaves your jurisdiction is subject to layered regulatory regimes:

• Sanctions screening — OFAC for US-touching payments, EU consolidated lists for euro-area transactions, UK HMT for GBP transfers, plus country-specific sanctions regimes
• AML and KYB requirements — confirming the supplier's beneficial ownership, business legitimacy, and risk profile before payment
• Country-specific tax compliance — VAT verification for EU suppliers, GST for Indian suppliers, withholding requirements for cross-border services
• Local data protection laws — Brazil's LGPD, EU GDPR, India's DPDP all govern how supplier data can be collected and stored during verification

The verification workflow needs to handle all of these, ideally without making your AP team into compliance experts in fifty jurisdictions. This is where the integrated approach — bank verification + registry KYB + sanctions screening + tax ID validation in one API call — makes the operational difference.

Frequently Asked Questions