How to Prevent Vendor Payment Fraud in Accounting Firms

Accounting firms manage payments for multiple clients, creating a large attack surface with many vendor relationships and high transaction volumes. The attacker's goal is to intercept a legitimate vendor payment request and redirect it to a fraudulent account by changing bank details via email.

Coalition's 2025 Cyber Claims Report found that BEC and funds transfer fraud accounted for 60% of total cyber insurance claims in 2024, with nearly 30% of BEC incidents escalating to actual funds transfer. The pattern is consistent: the attacker monitors email conversations between your firm and a vendor, waits for an invoice to come due, then sends a follow-up message requesting a bank account change.

The attack succeeds because it exploits trust in existing vendor relationships and the routine nature of payment processing. Your accounts payable team sees an email from a known supplier, using the vendor's branding and employee names, asking for updated payment details. The message looks legitimate. The timing makes sense. The request goes through.

The multi-client structure amplifies the risk. One firm might manage payments for a dozen offshore entities, each with its own vendor list. A single compromised email thread can give the attacker access to payment conversations across all your clients who work with that vendor.

The attacker either compromises a legitimate vendor's email account or creates a nearly identical lookalike address, then monitors ongoing payment conversations. When a real invoice is due, the attacker sends a follow-up email requesting a bank account change, using the vendor's branding, employee names, and signatures to appear legitimate.

The request often creates urgency. Payment due before a holiday. End-of-month deadline. Vendor switching banks and needs the change processed immediately. The pressure tactic is designed to make your team skip verification and process the change without a second check.

A regional bank case study documented a business that nearly lost $17,000 after a convincing message from a trusted supplier requested payment to a fraudulent account. The attack succeeds because it exploits trust in existing vendor relationships and the routine nature of payment processing.

The two attack methods are account compromise and lookalike domains. In the first case, the attacker gains access to the vendor's real email account and can read prior correspondence, insert themselves into ongoing threads, and send messages that appear in the legitimate conversation history. In the second case, the attacker registers a domain that looks nearly identical to the vendor's real domain and sends messages from an address your team might not catch on first glance.

The lookalike domain tactic is simple but effective. The real vendor is vendor-supplies.com. The attacker registers vendor-supply.com or vendorsupplies.com. The email comes from the same employee name your team recognizes, with the same signature block, referencing the same invoice number from last week's conversation. The only difference is one character in the domain name.

An authorization workflow requires a second authorized person to review and approve any vendor bank detail change before it takes effect in the payment system. The change request goes into a pending state, the second approver verifies the request through a separate communication channel, and only then does the new bank detail become active.

The verification step is critical: call the vendor at a known number, not the number in the email. If the vendor confirms the change, the approver signs off and the new bank details go live. If the vendor has no record of the request, the fraud attempt stops before any payment goes out.

This control stops the single-actor fraud vector. One person cannot change a vendor's bank details and release a payment to the fraudulent account without a second person catching the discrepancy. The attacker's email may fool the first person who sees it, but the authorization workflow forces a verification step that breaks the attack chain.

The workflow in practice looks like this: your accounts payable clerk receives an email requesting a bank detail change. The clerk enters the new details into the system, but the change does not save to the vendor record. Instead, it creates a pending authorization request. The system notifies the second approver. The approver sees the request, pulls the vendor's contact information from the existing record, calls the vendor directly, and asks whether they requested the change. If yes, the approver authorizes and the change takes effect. If no, the approver rejects and the fraudulent request is flagged.

The separate communication channel is what makes the control work. Email is compromised. The phone number in the fraudulent email goes to the attacker. The only safe verification path is the contact information already on file before the change request arrived.

Dual-approval requires two separate people to authorize a payment before it releases, reducing the risk that a single compromised employee or fraudulent actor can move money. The control works when the approval process is fast enough that the team enforces it consistently.

The control backfires when approval delays cause the team to create workarounds. Shared logins. Pre-signed checks. Blanket approvals for anything under a certain dollar threshold. The friction problem is real: if the approval process adds days to payment cycles, the team will route around it, and the control becomes theater instead of protection.

The key is to make the approval workflow part of the normal payment batch process rather than a separate manual step. If the second approver can review and authorize a batch of payments in one session, the control stays enforced. If every payment requires a separate email thread, phone call, and manual sign-off, the team will find a way to bypass it.

The workaround patterns that signal the control is failing: the same person submits and approves payments because the designated approver is unavailable. The team processes urgent payments outside the system and reconciles later. The approver signs off on batches without reviewing individual line items because the queue is too long. These are not compliance violations. These are operational signals that the approval process is too slow for the payment volume.

The fix is not to eliminate dual-approval. The fix is to reduce approval latency. Batch payments by day or week instead of processing one at a time. Give the approver a single queue to review instead of scattered email requests. Make the approval action fast enough that the team does not need to route around it to meet payment deadlines.

An audit log records who changed vendor bank details, when, what the before and after values were, and who approved the change. When fraud happens, the audit trail is what your bank, insurer, and law enforcement need to trace the fraudulent transaction and establish liability.

The log should be immutable. No one can delete or edit past entries. The record is queryable per vendor, per user, and per date range. If a payment goes to the wrong account, you can pull the full history: who requested the bank detail change, who approved it, when the approval happened, and what the original bank details were before the change.

The audit trail does not prevent fraud. It enables recovery. When your bank asks for documentation to support a fraud claim, the audit log is the evidence that shows the fraudulent change was not authorized through your normal process. When your insurer evaluates the claim, the log demonstrates that you had controls in place and the fraud bypassed them through social engineering rather than negligence.

The query you run when investigating a fraud incident: filter the audit log by vendor name, pull all bank detail changes in the last 90 days, and review who requested each change and who approved it. If the fraudulent change shows up in the log with a single user both requesting and approving, that is evidence the authorization workflow was bypassed. If the change shows up with proper dual-approval but no verification call was logged, that is evidence the verification step was skipped. The log tells you where the control failed.

The immutability requirement matters because the attacker may have ongoing access to your systems after the fraudulent payment goes out. If the audit log is editable, the attacker can delete the evidence of the bank detail change. If the log is append-only, the record survives even if the attacker compromises an admin account.

Train staff to recognize urgent requests to change payment details before holidays or weekends, slight misspellings in email addresses, requests to send payments to unfamiliar bank accounts, and messages that create pressure for immediate action. The verification rule is simple: any bank detail change request requires a phone call to the vendor at a known number instead of the number in the email before processing.

Make it clear that slowing down to verify is the correct response rather than a workflow failure. The attacker's urgency tactic is designed to make your team feel like they are causing a problem by asking questions. The opposite is true: the person who pauses to verify is doing their job correctly.

The specific red flags to train on: an email from a vendor you have worked with for years suddenly uses a different domain. A payment request arrives on a Friday afternoon with a Monday deadline. The email references an invoice number that matches your records but asks for payment to a bank account in a different country than the vendor's usual location. The message tone is more formal or more casual than the vendor's normal communication style.

The controls create the structure, but the team's ability to recognize and question suspicious requests is what makes the controls work in practice. Authorization workflows and dual-approval processes stop fraud when the team enforces them. Training ensures the team knows what to look for and feels empowered to question requests that do not follow the normal pattern.

The training should be specific to your firm's vendor relationships. Walk through real examples of legitimate vendor communication so the team knows what normal looks like. Show examples of lookalike domains and compromised email threads so the team can spot the difference. Make the verification process part of the standard operating procedure, not an exception that requires manager approval.