Key takeaways

  • Vendor-payment fraud works because the request looks routine. The control that stops it is a rule about process, not a smarter inbox.
  • Treat every change to a vendor's bank details as a change to master data: verified through a known contact, approved by a second person, and followed by a hold on the first payment.
  • Callback verification must use the phone number already in the vendor file, never one supplied in the request.
  • DMARC with a policy of p=reject (RFC 7489) blocks mail that spoofs your exact domain. It does not stop lookalike domains, compromised vendor mailboxes or display-name tricks.
  • Act within hours if a fraudulent payment is made. The FBI Internet Crime Complaint Center and your bank's wire-recall process work best when the report is fast.
  • Segregation of duties is the strongest single control: nobody both changes vendor details and releases payment.

The scam in one paragraph

Accounts payable receives an email that appears to come from a regular vendor or a senior colleague. It says the vendor has changed banks and asks that the next payment go to a new account, with a polite attachment on letterhead. The message might come from a lookalike domain, from a real mailbox the attacker has taken over, or from a spoofed address. Nobody has to break into your network. If the payment is released, it leaves quickly, often through several accounts. The FBI's Internet Crime Complaint Center reports business email compromise among the costliest categories of cybercrime year after year, with losses in the billions of dollars annually.

Our article on business email compromise for law firms and real-estate closings covers the same scam in one setting, and our article on callback verification covers how to make the phone check hold up against cloned voices. This article is for the finance team: how to design the accounts-payable process so that one convincing email cannot move money.

Treat bank-detail changes as high-risk changes

Software teams know the idea of change control: a risky change needs a request, a review and a record. A vendor's bank account is the same. Define a small number of fields as controlled, namely bank account, routing number, payee name and remittance address, and apply these rules every time one changes.

  • One request channel. Changes arrive through a form or a portal, not as a reply to an invoice email.
  • Callback verification. A named person phones the vendor on the number already held in the vendor file, from before the request. Never use the number in the request, the invoice or the signature block.
  • Ask a question the attacker cannot answer from email, such as the last invoice number, the name of the account manager or the usual payment day.
  • Two people. The person who changes the record is not the person who approves it, and not the person who releases payment.
  • A written record of who called, when, whom they spoke to and what was said, attached to the change.
  • A hold on the first payment after a change, with a small test payment or a longer review for large amounts.
  • Notification to the previous contact on file that the bank details changed, so a real vendor can say it did not ask for that.

Payments: friction in the right places

  • Dual approval above a threshold, set so that it catches the large payments that matter and not every small one.
  • Payee validation or account-name matching where your bank offers it, and positive pay for checks.
  • Alerts on unusual patterns, such as a first payment to a new account for a long-standing vendor, a payment just under the approval limit or a request marked urgent.
  • A rule that urgency, secrecy or a request to bypass the process is itself a reason to escalate. A message that says the CEO is travelling and needs this done quietly is the attack, not an exception to the policy.
  • Training for the people who actually handle invoices, with real examples, repeated each quarter.

What DMARC p=reject does, and what it does not

Email authentication has three parts. SPF lists which servers may send for a domain. DKIM signs messages so that tampering and forgery can be detected. DMARC, defined in RFC 7489, ties them to the visible From address and tells receivers what to do with mail that fails: nothing (p=none), treat as suspicious (p=quarantine) or reject outright (p=reject). It also sends aggregate reports that show who is sending mail in your name. Our article on SPF, DKIM and DMARC explains the setup in more detail.

Moving to p=reject is worth doing. It stops an attacker from sending mail that claims to be from your exact domain, so it protects your customers, your vendors and your own staff from a forged message from your CEO's real address. Start at p=none, read the reports, fix every legitimate sender, move to quarantine and then to reject. Rushing to reject before you know your senders will block your own invoices.

What it does not do is the larger list. It does nothing against a lookalike domain, such as one that swaps a letter or adds a word, because the attacker owns that domain and can pass authentication on it. It does nothing against a real, compromised mailbox at your vendor, which will pass every check. It does nothing against a display name that says the CFO while the address is a free webmail account. And it does not help if your vendors have not set up authentication at all. That is why the process controls above do the real work, and DMARC is a useful layer beside them.

Layers that help with the rest: warning banners on mail from outside the organization, alerts on newly registered lookalike domains, mailbox-rule alerts and multi-factor authentication to cut account takeover, and a mail filter that checks sender history. Our article on the first 24 hours of a Microsoft 365 business email compromise covers response.

If a payment has gone out

Minutes matter. Call your bank immediately and ask for a wire recall or a fraud hold, and give the account details. File a report with the FBI Internet Crime Complaint Center at ic3.gov, because for qualifying international wires the FBI can work with the Treasury's Financial Crimes Enforcement Network and foreign banks to freeze funds, and that is far more likely to succeed within the first few days. Preserve the original emails with full headers, tell your cyber-insurance carrier and keep a log of the timeline. Then find out how the request got through. Often the real compromise is a vendor's mailbox or one of your own.

If you want the payment process reviewed, the email authentication set up safely or a tabletop exercise for the finance team, start with our Cybersecurity service. The Email security and archiving page covers the mail platform itself.

Sources

This article is general information, not legal or banking advice. Recall and recovery options depend on your bank and on how quickly you act. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity