Verification of payee in instant payments: how rails check the recipient before money moves

Verification of payee is a check that compares the name a sender enters with the name on the receiving account before an instant payment is sent. The EU made it mandatory for euro payments on 9 October 2025, the UK has run Confirmation of Payee since 2020, and Pix shows the payer the recipient's name before confirmation. Cross-border payouts through providers such as BlindPay still need the sender to verify new payees.

The reason is simple. Real-time settlement removes the window in which a bank used to catch a mistake. Once the money lands, it's gone.

Key takeaways

• Instant payments settle with finality in seconds, so the name check has to happen before the payment, not after.
• The EU's Verification of Payee returns one of four results: match, close match, no match, or other. It became mandatory in the euro area on 9 October 2025, free of charge to the payer.
• The UK's Confirmation of Payee launched in 2020 and runs more than 2 million checks a day, according to Pay.UK.
• Pix shows the payer the name behind a Pix key. Brazil's MED refund route doesn't cover a payment sent to the wrong person because the sender skipped the name.
• The US has no scheme-wide name check yet. The Federal Reserve offers a rail-agnostic Payee Name Verification service, and FedNow said in April 2026 it is exploring a real-time version.

What is verification of payee?

Verification of payee is a pre-payment check where the sender's bank asks the recipient's bank whether the name the sender typed matches the account. The answer comes back in a second or two and is shown to the sender before they confirm.

It exists because an IBAN, a CLABE, or a sort code tells you where money goes, not who owns it. Fraudsters exploit that gap. An invoice arrives with "updated bank details", the sender pays, and the money lands in an account the supplier never owned.

This type of fraud has a name: authorized push payment fraud, or APP fraud. The payer authorizes the payment themselves, so card-style chargebacks don't apply. A name check is the cheapest defense against it, because it catches the mismatch before the money moves.

Why does a name check matter more on real-time rails?

On a real-time rail, the payment is final in seconds, so there's no overnight window to stop it. On a batch rail like ACH or a SWIFT wire, a bank sometimes catches an error or a fraud signal before settlement. Instant rails remove that buffer.

The speed is the feature, and the irrevocability is the cost. Are stablecoin payments reversible? covers the same trade-off for on-chain transfers, where finality is also measured in seconds.

Two schemes show what happens after the fact:

• Brazil. The Banco Central do Brasil's Pix security page explains that the Mecanismo Especial de Devolução (MED), the special refund mechanism, can block and return funds in confirmed fraud cases if requested within 80 days. It lists the cases MED doesn't cover, including a Pix sent to the wrong person because the sender didn't check the name. The same page tells users to always check the beneficiary's name before confirming.
• United Kingdom. Since 7 October 2024, UK payment providers must reimburse in-scope victims of APP scams on Faster Payments up to £85,000 per claim, under the Payment Systems Regulator's reimbursement rules. That puts the cost of a missed check on the banks, which is one reason they lean on Confirmation of Payee.

Recovery is slow, partial, and narrow. Prevention is the part that works.

How does verification of payee work in the EU?

In the EU, the payer's provider sends the payee's name and IBAN to the payee's provider, which compares them with its records and returns a result before the payment is sent. The rule comes from the Instant Payments Regulation, Regulation (EU) 2024/886.

The European Central Bank's summary of the regulation lists four possible results: "match", "close match", "no match", or "other". The payer sees the result before initiating the payment. The check applies to instant payments and to regular SEPA credit transfers, and it must be free for the payer.

What each result means in practice:

The deadlines, from the same ECB page:

The payer keeps the final decision. A no match result doesn't block the payment. It warns, and the payer chooses. If you pay out to EU recipients, the name you send now matters as much as the IBAN. How to off-ramp USDC to euros over SEPA covers which beneficiary fields to collect.

How does Confirmation of Payee work in the UK?

The UK's Confirmation of Payee (CoP) is an account name check that runs before a payment is sent or collected, and it also checks whether the account is personal or business. Pay.UK operates it as an API-based, peer-to-peer service with a directory of participants and no central database.

It launched in 2020, more than 300 organisations have implemented it, and it completes more than 2 million checks a day, according to Pay.UK. The Payment Systems Regulator mandated its expansion in 2024.

The results work like the EU model: match, close match with the correct name shown, or no match. The account type check matters for business payments. A supplier invoice that points to a personal account is a classic fraud signal, and CoP surfaces it.

How does Pix show who you're paying?

Pix shows the payer the name registered to a Pix key before the payment is confirmed. A Pix key is an alias, such as a CPF, CNPJ, phone number, email, or random key, stored in the DICT, the Banco Central's directory of transactional account identifiers.

When a payer enters a key, their bank looks it up in the DICT and displays the account holder's name. The payer confirms or cancels. There's no match score. The payer compares the name themselves, which is why the Banco Central's guidance says, plainly, check the beneficiary's name before you confirm.

The DICT also carries fraud data: institutions share information on keys and accounts involved in fraud, can hold suspicious transactions for extra analysis, and can place a precautionary block, per the same Banco Central page.

