Beneficiary account verification: how to stop a cross-border payout reaching the wrong account

A cross-border payout can fail in two ways. It can be late, or it can reach the wrong party. Beneficiary account verification is the control that answers the second risk. It confirms that the account details on an instruction belong to the business your customer means to pay. For a credit union, a tier-2 bank or a licensed money service business, that check sits between a customer instruction and a settlement leg you may not be able to reverse. This article sets out how to build it, what the rules now expect, and what changes when settlement runs on a public blockchain.

What is beneficiary account verification?

Beneficiary account verification proves that a named payee owns the account you are about to credit. It is also called verification of payee, or confirmation of payee in the United Kingdom. The check has two halves.

The first half is existence. The account number, the IBAN or the wallet address is well formed, valid and open. The second half is ownership. The legal name on that account matches the payee on the instruction. Both halves matter. An account can be perfectly valid and still belong to someone else.

This is not sanctions screening, and it is not know your business onboarding. Screening asks whether you are permitted to pay this party. Onboarding asks who the party is. Beneficiary account verification asks whether these coordinates reach that party. Most institutions run all three. They fail reviews when they assume the first two cover the third.

Why do cross-border payouts reach the wrong account?

The usual cause is not a system error. It is a changed instruction. A supplier emails new bank details, the details are false, and nobody calls the supplier back on a known number. The FBI Internet Crime Complaint Center reported more than 2.9 billion dollars in adjusted losses from business email compromise in its 2023 Internet Crime Report, much of it from this pattern. The instruction looks legitimate because, in every respect except the account, it is.

Cross-border adds its own failure modes. Local account formats differ, so a valid IBAN check digit tells you nothing about an Indian IFSC code or a Mexican CLABE. Legal names arrive transliterated, abbreviated, or in another script. Supplier master data goes stale between payments. Intermediary agents truncate the data that would have let you spot the mismatch. Each of these turns a correct payment into an investigation.

There is also a quieter cause. Many institutions verify the payee once, at onboarding, and never again. The account that was verified in March is not the account on file in November.

What do the rules require on verification of payee?

The direction of travel is settled. In the European Union, the Instant Payments Regulation, Regulation (EU) 2024/886, requires payment service providers to offer a verification of payee service for euro credit transfers from 9 October 2025. The payer must be told, before authorising, whether the name and the account match.

The United Kingdom went at the outcome instead. Its Payment Systems Regulator made reimbursement for authorised push payment fraud mandatory from 7 October 2024, with a per claim maximum of 85,000 pounds. Confirmation of payee is the control that sits underneath that liability.

Cross-border rules focus on data rather than matching. FATF Recommendation 16 requires the beneficiary name and account number to travel with a transfer, and requires the receiving institution to hold them. FinCEN advisory FIN-2019-A005 asks institutions to apply verification procedures to changed payment instructions and to report email compromise schemes. None of these rules names a technology. They name an outcome: you know who you paid, and you can show how you knew.

How do you verify a beneficiary account before the first payout?

Build the check once, as a step in payee onboarding, then repeat it on every change. A workable sequence looks like this.

• Collect the account details from the payee directly, through your portal or on their letterhead, never from a message thread.
• Prove the payee exists as a legal entity, using a registry extract, an entity identifier and the know your business file you already hold.
• Match the account name to that legal name. Allow a documented trading name. Do not allow an unexplained difference.
• Call the payee back on a number you held before the request arrived, not one supplied with it, and record who you spoke to.
• Use a verification of payee or confirmation of payee service wherever the corridor offers one, and store the response code it returns.
• Send a small test payment and ask the payee to confirm the exact amount they received.
• Lock the verified details. Any later change restarts this sequence and needs a second approver.

Two rules make the sequence hold. The person who approves a change must not be the person who entered it. And the callback must use contact details that predate the change request. Most published loss cases fail on one of those two points.

Treat a change of bank details as a new payee, not an edit. The moment you call it an edit, you inherit all the trust you built for the old account and apply it to coordinates nobody has verified.

What changes when the settlement leg is a stablecoin transfer?

Two things change, and they pull in opposite directions. The first is that settlement is faster and far harder to recall. A stablecoin transfer confirms in minutes, and there is no correspondent bank to telephone and ask for a courtesy return. Verification has to be complete before release, because after release you are negotiating rather than recalling.

The second is that verification gets better raw material. A wallet address is checkable before you send anything. You can confirm the address format matches the chain, confirm the token contract is the issuer's canonical contract on that chain, screen the address against analytics and your own denylist, and send a very small test transfer. You can then whitelist the address, so a later change needs the same approval chain as a bank change. None of that is available for a correspondent bank instruction.

The messaging layer still carries the record. In a pacs.008 customer credit transfer the payee sits in the creditor and creditor account elements, with the payee's institution in the creditor agent. The interbank leg carries the same identifiers in a pacs.009. If a payout is rejected or returned, a pacs.004 carries the reason, and a camt.056 is how you request a cancellation you may well not get. Verification quality shows up directly in how often you need those messages.

How do you evidence beneficiary account verification for an examiner?

An examiner will not ask whether you believe in the control. They will pick a payout and ask for the file. Keep that evidence on the payee record, not in somebody's inbox.

For each verified payee, hold the source document for the account details, the name match result and its date, the callback note with the number dialled and the person reached, the test payment reference, and the identity of the approver. For each change, hold the same set again, plus the reason the payee gave. Keep an exceptions log for any payout released without a complete check, with the business reason and the authoriser named. Retain all of it for the period your record keeping rule sets, which is five years under the Bank Secrecy Act rules administered by FinCEN.

Then measure the control. Track the share of payouts made to payees verified inside your refresh window. Track how many change requests arrived, how many failed a callback, and how long verification took. A control with no metrics is a policy, and a policy on its own is not evidence.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross-border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. Payee onboarding with know your business and know your customer checks, know your transaction screening, sanctions and politically exposed person screening, FATF Travel Rule data under IVMS101, a settlement address whitelist and a tamper-evident audit trail all run inside the platform. Settlement is in regulated stablecoins on public blockchains, and every payment is ISO 20022 native, so the beneficiary account details you verified are the same ones carried in the pacs.008 and tracked end to end by the unique end to end transaction reference. The verification decision stays yours. The evidence of it stays attached to the payment.