Preventing Vendor Payment and Wire Fraud in Construction

How the attack actually works

The attack rarely starts with the intended victim. Often, an email account somewhere in the vendor or contractor's supply chain gets compromised first, frequently because it had no multi-factor authentication. Once inside, the attacker doesn't act immediately. They quietly read invoice threads, payment schedules, and correspondence style for days or weeks, learning exactly how that vendor communicates.

When a real invoice or payment is due, the attacker sends an email, sometimes from the compromised account itself, sometimes from a look-alike domain that's one letter off, saying the vendor has 'updated their banking information' and providing new account details. Because the email arrives in an existing thread, referencing real project details, it looks completely legitimate. The payment goes out, and by the time the real vendor calls asking where their money is, the funds are gone.

Why this specifically hits construction hard

Construction involves large, irregular payments to subcontractors and suppliers, multiple parties communicating primarily by email, and a payables process that's often handled by one or two people under time pressure to keep a project moving. That combination of high-value transactions and lean administrative process is exactly what this fraud pattern exploits.

Technical controls that reduce the risk

These controls matter and stop a meaningful share of attempts, but none of them can fully guarantee that a compromised vendor mailbox somewhere in your supply chain won't send a convincing message. That's why the technical layer alone is not sufficient.

• Phishing-resistant multi-factor authentication on every mailbox, internal and reviewed for any external partners you can influence
• Anti-impersonation and inbox-rule monitoring that flags suspicious forwarding rules or look-alike sender domains
• DKIM and DMARC alignment on your own domain so attackers can't easily spoof your company in emails to others
• Mail-flow rules that visibly tag messages from newly registered or look-alike vendor domains

The written verification procedure that actually stops it

The single control that reliably stops this fraud, even when every technical layer fails, is a simple written rule applied without exception: any change to a vendor's banking or payment details, no matter how legitimate the request looks, is verified by phone before the payment goes out, using a phone number already on file, never a number provided in the email requesting the change.

1. Flag any email requesting a change to banking or payment details, from any vendor, regardless of urgency language
2. Do not click reply or use any contact information contained in that email
3. Call the vendor using a phone number already on file from before the request, such as a signed contract or an earlier invoice
4. Verbally confirm the change directly with a known contact at the vendor
5. Only then update payment records and process any pending payment
6. Document the verification (date, who called, who confirmed) for the file

Making the procedure stick

A written procedure that sits in a binder nobody reads doesn't stop anything. It needs to be trained into whoever handles payables, reinforced when a new hire takes over that role, and treated as non-negotiable even when a request appears urgent, because urgency is itself one of the attacker's primary tools.

This procedure also produces documentation that satisfies cyber-insurance questionnaires and ISN or Avetta prequalification packages, which increasingly ask construction firms to demonstrate exactly this kind of control.

Related risks worth addressing at the same time

Firms tightening up payment verification should also review job-site connectivity, since site supervisors handling change orders and approvals over unreliable connections are more likely to work around proper channels under pressure; see our guide to job-site internet options in Northern Ontario. Document control practices that keep drawings and RFIs authoritative and versioned reduce a related category of costly mistakes on the project side.

Sources and further reading

• Canadian Centre for Cyber Security: Business email compromise

Frequently asked questions