Supplier Risk Watch
Supplier Impersonation / Payment Diversion·United States·

The Invoice Was Real. The Supplier Was Real. One Bank-Account Change Redirected US$1.1 Million.

A New Jersey healthcare provider sent four ACH payments worth about US$1.1 million to a fraudster's account after emails posing as its safety-equipment supplier asked it to change bank details. The recipient has now pleaded guilty to money laundering conspiracy.

Source: U.S. Department of Justice, Southern District of Ohio · 29 September 2026

Risk Snapshot

Loss

US$1.1m

Control Failure

Unverified Bank-Detail Change

Risk

Supplier Impersonation / Payment Diversion

Region

United States

What Happened?

According to court documents, employees at a New Jersey healthcare provider received emails in June 2020 that appeared to come from its contracted safety-equipment supplier. The messages instructed the organisation to send future payments to a new bank account.

That account was controlled by Benjamin O. Alexander through BOA Building Maintenance and Cleaning Services LLC. Believing the instructions came from its genuine supplier, the healthcare provider sent four ACH payments totalling approximately US$1.1 million.

Alexander has now pleaded guilty to conspiracy to commit money laundering, the U.S. Department of Justice announced on 29 September 2026.

Where Was the Supplier Risk?

The supplier was genuine and so was the payment obligation. The only fraudulent element was the destination account, delivered through an email that appeared to carry the supplier's existing credibility.

Many organisations verify invoices carefully but treat a bank-detail change as an administrative amendment to an already trusted supplier. That reverses the risk hierarchy: a changed bank account should effectively require re-verification of the supplier-payment relationship.

When email is compromised or spoofed, a fraudulent instruction inherits everything the real supplier has earned. Confirming the request through the same channel it arrived in confirms nothing.

What Went Wrong?

A bank-detail change received by email was accepted as a genuine instruction from a trusted supplier, without independent verification of the request.

The new destination account was not validated against the supplier's identity. The account belonged to an unrelated cleaning business, a mismatch that name and ownership checks would be expected to surface.

Nothing treated a change of payee account followed by repeated payments to it as an exception. Four ACH payments reached the fraudulent account before the diversion was addressed.

What Should Businesses Do?

  • Treat every bank-detail change as a re-verification event

    A new account should not become trusted supplier master data because an email asked for it. Hold the change until the account and the supplier relationship have been independently re-verified.

  • Validate the destination account, not just the request

    Check that the new account exists and that its holder matches the supplier's verified legal entity. An account in the name of an unrelated business is a clear stop signal.

  • Verify the person authorising the change out of band

    Confirm the change with a known, previously verified supplier contact through a channel that did not originate the request, never through contact details supplied in the same email.

  • Flag first payments to changed accounts and keep a permanent audit trail

    Route payments to recently changed bank details through exception review, and record who requested, verified and approved each change so it can be reviewed independently later.

The ArayaPRO Response

How ArayaPRO Helps

This is exactly the type of supplier risk ArayaPRO is built to control.

Explore ArayaPRO

Further Reading

Supplier Risk Watch

Stay ahead of supplier risk.

Practical intelligence on emerging supplier threats, real-world incidents and the controls that reduce your exposure.

Supplier-risk intelligence delivered to your inbox. No noise. Submitting this form subscribes you to Supplier Risk Watch emails — see our Privacy Policy.