Introduction
An invoice arrives in a conversation your finance team recognizes. The supplier's name is correct. The amount matches an open purchase order. The message is professional, and the explanation for changing banks sounds reasonable. Nothing about it requires the recipient to click a suspicious link.
This is where advice to look for bad grammar reaches its limit. Business email compromise, or BEC, can exploit real business context and legitimate accounts. The FBI describes attackers accessing existing billing conversations and timing fraudulent requests around them. A familiar thread is useful context, but it is not proof that the payment instructions are authentic. FBI: Business Email Compromise (opens in a new tab)
The leadership question is practical: can a convincing message change where your money goes? The following recommendations describe a stronger payment workflow. They are general guidance to adapt to your organization, not a list of features automatically included in a service agreement.
Make verification routine, even when the email looks right
Employees should still inspect sender addresses, notice unusual urgency, and report suspicious messages. Those habits help. They cannot carry the entire burden of payment security.
Consider an illustrative scenario: a genuine supplier mailbox is compromised shortly before a scheduled payment. A fraudulent bank-change request arrives from that account, using the existing subject line and invoice details. Replying to ask whether the change is real could simply reach the attacker again.
Build a process that does not depend on an employee deciding that a message looks suspicious. Our recommended trigger is the transaction: a new payee, changed bank details, a new payment method, an unusual urgent transfer, or an exception to established purchasing rules. Any of those should start a defined verification process.
Apply that process to executives as well as suppliers. An instruction apparently coming from the CEO should not create an undocumented exception. Leadership makes the control credible by accepting the same checks everyone else follows.
Call a number you already trust
The FBI recommends verifying payment changes through a known telephone number, rather than a number supplied in the request. It also recommends secondary approval of changes to vendor payment destinations. FBI payment-verification guidance (opens in a new tab)
A workable implementation is a controlled vendor record containing a previously validated contact and callback number. Staff initiate an outbound call using that record. They do not use the signature, attachment, or replacement contact details in the change request as their only source of truth.
During the call, verify the specific transaction and proposed change. “Did you send us an email?” is weaker than confirming the relevant invoice, intended recipient, and account-change details through an authorized contact. Follow your organization's privacy procedures when handling banking information.
If the trusted contact cannot be reached, hold the change and escalate through the documented path. An inbound call claiming to solve the problem should not automatically satisfy the callback requirement. Nor should a familiar-sounding voice alone be treated as identity verification.
For a new vendor without an established contact, use a separate onboarding process to validate the organization and the person authorized to supply payment details. Do not quietly turn an unverified new contact into a trusted one because a deadline is approaching.
Give the second approver something meaningful to check
Two people clicking “approve” on the same email is not a strong separation of duties. The second approver needs evidence of independent verification and visibility into what changed.
A practical record could include:
- The invoice or business reason for the payment.
- The original and proposed payment destination, handled securely.
- The source of the callback number and the authorized contact reached.
- Who completed verification and when.
- Who approved the change and who can release the payment.
- Any exception, its justification, and the person accountable for it.
Configure finance systems so one person cannot casually create a payee, change its bank details, and release the payment without the required review. Where staffing makes full separation difficult, document a compensating review with an owner who can actually stop the transaction.
Also protect the vendor master record itself. Restrict who can edit it, preserve change history, and review unusual changes. Otherwise, a later callback could use a number that was silently replaced earlier.
Use identity alerts as another layer, not payment authorization
Unusual sign-in alerts can help IT investigate account misuse. They do not establish that a particular invoice is legitimate. Microsoft documents that its unfamiliar-sign-in detection evaluates factors such as device, location, and prior behavior, and that newly created users have a learning period. Availability also depends on licensing. Microsoft Entra risk detections (opens in a new tab)
The practical implication is simple: an absence of alerts should never waive finance verification. Your organization may also have no visibility into a supplier's identity system.
Ask IT who receives identity alerts, who investigates them, and what happens outside business hours. Confirm that multifactor authentication and access policies are actually applied to the intended users. Review privileged accounts and the ability to change email forwarding or other account settings. These measures support the payment process; they do not replace it.
Microsoft's account-compromise guidance identifies suspicious inbox rules, external forwarding, and altered account details as investigation clues. Its response steps extend beyond changing a password to reviewing sessions, authentication methods, and application access. Suspected compromise deserves a coordinated technical response. Microsoft: Respond to a compromised email account (opens in a new tab)
A shared code is optional, and its limits matter
Some organizations add a prearranged code to sensitive approvals. Our recommendation is to treat it only as a supplementary check within a documented process.
A code stored in the same mailbox as the payment discussion may be exposed during the same compromise. A reused code can be copied or passed along. A requester who knows the code has not necessarily demonstrated authority to change a vendor's banking instructions.
If you choose this measure, decide how the code is established, protected, changed, and revoked. Never ask staff to disclose account passwords, authentication tokens, or bank one-time passcodes as payment verification. Keep independent callbacks, transaction-specific checks, and approval controls in place.
If money has already been sent, escalate immediately
Contact the originating bank's fraud team immediately through a verified channel. Ask about recalling or reversing the transfer and the steps required to contact the receiving institution. File a detailed complaint with the FBI's Internet Crime Complaint Center. Speed can matter, but recovery is not guaranteed. IC3: What to do after BEC (opens in a new tab)
In parallel, activate your internal incident process. Recommended actions include:
- Stop related pending payments while finance determines their legitimacy.
- Preserve original messages, attachments, payment records, and verification notes.
- Notify the incident lead and involve qualified IT or incident responders.
- Contact the legitimate supplier through independently verified details.
- Coordinate counsel and insurance notification under the applicable arrangements.
- Record decisions and timestamps without guessing at the full scope.
Do not wait for a complete technical investigation before calling the bank. Equally, do not assume recovering a payment resolves a compromised mailbox. Finance recovery and technical containment are connected workstreams with different owners.
Five questions for your next leadership meeting
- Can a supplier's bank details be changed solely through email?
- Where do staff obtain trusted callback numbers, and who can change those records?
- What evidence does the second approver see before releasing money?
- Can an employee pause an urgent executive request without being penalized?
- Have we rehearsed a fraudulent payment already in flight, including the bank contact?
A short walkthrough using a fictional invoice can expose more practical gaps than asking whether everyone completed awareness training. Include the backup approver and the person covering vacation absences.
Make the process sustainable
BreachReady is DFI's annual, DFI-led readiness service, designed to take on the heavy lifting of making real resilience easier to maintain. The useful starting point is a process your people can follow under pressure, with clear ownership and realistic maintenance.
Client finance and IT teams still participate: they provide context, validate existing workflows, approve changes, and complete responsibilities agreed in the engagement. An initial 30–60-day target is a planning goal, not a guaranteed completion date; access, scope, and dependencies affect timing. Ongoing maintenance matters as vendors, staff, and systems change.
Confirm the exact reviews, exercises, implementation responsibilities, and follow-up included in your BreachReady scope. The goal is to make trustworthy payment decisions routine, so a well-written email cannot become the sole authority for moving money.
