Business email compromise: how to stop payee change fraud in cross-border B2B payments

Business email compromise prevention comes down to one question: how does your firm verify a request to change where a payment goes? In a typical case, an attacker takes over or imitates the email account of a supplier or a senior officer, sends new bank or wallet details that look routine, and the payment leaves to an account the attacker controls. The controls that stop it are procedural, not exotic, and they need to be designed before the first incident rather than after it.

This article covers how the fraud works in cross-border B2B payments, which controls hold up, what changes when settlement runs in stablecoins, and how to allocate the loss with business clients. It is general information, not legal advice.

What is business email compromise in cross-border payments?

Business email compromise, often shortened to BEC, is a form of authorised push payment fraud aimed at businesses. The payer authorises the payment, so the transaction is genuine in every technical sense. What is false is the instruction behind it. The FBI Internet Crime Complaint Center has reported BEC losses in the billions of dollars each year in its annual reports, consistently placing it among the costliest categories of cybercrime it tracks.

Three patterns account for most cases. In supplier impersonation, the attacker sends an invoice or a letter announcing new bank details for a real supplier. In executive impersonation, a message that appears to come from a chief executive or finance director asks for an urgent, confidential transfer. In account takeover, the attacker controls a genuine mailbox and replies inside an existing thread, which defeats most checks based on the sender address alone.

Cross-border payments make each pattern harder to catch. The beneficiary sits in another jurisdiction, account formats are unfamiliar, name checks are not available in every corridor, and the money is often onward-transferred before the payer notices. A payment firm that executes instructions for business clients carries part of that exposure, whether through its own reimbursement policy, its contracts or the expectations of its regulators.

Why do ordinary controls miss it?

Sanctions screening and transaction monitoring are built to answer a different question. Screening asks whether the beneficiary is a listed party, and a mule account opened last week is not. Monitoring compares a payment with the expected activity of the customer, and a supplier payment of a normal size to a supplier the customer pays every month looks normal. The only thing that changed is the account number.

Email checks miss it for a related reason. Domain authentication such as SPF, DKIM and DMARC helps against spoofed domains and lookalike domains, and it is worth enforcing, but it cannot tell a real mailbox from a compromised one. When the attacker is inside the genuine account, every technical signal says the message is legitimate.

Business email compromise does not defeat your controls. It walks around them, because it asks for the one change most firms treat as administration: a new account number for a payee the customer already trusts.

Which controls actually stop payee change fraud?

The controls that work treat a change to beneficiary details as a risk event, not a data update. The list below is the minimum set a reviewer would expect to see, written so each control produces evidence.

• Verify every change out of band. Call the counterparty on a number already held on file, never one supplied in the message requesting the change, and record who called, when, who answered and what was confirmed.
• Apply a cooling-off period. Hold the first payment to a changed account for a set period or until verification is complete, and say so in the client terms so the hold is expected rather than argued.
• Separate the change from the payment. The person who updates beneficiary details should not be the person who releases the next payment to them, which is ordinary dual control applied to master data.
• Use name checks where they exist. Confirmation of Payee in the United Kingdom and Verification of Payee under the EU Instant Payments Regulation give a name match result before funds move, and a mismatch should stop the payment until it is explained.
• Monitor for the pattern, not only the amount. A new or changed payee followed within days by a payment that is larger, more urgent or outside normal timing is the signature of the fraud, and the scenario should hold it for review.
• Train the people who process changes. Operations staff should recognise urgency, secrecy and a request to bypass the usual process as the warning signs they are.

None of this needs new technology. It needs the change process to be written down, followed every time and recorded, so that a reviewer can see which payments went to changed accounts and how each change was verified. See our guide to beneficiary account verification for the checks that apply before a payout is released.

What changes when settlement runs in stablecoins?

A stablecoin settlement leg is final in minutes. That is the reason to use it, and it is also the reason fraud controls must sit before release rather than after. A wire sent in error can sometimes be recalled with the cooperation of the receiving bank. A confirmed on-chain transfer cannot be reversed by the sender, and recovery depends on the issuer freezing the balance or the receiving party returning it, neither of which can be relied on.

Two attack patterns are specific to wallets. In address substitution, a fraudulent message supplies a new wallet address for a counterparty, which is the payee change attack in a different format. In address poisoning, the attacker sends a tiny transfer from an address that shares the first and last characters with a genuine counterparty address, hoping an operator will later copy the wrong one from the transaction history. Both are defeated by the same discipline.

• Pay only to whitelisted addresses, added through the same out-of-band verification as a bank account change and approved by a second person.
• Send a small test transfer to any new address and have the counterparty confirm receipt through a known channel before the full amount is released.
• Compare the full address, never the first and last few characters, and never copy an address from transaction history.
• Screen the destination wallet before release, so an address already linked to fraud or sanctioned activity is stopped regardless of how it reached the instruction.

The record is the advantage. Every on-chain movement is permanent and timestamped, so when a case does occur, the trail of where the funds went is available immediately to the firm, the issuer and law enforcement, which improves the chance of a freeze if the report is fast.

Who bears the loss when a business is deceived?

This depends on the jurisdiction, the type of customer and the contract. The United Kingdom introduced mandatory reimbursement for authorised push payment fraud on Faster Payments and CHAPS from October 2024, but it covers consumers, micro-enterprises and small charities rather than larger businesses, and it does not reach most cross-border payments. For business clients in most markets, the allocation of loss is a matter for the contract.

Write that allocation down before it is tested. Client terms should state which party verifies payee changes, what verification the payment firm performs, how quickly a suspected fraud must be reported, and what the firm will do on notice, such as contacting the receiving institution, requesting a recall or asking an issuer to freeze a balance. A clear process reported fast recovers more money than a generous policy applied late.

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. Settlement runs in regulated stablecoins such as USDC and USDT on public blockchains and completes in minutes with on-chain auditability, and because the platform is ISO 20022 native, with pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns tracked end to end by UETR, every payment to a changed beneficiary can be traced from instruction to settlement. KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101 form, a compliance workbench and a tamper-evident audit trail sit alongside the payments themselves, so the verification behind a payee change and the release that followed it are recorded in one place.