The $545,598 Payment Change That Looked Like Routine Business

The $545,598 Payment Change That Looked Like Routine Business

The invoice was real. The contractor was real. The work had been completed, and the payment was expected.

Only the destination was false.

On March 13, 2026, the Town of Surfside Beach, South Carolina, issued a $545,598.30 ACH payment intended for Wildcat Contractors. The contractor did not receive it. The town later found fraudulent communications that redirected the money to an account controlled by criminals.

This is the kind of fraud that should worry every small business owner because the scheme did not need to invent an obligation. It entered a live payment process and changed one critical field: where the money should land.The Fraud Borrowed a Real Invoice

Payment-diversion schemes are most convincing when nearly everything in the request is true.

Surfside Beach genuinely owed the contractor money. Staff expected to process a payment. The amount related to actual work. Inside that normal workflow, a request involving ACH instructions could look administrative instead of dangerous.

The town’s independent digital-forensics review found that criminals used spoofed and typo-squatted domains, including surfsidesbeach.org, which added one letter to the town’s legitimate domain. The impersonation domain was created on March 9, four days before the payment was issued. Investigators found no evidence of unauthorized access to the town’s Microsoft 365 accounts.

That finding is a useful clue. A criminal does not always have to break into the payer’s mailbox. A near-match domain, copied details, and good timing may be enough to make a false request look like part of an existing conversation.

The investigation also found communications involving both legitimate and fraudulent Wildcat email domains. That mix can make a thread especially convincing. One genuine message establishes the relationship; a false message changes the money path.Four Clues That Deserved More Weight

The evidence points to four pressure points that small businesses should recognize.

A change in payment instructions. A switch in payment method or bank account is not routine clerical maintenance. It resets the risk and deserves a new verification.

A near-match email domain. An added letter can disappear on a crowded screen, especially when the display name still shows a familiar vendor or employee.

A new destination for a large payment. The invoice may be approved, but the account receiving the money is a separate decision. That decision needs its own evidence.

Verification that stays inside the same communication path. If the reply address, callback number, or supporting form comes from the email chain under suspicion, the criminal may control the confirmation loop.

The control can fail even when someone believes they checked. The real question is whether the check reached a person and record the requester could not manipulate.A Callback Is Only as Good as the Number

“Call to confirm” is sound advice only when the number was trusted before the change request arrived.

Do not use the number in the email, ACH form, invoice attachment, or signature block. Retrieve a known contact from the signed contract, approved vendor-master record, or a previously verified directory. Then ask specific questions:

  • Did your company request this change?
  • Who authorized the new instructions?
  • What payment method and account were previously approved?
  • Can a second known contact confirm the change?

Document who called, which number was used, who answered, what was confirmed, and when. For a significant change, require a second employee to approve both the vendor-record update and the payment release.Put a Break in the Payment Trail

Criminals want a straight line from inbox to bank. Your process needs deliberate breaks.

Restrict who can edit the vendor master file. Log changes and send an automatic alert when bank details, remittance addresses, contact names, or email domains are modified. Supporting paperwork matters, but a form or signature should never be treated as independent proof; both can be copied.

Create an exception queue for changes to payment method, bank account, email domain, or contact person. Hold the payment until independent verification is complete. For large transfers, add a cooling-off period or second approval.

Use the controls offered by your bank. Transaction limits, dual approval, immediate transfer alerts, and a prearranged fraud contact can shorten the response time when something goes wrong. Ask the bank now what information it will need for a recall. The middle of an incident is a poor time to learn the procedure.

Also protect the vendor side of the relationship. Agree in advance how payment changes will be communicated and verified. Tell vendors that your company will never accept new banking instructions based on email alone. Ask them to notify you quickly when an expected payment does not arrive.When the Money Has Already Moved

Speed becomes evidence preservation.

Contact the sending bank’s fraud department immediately and request a recall. Preserve the full email chain, headers, attachments, vendor records, approval logs, and bank confirmations. Notify the real vendor through a known number. Report the incident according to the company’s insurance, legal, and law-enforcement response plan, including the FBI’s Internet Crime Complaint Center when appropriate.

Do not spend the first hours debating whether the email was technically “hacked.” The loss can be real even when the company’s own mailbox was never accessed.The Case File Lesson

The extra letter in surfsidesbeach.org was small. The consequence was not.

Payment-diversion fraud succeeds by surrounding one false instruction with enough true details that the transaction feels familiar. The vendor, invoice, amount, and timing can all be right while the bank account is wrong.

That is why familiarity is not verification. When money instructions change, step outside the message, retrieve a contact you already trust, and prove the new destination before releasing the payment.