Vendor banking detail fraud is one of the most consistently effective fraud patterns in business operations. The attacker compromises a vendor email account or impersonates the vendor through other means, sends a change of banking details request to the buyer's AP team, and waits for the buyer to redirect the next payment to the new account. By the time anyone notices, the fraudulent account has been emptied.
The fraud works because the attack point is mundane. Banking detail changes happen legitimately all the time. Vendors switch banks, change accounts after corporate restructurings, update routing as part of normal business operations. An AP team processing a banking change request is doing routine work, not handling something they would naturally scrutinize.
The controls that prevent this fraud have to operate at the moment the banking change is requested, before any payment is sent to the new account. After the payment, recovery is often impossible. The window for prevention is narrow but the control structure is well established for those who implement it.
How the Fraud Pattern Works
The standard fraud pattern follows a predictable sequence.
Compromise the vendor side
The attacker gains access to a vendor's email system, either through phishing, credential theft, or other means. They monitor the email for relationships with target buyers and identify high value transaction patterns.
Send the change request
From the compromised vendor email, the attacker sends a banking change request to the buyer's AP contact. The request looks legitimate because it actually comes from the vendor's email domain and addresses the right contact at the buyer.
Wait for the next payment
The buyer processes the change. The next invoice payment routes to the new account. The attacker withdraws the funds and disappears.
Discovery is delayed
The actual vendor does not receive the payment and eventually inquires about it. By the time the inquiry comes, the funds are typically gone and the fraudulent activity becomes visible. Recovery from the fraudulent account is rare.
Variants of the Pattern
The basic pattern has several variants that change the specific attack vector but follow the same underlying logic.
Look alike domain attack
The attacker does not compromise the vendor's actual email but creates a look alike domain (vendor.com vs vendor1.com or vendor.co). Emails from the look alike domain are nearly indistinguishable from legitimate vendor email. The change request comes from the look alike.
Vendor portal compromise
If the buyer uses a vendor portal that allows vendors to maintain their own banking details, the attacker compromises the vendor's portal credentials and changes the banking details directly. No email is needed; the change flows through the portal as if the vendor initiated it.
Phone based social engineering
The attacker calls AP claiming to be from the vendor, citing knowledge of recent invoices or open POs, and requests the banking change verbally. Where AP accepts verbal banking changes, the attack can succeed without any electronic compromise.
Insider involvement
In some cases, the attacker has an inside collaborator who facilitates the change processing or suppresses the controls that would have caught it. These attacks are less common but harder to detect because internal control bypass is part of the design.
The Verification Workflow That Works
Effective control of banking changes requires a specific verification workflow that does not depend on the channel through which the change was requested.
Out of band verification
The change request is verified through a channel different from the channel through which it was received. If the request came by email, verification happens by phone. If by phone, verification happens by email or letter. The principle: an attacker who has compromised one channel is unlikely to have compromised multiple channels simultaneously.
Known contact list
The verification phone call goes to a contact at the vendor whose phone number is on file from prior known good interactions, not from the change request itself. A change request that includes a phone number to call for verification provides no verification, because the attacker can answer the phone they provided.
Sufficient verification depth
The verification call confirms specific details: the change itself, the new account information, the authorized signatory, the reason for the change. A brief yes confirmation is insufficient; the call needs to verify the substance of the change.
Documentation of the verification
The verification gets documented: who called whom, when, what was confirmed, the basis for confirming the verifier was authorized. The documentation supports the change record and provides evidence if questions arise later.
Multi Point Verification for Material Changes
For higher value vendors or larger payment streams, single point verification may be insufficient. Additional verification adds layers of control.
- Two person verification: two AP staff independently verify the change with two different contacts at the vendor
- Approval at elevated authority: changes for high value vendors require approval beyond AP, typically by AP leadership or finance
- Holding period: the change is applied but payments are held for a defined period (typically 24 to 72 hours) before processing, during which the actual vendor would notice any unauthorized change
- Notification to the prior banking contact: notification of the change is sent to the prior banking contact, providing a check if the change was unauthorized
Not every change needs every layer. The intensity should match the risk. High value vendor changes warrant more layers than routine small vendor changes.
What AP Staff Need to Know
Front line AP staff are the primary defense against banking fraud. The training and awareness they have matters more than any policy document.
Recognize the pattern
AP staff should know that banking detail change requests are a fraud vector and that the request itself should trigger heightened attention. An unexpected change request, even from a known vendor email, requires verification.
Resist urgency pressure
Fraudulent change requests often include urgency: payment is needed immediately, the change must happen now, delays will create vendor issues. AP staff need to be supported in resisting urgency and completing verification despite pressure.
Escalate uncertainty
When something feels off about a request, AP staff should escalate rather than process. The cost of a brief processing delay is far lower than the cost of a fraudulent payment that cannot be recovered.
Routine practice on the verification workflow
The verification workflow needs to be routine, not occasional. Staff who follow the workflow only sometimes are more likely to skip it under pressure. Consistent application makes the workflow feel like normal work rather than friction.
When Fraud Does Occur
Despite good controls, some fraud incidents occur. The response after the fact matters.
- Immediate notification to the bank. Most banks have specific procedures for fraudulent payment reporting and may be able to recall payments that have not fully cleared.
- Notification to the actual vendor. The vendor needs to know that fraudulent activity affected their account so they can investigate their own security.
- Investigation of the attack vector. How did the attacker get the information needed to attempt the fraud? Was the vendor compromised, was a buyer system compromised, was social engineering used?
- Control review and tightening. The specific control gap that allowed the fraud needs to be addressed. Other similar gaps should also be reviewed before the next attempt.
- Insurance and recovery. Cyber insurance and crime insurance policies may cover some of the loss. Recovery from the fraudster is rare but not impossible if law enforcement engagement is timely.
Start Here
Walk through your current banking change verification workflow with the AP team. Is the workflow documented? Is it followed consistently? Are out of band verifications routine or occasional? The honest assessment usually reveals gaps.
From the assessment, the highest leverage fix is establishing the out of band verification as a routine requirement with no exceptions for routine banking changes. The workflow gets easier as it becomes habit.
