Verification of payee is a check that compares the name a sender enters with the name the receiving bank holds for the account, before the payment is released. The EU requires it for euro transfers, the UK runs it as Confirmation of Payee, and Pix (Brazil's instant payment system) shows the recipient's name before confirmation.
What a payee name check does, and why rails need one
An account number tells a bank where money goes, not who owns the account. An IBAN (the European bank account number), a sort code and account number, a CLABE (the 18-digit Mexican bank account number) and a Pix key all route a payment correctly while saying nothing about the holder. Invoice fraud lives in that gap: a supplier "updates its bank details" and the money lands elsewhere.
A payee name check closes the gap at the one moment it can still be closed, before release. Rails that settle in seconds leave no overnight window to catch a mistake, and in most schemes a warning is advice, not a block.
The rails differ on three things: whether the check is mandatory, what the payer sees (a verdict or just a name), and who does the comparing.
How does verification of payee work in the EU?
In the EU the payer's bank sends the payee's name and account identifier to the payee's bank, which answers before the payer confirms. The duty comes from Regulation (EU) 2024/886, adopted on March 13, 2024, which amends the SEPA Regulation. Its Article 5c says providers must offer the payer a service that verifies the payee, for regular and fast credit transfers alike, free of charge to the payer.
[The European Central Bank's summary][ecb] describes the service as one that informs payers of any discrepancy between the account identifier and the name of the intended payee, with a result of "match", "close match", "no match" or "other" shown before the payment is initiated.
What each verification of payee result means for the payer
Result | What it tells the payer | Sensible next step |
Match | Name and account identifier agree | Release the payment |
Close match | Small difference, such as spelling or a trading name | Compare the names, then decide |
No match | The name does not correspond to the account | Stop and confirm through a channel you already trusted |
Other | The check could not run | Treat as unconfirmed until it does |
Deadlines for verification of payee in the EU, per the [ECB][ecb]
Scope | Date |
Payment service providers in euro-area Member States | October 9, 2025 |
Payment service providers in non-euro Member States | July 9, 2027 |
The scope is euro credit transfers of both kinds, offered by payment service providers, so it is not a check on payments arriving from outside the Union. When a business pays euros from its own bank account, the bank gives it the verdict. On a no match, the payer's bank must warn that authorising the transfer may send the funds to an account the intended payee does not hold, and the payer then decides whether to proceed, according to the European Payments Council's scheme rulebook. The check compares what you typed, so the legal name as the receiving bank holds it matters, and a trading name is the usual source of a close match.
On euro payouts, Lumx destinations on the SEPA rail take the IBAN and the BIC together with the holder details, and the holder is recorded on the destination before any payout runs. The banking partners run the payee name check on a third-party payout, and it counts toward approving the destination. Lumx does not hand back the verdict on its own. See the USDC to EUR page.
Confirmation of Payee in the UK, and the direction behind it
Confirmation of Payee (CoP) is the UK equivalent: before a payment over Faster Payments (the UK's real-time bank transfer network) or CHAPS, the payer's bank checks the payee's account name against the details the payer gave. The Payment Systems Regulator says the check reduces misdirected payments and certain authorised push payment scams, where the payer is tricked into sending the money.
The obligation comes from Specific Direction 17, issued in October 2022, which extended an earlier requirement on the six largest banking groups. It set a compliance date of October 31, 2023 for Group 1 providers and October 31, 2024 for Group 2. The direction was due to expire on November 1, 2026. On July 30, 2026 the regulator opened consultation CP26/2 proposing to remove that expiry date, and asking whether to bring a third group of providers in, with a draft date, in the draft consolidated direction, of after December 31, 2026. We read the consultation and the draft direction, not a final decision, so treat the Group 3 date as proposed.
For a business paying a UK account, the name you hold has to match the account holder's name as the bank records it. Faster Payments is an instant payment system, so a wrong name cannot be pulled back by the sender. A Lumx destination on the FPS rail takes the sort code and account number, with the holder details on the same record, and the partners' CoP check feeds the approval in the same way. See the USDC to GBP page.
What Pix shows the payer before the money moves
Pix does not return a match verdict. It shows the payer the recipient's name and leaves the comparison to the payer. The rule sits in the Central Bank's minimum requirements for the Pix user experience (version 7.3), which every participant has to follow.
The key can be a CPF (the Brazilian individual taxpayer ID), a CNPJ (the company equivalent), a phone number, an email or a random key. Three details from that document matter:
When the payer selects a Pix key, the app queries the Central Bank's key directory and must return the recipient's full name, the CPF with most digits masked, or the full CNPJ, plus the key and the amount, with an option to cancel before confirming.
For a company, the name shown is the trade name if one exists, so it can differ from the invoice.
When the payer types branch and account instead of a key, the app must still return the recipient's name, based on the data typed, before the transaction is confirmed.
The same Central Bank's guide to the special refund mechanism (MED, version 4.3) draws the consequence. A Pix sent by mistake to another recipient is not covered, and the guide recommends that users always check the recipient's name before confirming. Where the mechanism does apply, a fraud recovery request is opened for a transaction that happened at most 80 days earlier.
Lumx pays out over Pix from a BRL account. A Pix destination is registered with a key type and a key value, plus the holder's details. On a payout, the recipient sees the customer's name as the payer, because BRL accounts are named. The flow is in USDC to a Brazilian bank account and on the USDC to BRL page.
What SPEI checks, and what it leaves to you
SPEI (Mexico's interbank transfer system, run by Banxico) routes by CLABE. The CLABE is 18 digits and ends in a check digit, which catches most typing errors, but that is a check on the number. We found no published step in the scheme that returns a name verdict to the payer before release, so the comparison between the name you hold and the account behind the CLABE is yours to make.
What Banxico does publish is evidence after the fact. Its electronic payment receipt service, the CEP, lets anyone with the payment's tracking key (the clave de rastreo, up to 30 alphanumeric characters) download a receipt. Banxico states that CEPs are generated from information supplied by the receiving institutions, so the receipt proves who was credited.
A CEP helps with disputes, not prevention, so on SPEI collect the CLABE and the holder's name and validate both before the first payment.
Lumx treats the holder as part of the record. A SPEI destination takes the CLABE and a holder with a type (business or individual), a tax ID and an address, plus a legal name for businesses or a name for individuals. See the USDC to MXN page.
Which rails return a name, and what the payer sees
What the payer sees before release on each rail, and what Lumx takes in the destination
Rail | What the payer sees | Who compares | Lumx destination takes |
SEPA (euro area) | Match, close match, no match or other | The bank, with the payer deciding | IBAN, BIC, holder details |
Faster Payments (UK) | Result of the account name check | The bank, under Specific Direction 17 | Sort code, account number, holder details |
Pix (Brazil) | Full name, masked CPF or CNPJ, key | The payer | Key type, key value, holder details |
SPEI (Mexico) | No name verdict in the scheme texts we read | The sender, outside the rail | CLABE, holder type, tax ID, name |
FEDWIRE and ACH (US) | Depends on the sending bank | The sending bank | Account, routing number, account type |
For the United States, the Federal Reserve's Payee Name Verification service lets a financial institution verify an intended payee's name against a routing and account number before it issues a payment, on any rail. It is bank-side, so what a business sees depends on its bank. The fields per rail in the last column come from the Lumx create-a-destination reference, and the full list of live rails is on the coverage page.
A routine for the first payment to a new payee
I recommend treating the payee name as data you collect once, at onboarding, and not as a check you run at payout time. Ask the recipient for the legal name exactly as their bank holds it, together with the tax ID, and store the two together. Then confirm any change to bank details through a number you already had, never through the message that announced the change.
The same advice as a routine:
Collect the legal name as the bank records it, and for a company the registered name, not the brand.
Validate the identifier's format before saving it: IBAN checksum, CLABE check digit, CPF or CNPJ digits.
Confirm changed details out of band, using a contact you already had on file.
Keep the reference the rail returns: the end-to-end ID on Pix, the CEP on SPEI.
When a name check is the wrong control
A name check proves that a name matches an account. It does not prove that the person is who they say, that the payment is lawful, or that the funds are clean. A fraudster who holds an account in their own name can send you those details and pass any name check with a perfect match.
It is also the wrong control when the payer cannot see the result. On Pix the payer compares the name, so a business that pays through an interface that hides the recipient's name has removed the only check the rail offers.
What a name on the record looks like on a Lumx payout
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
A payout goes to a destination, which holds the account holder's details and the banking information of the receiving bank. Each destination carries a relationship between the customer and the holder. The value is SELF for the customer's own account, or one of twelve third-party values such as SUPPLIER or EMPLOYEE, and the value chosen has to be true.
Where the customer pays its own account, the API compares the holder with the customer, name included. A holder type that differs from the customer's type returns HOLDER_TYPE_MISMATCH, and a holder tax ID that differs returns HOLDER_TAX_ID_MISMATCH, both with status 403. When the receiving bank's own validation refuses a tax ID, the API returns INVALID_TAX_ID. The codes are in why a stablecoin payout gets rejected.
New destinations go through verification, which includes sanctions screening and the banking partners' payee name check, and a payout cannot run on a destination that is not APPROVED. The destination status moves from UNDER_VERIFICATION to APPROVED, or ends in FINAL_REJECTION, and each change is sent as a webhook event (destinations.under_verification, destinations.approved, destinations.final_rejection), so a bad record shows up while the customer is still in the flow. The payout itself is an off-ramp (what a stablecoin off-ramp is). Cut-offs are in payout limits and cut-offs by rail, the route in what a stablecoin corridor is, and the product in global payments.
Methodology and sources
Read on November 1, 2026: the ECB page on the EU payments regulation, the PSR consultation CP26/2 and draft Specific Direction 17, the Central Bank of Brazil's Pix requirements (version 7.3) and MED guide (version 4.3), Banxico's CEP page, the Federal Reserve's Payee Name Verification page, and the destinations, errors and webhooks pages of docs.lumx.io. Regulation (EU) 2024/886 is cited by number and adoption date with its official EUR-Lex link. The UK Group 3 date is a proposal.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
[ecb]: https://www.ecb.europa.eu/paym/retail/instant_payments/html/instant_payments_regulation.en.html
Cover photo: Akanksha Maurya on Unsplash.
What is verification of payee?
Verification of payee is a check that compares the name a sender enters with the name the receiving bank holds for the account, before the payment is released. The sender's bank asks the recipient's bank and shows a result, such as match, close match or no match. Lumx does not replace the rail's name check: its banking partners run it on destinations and it counts toward approval, but Lumx returns no separate verdict. A payout needs an APPROVED destination, and a SELF destination's name and tax ID are compared with the customer.
Is verification of payee mandatory in the EU?
Yes, for euro credit transfers under Article 5c of Regulation (EU) 2024/886. Payment service providers in euro-area countries had to offer it from October 9, 2025, free of charge to the payer, and those in non-euro countries follow by July 9, 2027, according to the European Central Bank. For EUR payouts, Lumx stores the IBAN, BIC and holder details on the destination before any payout runs.
Does Pix check the recipient's name?
Pix shows it. The Central Bank of Brazil requires the payer's app to return the recipient's full name, with the CPF masked or the CNPJ, before the payment is confirmed, whether the payer used a key or typed a branch and account. There is no match score, so the payer does the comparison. For Pix payouts, Lumx registers a destination with a key type, a key value and the holder's details, and the recipient sees the customer's name as the payer.
Can a payment to the wrong account be recovered?
Usually not by the sender. These rails settle in seconds, and recovery routes need a confirmed fraud, not a typing error: the Central Bank's MED guide says a Pix sent by mistake to another recipient is not covered. On Lumx, the holder record and the destination checks come first, and a confirmation from the recipient after the first payment covers what they cannot.
Does a cross-border stablecoin payout include a payee name check?
The name check, where one exists, sits inside the domestic rail at the end of the route, and the sender in another country does not see it. That moves the work upstream, into onboarding. Lumx takes the holder's name and tax ID on the destination, runs destination verification, and compares a self destination's holder with the customer.
