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

The risky moment can look like an accounts payable clerk handling a normal payment run.

A familiar supplier emails about an invoice. The message is clean, polite, and specific. It references the right project, uses the supplier's logo, includes a PDF that looks like the supplier's usual format, and explains that the supplier has moved to a new bank account.

A second email appears to come from the controller and references the same supplier thread: "Can you get this updated before Friday's run? We are trying to avoid late fees on this one."

Nothing looks strange. That is the problem.

Old phishing training told staff to look for broken language, odd formatting, generic greetings, and clumsy urgency. AI has made those signals much weaker. A fraud email can now be well written, role-specific, and timed to a real business process.

The reliable signal is the action being requested.

If a message asks for money movement, banking changes, payroll routing, or credential reset, it needs verification through a known channel before anyone acts on it.

What the risk is

AI-amplified phishing is text-based social engineering made faster, cleaner, and more contextual with AI tools. The target is still a person, but the message quality has changed.

Attackers used to spend time writing each convincing fraud message. They had to research the company, understand the roles, imitate the sender, and produce language that looked normal. That effort limited how many targeted attacks they could run.

AI changes the economics. An attacker can scrape public information from websites, LinkedIn, job postings, procurement pages, newsletters, and leaked email threads, then use AI to produce messages that fit the target's role and business rhythm.

The attack may arrive by email, Teams, Slack, WhatsApp, SMS, a vendor portal message, or a QR code on a convincing invoice page. Email is still the main path for many SMBs, but staff now handle business requests across several channels where verification habits are weaker.

Common examples include:

• A vendor banking-change request that matches the vendor's tone and invoice format.
• A payroll routing change that appears to come from an employee.
• A controller or owner asking for a payment before a deadline.
• A QR-code invoice that routes staff to a convincing payment or credential page.
• A lookalike domain that differs from the real one by one character.
• A landing page that copies the bank, Microsoft 365, payroll provider, or vendor portal branding.
• A chat message that picks up context from a real project and asks for a credential reset or payment step.

Staff should identify the requested action before judging whether the message looks suspicious.

Voice and video impersonation covers voice and video impersonation. This article stays with text-based fraud: email, chat, SMS, portals, QR pages, invoices, and landing pages. Prompt injection covered attackers manipulating AI systems; this article covers attackers using AI to manipulate people.

How it happens in a normal SMB

A small Alberta construction company pays a regional materials supplier every month. The supplier sends invoices by email, and accounts payable usually pays them during the Friday payment run. The controller reviews exceptions, but routine invoices are handled by an AP coordinator who knows the vendors well.

An attacker has collected enough public context to sound credible. The company website lists recent projects. LinkedIn shows the controller, owner, and AP coordinator. A supplier announcement from last year includes the supplier's logo and billing contact. The attacker also finds an old purchase order format in a public bid package.

Using AI, the attacker drafts a supplier email that fits the situation:

Hi Sarah, we are updating payment details for May invoices as part of our banking transition. Please use the attached remittance form for Friday's run. The outstanding invoices for the Riverbend and West Hill jobs should be paid to the new account below.

The wording is clean. The invoice numbers look plausible. The attached PDF has the supplier's logo, footer, and line-item style. The sender domain is one character off from the real supplier domain.

The AP coordinator hesitates because banking changes are unusual. Then a second message arrives that appears to be from the controller, also written cleanly:

This looks like the same supplier we discussed last week. Please update the remittance info before the run so we do not hold up the jobs.

On the coordinator's phone, the message shows the controller's name, while the actual sender address is a personal email account. The language fits the kind of internal nudge that happens during a busy payment week.

The AP coordinator updates the banking details in the accounting system and includes the supplier in Friday's payment run. The payment leaves the company's account.

Only then does the company see the pattern: a lookalike supplier domain, a convincing PDF, a fake internal nudge, and a banking change that was never confirmed through a known phone number.

The failure path

The failure path looks like this:

Case file Sequence 06 · Payment fraud

1. 01

   An attacker gathers public business context: names, roles, vendors, projects, domains, invoice formats, or recent activity.

2. 02

   AI helps produce clean, specific messages that match the target's role and normal business process.

3. 03

   The message asks for a high-risk action: banking change, payment instruction, payroll routing, credential reset, or urgent transfer.

4. 04

   The staff member evaluates the message by appearance, sender name, tone, and context.

5. 05

   The message looks normal enough to proceed.

6. 06

   The action is taken without out-of-band verification through a known channel.

7. 07

   Money, credentials, or account access goes to the attacker.

8. 08

   The business discovers the fraud when the real vendor, employee, bank, payroll provider, or customer asks why the expected action did not happen.

Appearance cannot carry the decision. The message may look right because AI helped make it look right. The request type should drive the control.

Business consequence

The first consequence is usually direct financial loss.

In the construction company, the payment went to an attacker. The supplier still expects to be paid. The business may have to pay the real invoice again, argue with the bank, preserve evidence, call the insurer, and explain to the supplier why the money was redirected.

Recovery is uncertain. A bank may be able to attempt a recall, with success depending on timing and where the funds moved. Insurance may help, although claims can become complicated when the business voluntarily initiated the transfer under deception. Policy wording matters, and the business will be asked what verification controls were in place.

Other consequences follow quickly:

• Payroll deposits may be redirected to an attacker, leaving an employee unpaid.
• Vendor relationships may be damaged when payment instructions are changed without confirmation.
• Customers may be affected if the fraud involved customer banking details or payment instructions.
• Staff may lose confidence after being blamed for a message that looked normal.
• The business may have to review recent banking changes, payment runs, credential resets, and vendor portal activity.
• A compromised mailbox or account may create a second incident response track.

Credential resets and account recovery requests belong in the same control family as payment requests because they also transfer control. A mailbox, payroll account, vendor portal, or banking login can become the path to the next payment fraud.

The staff member is rarely the main problem. If the business teaches people to judge fraud by whether the message looks sloppy, AI-amplified fraud will beat that training. The control has to attach to the requested action.

Controls that interrupt the failure path

The first control is out-of-band verification for high-risk requests.

For any request involving money movement, banking-detail changes, payroll routing, credential reset, vendor portal access, or payment instruction changes, staff must verify through a known channel before acting. The callback number should come from the vendor master record, contract, prior verified contact list, or another approved source. It should not come from the inbound message.

The verification process has to be normal, fast, and socially acceptable. If staff feel they are slowing the business down by calling a vendor, they will skip the call under pressure. Owners and managers need to make the pause expected.

The callback should be boring. "We received a request to change banking details. I am calling the number we already had on file to verify before we process it." That sentence prevents a large share of payment fraud.

Policy rule this creates