AI-amplified phishing and payment fraud: when the message looks normal

AI has changed the unit economics of phishing, both by lowering the cost of reconnaissance (LinkedIn scrape, website mining, public document review) and by generating clean role-specific messages at scale, which means a 30-person SMB now receives the same quality of message a Fortune 500 used to receive. The same economics drive both directions: vendor impersonation (a supplier email asking to update banking details) and internal impersonation (an email that appears to come from the owner or controller asking AP to process a payment). SMB per-incident impact is also higher than enterprise per-incident impact, because a single fraudulent vendor-banking change can be material to a small firm where the same loss might be a write-off at a larger one. The relevant question for an SMB is whether the requested action (money, banking, payroll, credentials) gets verified before staff acts on it, regardless of whether the message appears targeted.

Phishing training built around 'spot the typo, the clumsy urgency, or the generic greeting' no longer protects against AI-amplified messages, because AI removes those signals. Many simulation libraries built before AI-quality messaging are still in use, and the conventional 'spot the visible flaws' framing persists in training material that has not been refreshed. If the simulator itself still sends old-style messages with visible flaws, staff pass the simulation and still fail real attacks. The training that holds up focuses on the requested action (money movement, banking change, payroll routing, credential reset, account recovery) and the verify-out-of-band response, regardless of how clean the message looks.

Out-of-band verification means using a different channel than the one the request arrived on, with the verification channel established through an independent source. Phone callback to a number from the vendor master record, contract, or prior verified contact is the strongest version, because the phone network is independent of the email and chat identity, and walking to the person's desk is equally strong. Chat-based verification (Teams or Slack DM) works when the chat platform sits on a different identity domain than the request channel, and is weaker when both ride the same Microsoft 365 or Google Workspace tenant, because a compromised tenant can deliver both the email and the chat from the same attacker. The same principle applies to internal requests: when an email appears to come from the owner or controller, the verification is to reach that person on a phone number already known to be theirs.

The callback is standard practice in accounts payable, and most vendors expect it when banking details change. The call goes to the number already on file in the vendor master record, contract, or prior verified contact list, even when the request itself provides a 'new' number that looks legitimate. A normalized script removes the awkwardness by framing the call as routine procedure: 'We received a request to change banking details. I am calling the number we already had on file to verify before we process it.' Vendors who push back hard against a routine callback are themselves a useful signal that something is off.

The verified callback number gets into the vendor master record at onboarding, through a method independent of the same email or web channel the vendor first contacted the business on. For most SMBs, the practical options are an in-person or phone conversation initiated by the business to a number obtained from the vendor's own publicly listed contact (their website, a directory listing, or an industry association) with banking details confirmed on that call, a banking-details form attached to the signed contract with independent signature verification, or, for higher-value vendors, a third-party verification service. The same independence principle applies when a legitimate vendor genuinely changes their banking details: the new number is added to the master record only after a callback to the existing number on file confirms the change. A master record built from email replies and signature blocks alone provides no verification baseline, because the same attacker who can spoof an email can supply the 'verified' number that ends up on file.

The threshold logic applies to payments themselves: set a dollar amount above which two-person approval is required, calibrated to the business's normal payment sizes. Banking-detail changes, payroll-routing changes, credential resets, and account-recovery requests should be verified regardless of amount, because the change itself enables every future payment or access to that account. A vendor banking change of zero dollars today can redirect tens of thousands of dollars across the next year. The simplest operating rule is verification on every request that changes who gets paid, who can sign in, or who can recover an account, with the dollar threshold and two-person approval layered on top for payment runs.

Business email compromise is when the email genuinely comes from the vendor's real account because an attacker has taken over the vendor's mailbox, which means email authentication, lookalike-domain detection, and DMARC do not flag it. The verify-out-of-band rule still works in this case because the callback uses a phone number outside the compromised mailbox. This is why callbacks have to use a number from the vendor master record, contract, or prior verified contact; numbers shown in the email signature or invoice can be changed by the attacker. If the verified callback reaches the vendor and they confirm no banking change was requested, the business has both prevented the fraud and surfaced a compromise the vendor needs to address.

MFA stops basic password-stuffing attacks but does not stop AI-amplified phishing on its own. Much of the fraud does not require compromising the mailbox at all, because the attacker spoofs the sender or uses a lookalike domain from outside the business. When credential phishing is the goal, real-time adversary-in-the-middle kits proxy the legitimate login page and capture either the password and MFA code as the user types them, or the authenticated session token after a successful login, defeating code-based MFA in both cases. Phishing-resistant MFA (passkeys or security keys) is origin-bound, meaning it only authenticates to the legitimate domain so an attacker proxy receives nothing usable, which is what makes it the meaningful upgrade for high-value accounts: finance, payroll, banking, email administration, and executive accounts.

The verify-the-action rule applies regardless of channel. Email is still the most common path for AI-amplified text fraud, but SMS, WhatsApp, Teams, Slack, vendor portals, and QR codes are also being used, and SMS and QR codes in particular bypass email security filters. Internal channels deserve the same scrutiny as external ones, because a compromised Teams or Slack account messaging from inside the trust boundary is among the most dangerous channel-agnostic fraud vectors. Staff should treat any high-risk request the same way regardless of channel; voice and video channels face a distinct AI-impersonation risk covered in voice and video impersonation.

The first call after a fraudulent payment is to the bank, because recovery odds drop sharply with time and the bank's recall window is narrow. Ask specifically for a SWIFT MT103 recall (for wire transfers) or an ACH return request (for ACH payments), since front-line bank staff may need the specific procedure named. If the payment went through Wise, Stripe, Bill.com, or another payment platform, contact that platform's fraud team in parallel because the platform has its own freeze and recall procedures separate from the bank. Preserve the original message, payment record, sender details, headers, and any related communications, and review whether any mailbox or credential could have been compromised in the same incident. Notify IT or the policy owner, and hand decisions about insurance claims (which often depend on documented verification having been performed before payment), legal counsel, regulator reporting (in Canada, the Canadian Anti-Fraud Centre; in the US, the FBI's IC3 and the affected bank's fraud line), and client notification to the owner with appropriate advice.