Fraud and Risk

Vendor Impersonation and Business Email Compromise

How vendor impersonation and business email compromise attacks target AP teams in Australia, the methods used, and the controls that prevent fraudulent payments.

Vendor impersonation is a social engineering attack in which a fraudster poses as an existing supplier to redirect payments to a bank account they control. Business email compromise (BEC) is the most common mechanism: the fraudster sends an email that appears to come from a legitimate supplier -- often using a spoofed or near-identical email address -- requesting that the supplier's bank account details be updated before the next payment is made. If the AP team processes the request without verification, the next payment goes to the fraudster's account rather than the real supplier.

The Australian Competition and Consumer Commission's Scamwatch reported AU$152.6 million in business email compromise losses to Australian businesses in 2024. The median loss per incident was AU$35,000. The real figure is believed to be materially higher because many incidents go unreported due to reputational concerns. AP teams are the primary target because they have the authority to change payment details and make payments, and because the volume of supplier communication they handle makes individual requests easier to lose in the noise.

How BEC attacks are structured

A typical BEC attack targeting the AP function begins with reconnaissance. The fraudster identifies the business's AP contact details, the supplier being impersonated (often from a compromised email account or public information), and the timing of upcoming payments -- sometimes by monitoring email threads they have gained access to. The attack is then timed to coincide with a real payment cycle.

The impersonation email typically claims an urgent reason for the bank account change: a new banking provider, a bank account compromise, an end-of-quarter cash flow requirement. Urgency is used deliberately to discourage the AP team from following a slower verification process. The email may include a fake letterhead, a reference to recent conversations or invoice numbers obtained through prior access, and contact details that route back to the fraudster rather than the real supplier.

More sophisticated attacks involve actually compromising the supplier's email account, so the request appears to come from the legitimate email address. In these cases, email header inspection and domain-based verification are the only technical signals available -- the email address is genuine, but the account sending it is under the fraudster's control.

Prevention controls

The single most effective control against vendor impersonation and BEC is a callback verification policy: any request to change a supplier's bank account details must be verified by calling the supplier on a phone number already held in the vendor master file -- not a phone number provided in the same email making the request. This policy, applied consistently, stops the vast majority of BEC attacks because the fraudster cannot intercept a call to the legitimate supplier's established number.

Bank account change requests should require dual authorisation -- two people must approve the change before it is made in the accounting system. This removes the single point of failure that most BEC attacks exploit. The person receiving the request and the person approving the change should both be required to confirm the callback was completed.

Technical controls include email authentication settings (SPF, DKIM, DMARC) that reject or flag spoofed emails, and AP automation platforms that enforce bank account verification during supplier onboarding and flag changes to existing bank account details as high-risk events requiring additional review. Training AP staff to recognise BEC indicators -- urgency, unusual requests, slightly wrong email addresses -- reduces the likelihood that the initial request is processed without question.

When a fraudulent payment is made, the recovery window is narrow. The bank should be notified immediately; Australian banks are required to treat these as priority cases and can initiate a recall within the payment system if the funds have not yet been withdrawn from the receiving account. The ACCC and Australian Federal Police should also be notified, though recovery through law enforcement is slow and uncertain compared to bank-initiated recalls.

Related terms

See it in action

Payment Security

Learn more
Back to full glossary