Business Email Compromise Is a Payee Verification Failure, Not an Email Security Problem

The FBI's 2025 Internet Crime Report recorded $3.05 billion in Business Email Compromise (BEC) losses in the United States. The corporate response runs almost universally through IT budgets: email filtering, domain authentication, phishing simulation, security awareness training. The email is where BEC begins, and that assumption holds. The payment is where it succeeds, and that assumption is absent from most security frameworks entirely.

Know Your Payee (KYP) or verifying that the account receiving a payment belongs to the intended recipient before that payment is authorised, is the missing control. Understanding why requires following the attack to the point where it breaks down.

How the Attack Works

A BEC attack typically unfolds over weeks. Attackers gain access to a corporate email account through phishing, credential theft, or they purchase it on criminal marketplaces and then do nothing. They read. They learn the cadence of payment instructions, the names of the people who authorise transfers, the format of a legitimate vendor invoice.

When a large vendor or supplier payment is being prepared, they intervene. The communication is mimicked or intercepted, and the account details are substituted. Bank name stays the same. Account number and routing number change. The finance team processes what looks like a routine payment, the payer authenticates correctly, and the funds reach a mule account the attacker controls.

The email was the entry point but the account detail substitution was the attack.

Why Standard Controls Don't Stop BEC

Email authentication protocols verify that a domain is legitimate, not that the content of a message is honest. Multi-factor authentication confirms the payer's identity, not the payee's. Security awareness training teaches employees to spot suspicious emails, but a BEC message that arrives mid-thread, using names and context harvested from weeks of monitoring, does not look suspicious. These controls are necessary. They reduce the frequency of successful account compromise. They do not however close the gap where the loss occurs, which is the vendor bank account substitution — a layer below the email entirely.

A payer who is correctly authenticated can still authorise a wire transfer or ACH payment to the wrong account. Authentication and verification are separate functions, and the US payment system has invested heavily in the former and almost nothing in the latter.

Payments Under False Pretenses – Nacha Names It Correctly

The 2026 Nacha risk management rules introduced a formal definition of "false pretenses" for the first time: payments induced by misrepresenting identity, authority, or the ownership of an account to be credited. BEC and vendor fraud is explicitly within scope. Phase 2, effective 19 June 2026, extends that obligation to all originators and receiving institutions regardless of volume. The definition matters because it locates the fraud correctly. Not as an unauthorised payment, but as a payment authorised under false pretenses because the account ownership was misrepresented. The question Nacha now requires organisations to answer, before a payment moves, is not whether the payer was authenticated. It is whether the supplier or vendor’s account details were verified.

That is not a question email security tools can answer.

What Pre-Payment Verification Does

Pre-payment payee verification confirms that a bank account number, routing number, and account name match before a transaction is submitted, whether the transaction originates from a purchase order, invoice or delivery receipt in the accounts payable workflow.

When an attacker substitutes account details, the verification check returns a mismatch: the account does not correspond to the vendor on record. The payment is then held. This control has a property most BEC controls lack, which is its immunity to the social engineering layer of the attack. The email can be perfectly crafted, and the attacker can have weeks of thread history but, none of that changes the outcome of a payee verification check, because the check does not evaluate the email. It evaluates the account.

Every other BEC control operates on the communication channel the attacker has already compromised. Payee verification operates on the payment channel which the attacker cannot manipulate without substituting account details, which is exactly what the check is designed to catch.

For US corporate treasury and Accounts Payable (AP) teams managing high-value supplier payments and ACH transfers, that is where the exposure sits, and where the Nacha false pretenses requirement points. iPiD's pre-payment payee verification confirms account identity before transactions settle, across the ACH network and beyond.

John Walsh, Head of Payment Services at Citi, puts it directly: "Our collaboration with iPiD will enable us to rapidly scale and accelerate the reach of our Citi Verify solution globally — supporting superior fraud mitigation and driving unparalleled efficiency for our clients." Eftsure, which integrated iPiD's KYP capabilities to extend enterprise vendor payment protection globally, is another example of what closing this layer looks like in practice.

‍