What Happened?
A Nigerian national was sentenced to eight years in U.S. federal prison after being convicted over a business email compromise (BEC) scheme that targeted two charitable organisations, the U.S. Department of Justice announced on 28 August 2026.
According to the DOJ, the offender registered spoofed domains designed to mimic legitimate organisations, obtained unauthorised access to employee email accounts, and used those compromised accounts to send — and then falsely confirm — fraudulent payment requests.
More than US$7.5 million was ultimately sent to bank accounts that did not belong to the intended recipients, with the fraudulent instructions corroborated from what appeared to be a second, independent email account.
Where Was the Supplier Risk?
The vulnerability wasn't a weak password or an obviously fake email — it was reliance on the same communication channel to both request and confirm a payment. Once that channel is compromised, corroboration from a second account offers no real assurance.
A message can carry every visible signal of legitimacy — a spoofed domain that closely matches the real one, a natural-reading email thread, and a second account confirming the details — while still directing funds to an account the recipient never controlled.
This case shows a structural gap present across BEC and payment-diversion fraud generally: verification is only meaningful when it happens through a channel the requester cannot also control.
What Went Wrong?
The control failure was treating email-based confirmation as sufficient assurance for a high-value payment — even when that confirmation appeared to come from a second, independent account.
Spoofed domains and compromised mailboxes are built specifically to survive a visual check: they look right, sit inside a plausible conversation, and can even 'confirm themselves' when a criminal controls more than one account in the chain.
The absence of an independent, out-of-band verification step — one that doesn't rely on the same email environment that delivered the request — is what allowed more than $7.5 million to reach the wrong destination before the fraud was detected.
What Should Businesses Do?
Never confirm a payment through the channel that requested it
A reply to the same thread, or a second email account that appears to corroborate the request, verifies nothing if the underlying email environment has been compromised. Confirmation must come from an independent channel.
Independently validate bank account details before releasing a payment
Don't treat a bank-detail change or first-time payment instruction as trustworthy because it looks right. Validate the destination account independently of the channel that supplied it, every time.
Treat a 'confirming' second email as no safer than the first
This scheme worked precisely because a second compromised account made the request look corroborated. Two email accounts agreeing is not independent verification if both sit inside the same compromised environment.
Build mandatory, logged verification into high-value payment changes
Don't leave detection to an individual employee's instinct. A required, auditable verification step for payment-destination changes closes the gap that email-based trust leaves open.
The ArayaPRO Response
How ArayaPRO Helps
This is exactly the type of supplier risk ArayaPRO is built to control.
Further Reading