On October 29, 2018, a boat builder wired $3,316,730 to a bank account in Pennsylvania to pay for ferry engines. The engines came from a supplier it already did business with. By the account federal prosecutors later gave, the invoice was never the problem. The problem was the account number, and an email from the supplier’s billing executive explaining why it had changed.
Recently I heard someone from a large construction company describe nearly the same thing happening to them. One of their partners, a much smaller firm, had been compromised. Then the progress invoices started arriving: billings for services, from the partner, payable to a different address and a different bank account. Why would anyone bother breaking into the small company? I don’t think the small company was ever the target. It was the door into the big company’s accounts payable.
What happened
According to the U.S. Attorney’s Office for the Western District of Washington, the scheme began with one malicious link sent to an employee at the engine-building company. That link gave the conspirators access to the company’s email system. They read through it, including the messages that carried invoices. Then they wrote to the boat builder as the engine company’s billing executive with instructions to wire the payment to a new account, because (the email said) the usual account was under audit. The new account belonged to a fake company, opened at a Pennsylvania bank specifically to receive this money.
The boat builder paid. A co-conspirator in Pennsylvania quickly forwarded $3,074,500 to accounts controlled by others in the scheme, including Leslie Redd III of Inglewood, California. Redd kept $857,350. He sent more than $2 million on to co-conspirators in China, people prosecutors said he couldn’t even name. Investigators seized $420,817 from his accounts.
Redd pleaded guilty to conspiracy to commit wire fraud and wire fraud. On April 26, 2024, U.S. District Judge Ricardo S. Martinez sentenced him to 16 months in prison and three years of supervised release, and ordered $2,802,368.24 in restitution, which the release describes as the outstanding loss. At sentencing the judge noted that the crime had delayed and cut pay for employees at the victim businesses and threatened their viability. The release calls both companies victims. It does not say which one ended up holding the loss.
The arithmetic leaves loose ends. Take the $2,802,368.24 still outstanding away from the $3,316,730 wired and $514,361.76 came back from somewhere; the seizure from Redd’s accounts covers $420,817 of it. The release doesn’t say where the remaining $93,544.76 came from. Nor does it account for the $242,230 gap between what landed in Pennsylvania and what was forwarded out.
Why the gap existed
Most of the defenses companies buy against email fraud ask one question: did this message really come from the sender it claims? In a compromise like this one, the honest answer is yes. The email came out of the supplier’s own mail system, signed as a real employee, about an invoice for real engines. Every check aimed at impostors passes, because there is no impostor in the technical sense. Just a stranger sitting in a legitimate mailbox.
The question that mattered was different. Did this supplier actually change its bank? Email can’t answer that, because email is the channel that was compromised. The audit story did its job by making the change sound routine and faintly bureaucratic (who argues with an audit?).
Whether anyone at the boat builder updated a vendor master record with the new account, or keyed it straight into a one-off wire, the release doesn’t say. Both paths are gaps. In the first, a bank change arrived in the same thread as the invoice it was meant to pay and got processed as clerical housekeeping. In the second, a $3.3 million payment left the building without touching the vendor master at all.
Why the small company
The construction story makes the economics plain. A large contractor usually has a security team and auditors who ask about it. Its subcontractors are another matter. Plenty of small firms keep the books with one person and have never once looked at the sign-in history on their email accounts. The attacker doesn’t need to beat the large company’s controls. They need a seat inside a mailbox the large company already trusts.
And from that seat the job is easy, because progress billing is predictable. The invoices arrive on a schedule, for amounts the project manager is expecting, referencing jobs everyone knows are underway. Nothing has to be forged. The attacker waits for the next invoice the customer is already planning to pay and changes one line on it.
The FBI’s 2025 Internet Crime Report counted 24,768 business email compromise complaints, with about $3.05 billion in reported losses. Those are only the incidents someone reported.
Controls that would have caught it
Bank changes are their own transaction. A change to supplier remittance details runs through its own approval workflow in the ERP, separate from invoice processing, and nobody who enters invoices can edit bank details. A bank change that shows up inside an invoice email gets routed out of AP and into that workflow, where it starts from zero.
Callback to the number already on file. Someone phones the supplier using a number from the vendor master or a signed contract. Never the number in the email that asked for the change. If the request is genuine, it costs one short call; if it isn’t, that call is the only step in the process the attacker can’t reach.
A hold on new bank details. New remittance details sit inactive for a set number of days, and the first payment to them needs a second approver who wasn’t the person who verified the change.
No payments outside the vendor master. The payment run pays only to bank accounts stored on the vendor record. A wire to an account that isn’t there should be impossible to create, not merely discouraged by policy.
A remit-to mismatch stops the invoice. When the bank details printed on an invoice differ from what the vendor master holds, the invoice goes on hold and a person looks at it. A warning line in a log that nobody reads doesn’t count.
An agent watching the vendor master
Most of the warning signs in a case like this live in ERP data before the money moves. A bank detail change, then a large invoice from the same supplier a few days later. A first-ever payment to an account nobody had paid before. The trouble with signals like that is that they sit in a change log or a report, and a report only matters if someone remembers to run it and then actually reads it on the day it counts.
An AI agent changes the timing. Instead of waiting for month-end review, it wakes up on the event itself: every edit to vendor bank details, every payment proposal before it is released. It can compare the payment against that supplier’s history and check how recently the destination account was added. It can also notice when the person who approved the bank change is the same person who handles that supplier’s invoices. When the combination looks wrong, it holds the payment and tells a person to make the callback.
What the agent should not do is approve anything. Its job is to notice and to stop the line, and to explain in plain language why it stopped it. A human still picks up the phone. Expect some false positives early on, because legitimate suppliers do change banks (small firms get acquired, or refinance with a new lender). Someone has to review what it holds for a while and adjust the thresholds.
The laptop at the other company
This whole thing started on one employee’s machine at the supplier, with one link. The release doesn’t say whether the link harvested a password or planted something, and the difference matters to which defense would have worked. Phishing-resistant multifactor authentication makes a stolen password alone useless against the mailbox. Endpoint detection and response watches the machine itself for the behavior of whatever the link installed. Neither one is exotic anymore.
Intrusion defense on the mail system matters just as much, because attackers who get in usually change settings to hide themselves. In a 2018 Sixth Circuit case involving two car dealerships, the hacker inside the seller’s sales manager’s account filtered out the buyer’s messages so nobody at the dealership would see the conversation go sideways. A new inbox rule that forwards or hides mail from a specific customer is exactly the kind of event a monitored mail environment flags, and exactly the kind nobody notices in an unmonitored one. Same with a sign-in from a country the employee has never visited.
In the Redd case, a gap on the supplier’s side sent the customer’s money to Pennsylvania. So the supplier’s endpoint protection belongs in the conversation with partners: minimum requirements in the subcontract or the vendor onboarding packet, multifactor authentication on email as the floor. Some partners will meet it. Some will sign it and not. The ERP controls above exist for that second group.
It also runs in the other direction. If your own AP or billing mailbox gets compromised, your customers start receiving your invoices with someone else’s bank details on them.
Who pays
Back to those car dealerships. Beau Townsend Ford agreed to sell 20 Ford Explorers to Don Hinds Ford for about $736,225, and the wire instructions Don Hinds received came from a hacker sitting in the Beau Townsend sales manager’s email. The district court ruled that Don Hinds had to pay again. The Sixth Circuit reversed, saying a factfinder should decide whether either dealership’s failure to exercise ordinary care contributed to the hacker’s success and split the loss by comparative fault. The parties settled.
So being the company whose mailbox was compromised is no defense. Neither is being the company that paid in good faith. A court may look at both, and at what each could reasonably have checked. That is a bad time to find out the vendor master let a bank change ride in on an invoice email. (I’m not a lawyer, and none of this is legal advice.)
An AI prompt for this one
OBJECTIVE
Review every vendor bank detail change and every pending vendor payment
for signs of vendor email compromise before the payment is released.
INPUTS
- Vendor master change log (bank account, routing, remit-to address),
with who requested, who approved, and the date of each change
- Pending payment proposals and payment journals
- Vendor payment history for the past 24 months
- Open vendor invoices, including remit-to details printed on the invoice
DETECTION RULES
1. Flag any payment to bank details added or changed in the last 30 days.
2. Flag any payment whose amount exceeds that vendor's largest prior
payment, or lands within 10 days of a bank detail change.
3. Flag any invoice whose printed remit-to bank details differ from the
vendor master.
4. Flag any bank change approved by a user who also enters or approves
invoices for the same vendor.
5. Flag any payment to an account not present on the vendor record.
6. Flag any bank change with no recorded callback verification.
LEGITIMATE EXPLANATIONS TO TEST
- Documented acquisition, merger, or refinancing of the vendor
- Callback verification logged with a phone number from the vendor
master or contract, not from the change request
REQUIRED OUTPUT
For each flag: vendor, invoice, amount, rule triggered, the specific
evidence, and a recommended action. Recommended actions are limited to
HOLD PAYMENT and REQUEST CALLBACK. Never approve or release a payment.
Source note
This article draws on public records listed below. Details of the Redd case come from the U.S. Attorney’s Office press release, which summarizes the plea agreement and sentencing filings; where that release leaves a figure unexplained, the article says so rather than guessing. The construction company story was told to me secondhand, and I have repeated only what I was told.
References
My book, Gamifying the Enterprise: Game Mechanics for Continuous Proficiency, is on Amazon.
All my books are on my Amazon author page.
The AD&D365 configuration guides are at adnd365.com/start.
Connect with me on LinkedIn.
