Business email compromise targeting AP departments has become one of the most financially damaging fraud vectors in mid-market companies. The FBI's Internet Crime Complaint Center (IC3) has consistently reported BEC-related losses in the billions annually across U.S. businesses, with AP departments as the primary target. The mechanics are simple and the defense requires specific process controls, not just awareness training.
The typical BEC attack targeting AP runs as follows: a fraudster researches the company's vendor relationships (often from LinkedIn, the company website, or leaked procurement data), then impersonates a known vendor via a spoofed email address or a lookalike domain. The email requests a banking change for future payments — "please update our ACH details to the following account" — and provides new routing and account numbers. If AP processes the request without verification, the next payment to that vendor goes to the fraudster's account. Wire transfers are unrecoverable. ACH returns are possible within limited timeframes but far from guaranteed.
Why AP Is the Target
AP teams process payment change requests routinely. Vendors do legitimately change banks, update remittance addresses, and modify payment preferences. An AP team that processes dozens of vendor banking updates per year has normalized the process to the point where a fraudulent request looks identical to a legitimate one — both arrive by email, both cite an upcoming invoice or pending payment as the reason for urgency, and both ask for the same action.
The attack is effective precisely because it exploits a legitimate, routine AP process rather than a technical vulnerability. No malware, no system breach. The fraudster just needs to send a convincing email and hope the AP team processes it without a verification step.
Smaller attacks — redirecting a single payment to a fraudulent account — are often not discovered until the legitimate vendor follows up about a missed payment, which may be 30–60 days later. By then, the wire transfer or ACH payment is gone. Larger attacks chain multiple payment redirections before anyone notices the pattern.
The Five Controls That Actually Work
We're not saying employee training is worthless — awareness training that teaches AP staff to recognize BEC indicators is a baseline control. But it's not reliable as a primary defense. The controls that reliably prevent BEC fraud in AP are process controls and system controls, not just training.
Control 1: Vendor master change approval workflow. Every change to a vendor's banking information — new account number, new routing number, new payment method — should require an approval separate from the normal invoice processing workflow. This means: the AP clerk who receives the banking change request cannot approve it themselves; a second approver (Controller, AP Manager, or CFO depending on your authority matrix) must sign off before the change is committed to the vendor master. This simple segregation of duties eliminates the scenario where a fraudster convinces a single AP clerk to process a banking change.
Control 2: Independent verification callback. For any banking change request, require a verification call to the vendor using a phone number independently obtained — not a phone number provided in the banking change email, and not a phone number found in the email signature of the request. Use the vendor's phone number from the original contract, the vendor master record, or the vendor's website. Call and confirm that the banking change request is legitimate and that the new account details match what the vendor intended.
This one step is the single most effective BEC defense in AP. A fraudster who has successfully spoofed a vendor's email domain cannot intercept a phone call to the vendor's actual phone number. If the vendor says "we didn't send any banking change request," you've caught the fraud before any money moved.
Control 3: Payment validation against approved vendor master at the time of payment. Wire and ACH payments should validate beneficiary banking details against the approved vendor master record at the moment of payment release, not just at the time of invoice entry. This catches the scenario where a banking change was made after invoice approval but before payment release — a specific attack pattern where the fraudster knows to time the banking change to occur after the invoice is approved so it doesn't disrupt the approval workflow.
Control 4: New vendor verification before first payment. New vendors — particularly those added outside a formal procurement process — should go through a verification step before their first payment is released. This means confirming that the vendor is a legitimate business (basic internet search, LinkedIn check, business registration lookup for significant spend), that the banking details they provided match what a real company in that business would use, and that there's an actual business relationship with a documented purchase history. Fraudsters sometimes add entirely fictitious vendors and submit invoices against them. A verification step before first payment catches this.
Control 5: Anomaly monitoring on payment patterns. Reviewing payment data for pattern anomalies — a vendor's payment amount suddenly 3x their historical average, a new beneficiary account for a long-standing vendor, a payment destination that doesn't match the vendor's historically associated geographic region, or two payments to different accounts for the same vendor in the same payment batch — provides a detective control that catches fraud that slips through preventive controls.
The "Urgency" Red Flag
BEC attacks consistently exploit urgency. The email requesting a banking change will often include language like "we need this updated before the payment scheduled for Friday," or "our old account is being closed at end of month — please update immediately." The urgency is designed to bypass the verification step — creating time pressure that makes the AP clerk feel like they don't have time to call and verify before the payment runs.
Establishing an explicit AP policy that urgency framing in a banking change request is a red flag — not a justification for expediting the change — is important. The correct response to "please update before Friday" is not to update before Friday without verification; it's to make the verification call immediately so that if the request is legitimate, the update can still happen in time.
Training your AP team to recognize this pattern and establish the habit of calling rather than updating is more valuable than any amount of phishing awareness training. The behavior pattern to build is: banking change request received → independent callback initiated immediately, regardless of urgency language in the request.
Wire vs. ACH: Different Risk Profiles
Wire transfers are the high-risk payment method for fraud purposes because they're irrevocable. Once a wire is sent to a fraudulent account, recovery requires law enforcement involvement and international cooperation if the funds have crossed borders. Recovery rates on fraudulent wire transfers are low — typically 30–50% if reported to the FBI within 24–72 hours through the Financial Fraud Kill Chain, and close to zero if reported later.
ACH payments can be returned within the NACHA rules framework: an unauthorized ACH debit can be returned up to 60 days after settlement using the R10 return code (unauthorized debit). An authorized ACH credit sent to the wrong account is more complex — NACHA's rules don't provide the same return mechanism for credit payments, and recovery depends on the receiving bank's cooperation.
This asymmetry argues for heightened verification requirements on wire transfers specifically: any wire payment above a threshold (commonly $25,000–$50,000 in mid-market AP policies) should require a second approver and a verbal confirmation with the vendor before release. The marginal inconvenience of a 3-minute phone call is substantially less than the consequences of an irrecoverable fraudulent wire.
The Vendor Impersonation Variant: Invoice Fraud
Beyond banking change requests, a related fraud pattern involves submitting entirely fictitious invoices from lookalike vendor email addresses. The fraudster doesn't need to redirect a banking change — they create an invoice that looks like one from a legitimate vendor (matching invoice number format, logo, similar but slightly different amount) and submit it through the vendor's normal invoice submission channel.
Invoice fraud of this type is caught by: duplicate detection against historical invoices from the same vendor, PO validation (a fraudulent invoice for services not authorized by a PO fails the PO matching check), and vendor authentication at invoice submission (a supplier portal with verified login credentials prevents invoice submission from an impersonated email address).
The common thread across all AP fraud prevention controls is that they work best in combination. A single control — verification callback, duplicate detection, or approval workflow — can be targeted or circumvented by a sophisticated attacker. Layered controls are substantially more difficult to defeat, and the combination of preventive controls (vendor master approval workflow, payment validation), detective controls (anomaly monitoring, GR matching), and procedural controls (callback verification policy) creates a defensible AP fraud prevention framework without materially slowing down legitimate payment processing.