The MED got broader in 2025. Resolution BCB 493, published 28 August 2025, introduced MED 2.0, which traces stolen funds beyond the first receiving account (Banco Central MED 2.0 overview). It's still a fraud tool. A payer who typed the wrong key and didn't read the name has no MED claim.

Pix keys, CPF, and CLABE payout details covers which identifiers to collect for Brazil and Mexico, and Pix vs SPEI compares the two rails.

What does Mexico's SPEI check?

SPEI, Mexico's interbank instant payment system run by Banco de México, routes payments by CLABE, the 18-digit standardized account number with a check digit. The check digit catches most typos, but SPEI doesn't return a name match result to the payer before sending.

What SPEI offers instead is proof after the fact. Banco de México's CEP service (Comprobante Electrónico de Pago) lets anyone download an electronic payment receipt using the payment's tracking key, the clave de rastreo. Banxico states that the CEP is generated from information the receiving institution provides, so it shows who the receiving bank credited.

That makes CEP useful for disputes and reconciliation, not for prevention. The prevention step on SPEI is yours: validate the CLABE check digit, confirm the account holder's name with the recipient, and keep the CEP for your records.

What about the US?

The US has no scheme-wide payee name check that returns a match result to every sender, the way the EU and UK schemes do. What exists is bank-level tooling.

The Federal Reserve's Payee Name Verification service lets a financial institution check an intended payee's name against a routing and account number before issuing a payment. It's rail-agnostic and initially uses 12 months of historical transaction data. In an April 2026 release, the FedNow Service said it is exploring how to enable Payee Name Verification for real-time needs.

So a US instant payment over RTP or FedNow may or may not get a name check, depending on the sending bank.

How do the major rails compare?

The EU and UK return a structured result; Pix shows the name and leaves the comparison to the payer; SPEI and the US rely on the account number plus bank-level tools.

How should a sender check the recipient before a real-time payout?

Treat every new or changed payee as unverified until you confirm the name through a second channel. A five-step routine covers most of the risk:

1. Collect the legal name exactly as the bank holds it. For a business, that's the registered company name, not the trading name. For an EU payout, a close match on a trading name is a common false alarm.
2. Validate the identifier's format. Check IBAN checksums, CLABE check digits, and CPF or CNPJ digits before saving. Format errors are the easy wins.
3. Confirm changed bank details out of band. If a supplier emails new details, call a number you already had on file. Don't use the contact details in the email that asked for the change.
4. Send a small first payment. For a new payee on a high-value flow, a small test payout followed by the recipient's confirmation proves the account and the name.
5. Keep the proof. Store the payment reference: the end-to-end ID on Pix, the CEP on SPEI, the UETR on SWIFT. How to track an off-ramp payout lists the reference each rail returns.

Common stablecoin payout mistakes covers the bank-details errors that cause most failed or misdirected payouts.

Why don't cross-border payouts always get the same check?

Because the name check lives inside each domestic rail, and a cross-border payout reaches that rail through an intermediary. The intermediary, not the original sender, is the one talking to the domestic scheme.

On a SWIFT wire, the beneficiary name travels in the payment message, but there's no network-wide match result returned to the sender before the payment leaves. Each receiving bank applies its own rules about whether a name mismatch blocks the credit.

On a stablecoin payout that lands over Pix or SEPA, the last leg is a domestic payment sent by the provider's local institution. The sender in another country never sees a match screen.

That's why the verification work moves upstream, into how you onboard payees. What is real-time cross-border settlement? explains where the cross-border and domestic legs split, and Which countries have instant payment systems? lists the rails at the end of each corridor.

How does BlindPay handle recipient details?

BlindPay validates recipient account details when you add them, before any payout runs, and pairs that with your own name confirmation for new payees.

What BlindPay does, from the bank accounts docs:

• Format and country validation at creation. Every bank account is checked against regex, length, and country rules, on development and production instances alike. A malformed IBAN, CLABE, or CPF fails when you save it, not when you pay.
• Beneficiary names on the record. PIX Safe, TED, SPEI, and SEPA accounts carry a beneficiary name field. SEPA also requires the beneficiary's legal name and address, and the IBAN's country code must match the beneficiary's country.
• SWIFT/BIC lookup. GET /available/swift/{swift} returns a bank's name, city, branch, and country for a SWIFT/BIC code, so you can prefill and confirm bank details before a SWIFT (POBO/COBO) payout.
• Compliance in the flow. Every payout runs through a customer that has passed KYC or KYB, with transaction screening on top.

Payouts settle over Pix, PIX Safe, TED, SPEI, ACH, RTP, wire, SEPA, Transfers 3.0, ACH Colombia, and SWIFT (POBO/COBO), listed in payment methods. On the instant rails, the payout is final in minutes, which is exactly why the payee check belongs before the first payout.

This article is for information only and is not legal advice.

What to do next

Add a payee verification step to your onboarding flow before your first instant payout: legal name, validated identifier, out-of-band confirmation for changes. Then save a bank account on a free development instance and see which fields BlindPay validates for each rail.