Invoice fraud exploits trusted payment workflows, not just bad emails

At a glance

What this is: Invoice fraud is a payment diversion pattern that uses real supplier context, believable correspondence, and a changed destination account to trick accounts payable teams.

Why it matters: It matters to IAM and finance governance because the failure point is identity and approval assurance around vendor changes, where trusted communications can no longer be treated as proof of authority.

By the numbers:

• The FBI’s 2025 Internet Crime Report recorded more than $3 billion in reported business email compromise losses.

Context

Invoice fraud is a control failure in a business process, not just a deceptive email. The attacker does not need to alter the invoice amount if they can redirect the payment destination while preserving the familiar transaction story.

In financial workflows, the weak point is often the assumption that a legitimate thread proves legitimate authority. That matters to identity governance because payment changes are an approval problem, an impersonation problem, and in some cases an access problem at the same time.

Key questions

Q: How should teams verify a supplier bank-detail change before releasing payment?

A: Use a pre-established, independently verified contact route and require a separate reviewer to confirm the request, the receiving account, and the payments affected. Do not rely on the email thread, the invoice PDF, or the phone number supplied in the message. The key control is out-of-band validation before any vendor record changes or payment release.

Q: Why does invoice fraud remain effective even when the email looks legitimate?

A: Because legitimacy in the thread does not prove legitimacy in the authority. Attackers can use a compromised mailbox, copied correspondence, or a lookalike domain to preserve the story while changing the bank account. The risk comes from trusting conversation continuity as evidence of authorisation, which it is not.

Q: What are the signs that a payment-related message is fraudulent?

A: Common warning signs include unsolicited contact, pressure to act quickly, requests for personal or banking information, and messages that arrive through channels used by attackers rather than the government. Email requests for payment information are especially suspect in this context. If the message tries to move you away from normal verification steps, treat it as a likely fraud attempt.

Q: What should finance teams do immediately if a fraudulent payment has already been sent?

A: Contact the originating bank at once, request recall or recovery action, stop any related transfers, preserve the original messages and transaction records, and verify the legitimate account through an independent contact. Then review how the request bypassed the approval process so the same path cannot be reused.

Technical breakdown

How reply-chain hijacking preserves trust while changing the destination

Reply-chain hijacking works because the attacker uses the existing conversation history to inherit legitimacy. The subject line, quoted messages, invoice references, and familiar tone all reduce suspicion, but none of them authenticate the request to change bank details. If the mailbox is compromised, the attacker can reply from the real address; if not, they can copy or fabricate the thread. The security failure is treating conversational continuity as proof of authorization. In practice, this is an identity problem wrapped inside a payment process, because the conversation looks right even when the authority behind it is false.

Practical implication: Separate message history from authorization and require an out-of-band trust check before any vendor record change.

Why impersonating domains and cloned portals still work

Lookalike domains succeed because humans key off familiar names, signatures, and urgent wording, while domains themselves can differ by a single character or an added word. A cloned portal or contact page extends that deception beyond email and gives the attacker a second channel for reinforcement. This is a broader external impersonation pattern, where the phishing surface includes email, web, and support contact infrastructure. The technical issue is not merely spoofing, but the attacker’s ability to create a consistent identity story across multiple assets that the victim can verify only superficially.

Practical implication: Check ownership and control of the sender, portal, and support contact before accepting any banking change.

Why generative AI lowers the cost of believable payment fraud

Generative AI does not create the fraud problem, but it reduces the effort required to make it look routine. Attackers can reproduce vendor tone, remove grammar mistakes, translate messages, and imitate common invoice language at scale. That means fluency is no longer a meaningful proxy for legitimacy. The real technical question is whether the message can be tied to a trusted identity and a verified approval path. In other words, content quality has become cheap, while authority verification remains the scarce control.

Practical implication: Treat polished wording as irrelevant until the payment change is verified through a trusted channel.

Threat narrative

Attacker objective: Divert payment to an unauthorized account while preserving the appearance of a legitimate supplier transaction.

1. Entry occurs through a compromised vendor mailbox, an impersonating domain, or a hijacked reply chain that reuses real correspondence.
2. Credential or trust access is then used to request a banking change that fits the invoice narrative and appears operationally normal.
3. Escalation happens when accounts payable accepts the new destination without an independent verification step, allowing the attacker to redirect funds.
4. Impact is a fraudulent payment to an attacker-controlled account, often before the deception is detected.

NHI Mgmt Group analysis

Invoice fraud is an identity assurance failure inside finance operations. The attacker does not need to break the invoice itself if they can break the trust relationship around payment instructions. That makes this a governance problem spanning email identity, vendor records, and payment approval, not a narrow finance issue. Teams that treat bank-detail changes as ordinary administrative updates are leaving the authority check outside the control boundary.

Reply-chain continuity has become a false signal of legitimacy. A real thread, a known invoice number, and an existing purchase order can all be true while the payment destination is false. This is why conversational context cannot substitute for verified authority, especially where mailbox compromise and copied correspondence are both viable entry paths. The control model has to assume that the story can be real even when the sender is not.

External impersonation now spans email, web, and support infrastructure. The article’s discussion of fake domains and cloned portals shows that payment fraud is no longer just inbox abuse; it is an ecosystem of lookalike assets used to reinforce the same deception. That is why finance teams need to investigate the supporting infrastructure, not only the message content. MITRE ATT&CK remains useful for mapping how those tactics connect across initial access, credential abuse, and impersonation.

A trusted-payment workflow must be built for exception handling, not just steady-state processing. Quarter-end pressure, supplier urgency, and account-closure stories all create predictable exceptions that attackers exploit. The problem is not that staff are careless, but that many processes are not designed to hold a change while independent verification occurs. Practitioners should treat banking changes as controlled events with evidence, ownership, and auditability, not as edits to be completed inside the thread.

Invoice fraud and account takeover converge when the vendor record becomes the control point. Once the payment destination is changed, downstream approvals may simply validate the attacker’s edited record. That means the decisive governance boundary sits earlier than many teams assume. Finance and identity teams should align on who can request, verify, and approve a bank-detail update before any payment release occurs.

From our research library:

• Nearly 60% of companies reported that fraud losses were still increasing in 2025.

What this signals

Payment approval is the real control plane. Invoice fraud succeeds when the workflow treats a vendor message as sufficient authority to change destination details. Organisations should move verification to the point where the payment record is edited, because that is where the attacker’s leverage begins and where the strongest evidence can still be gathered.

External impersonation now spans the entire vendor relationship. A bad domain, a cloned portal, and a copied thread are often part of the same campaign rather than separate problems. That means finance security teams need to correlate email, web, and contact signals before they release funds, not after the payment has already left.

Identity assurance for suppliers should be treated like a standing control, not a one-time onboarding task. The article makes clear that trusted relationships can be abused long after the original vendor setup is complete. For practitioners, the programme signal is simple: if bank changes are not independently verified every time, the process is still vulnerable.

For practitioners

• Verify payment changes through an independent channel Confirm banking details using a trusted vendor contact path established before the request, not the number or portal in the suspicious message.
• Require separate approval for vendor-record updates Make one person receive and verify the change while a different authorised reviewer approves the record update and any payment release.
• Hold payments when destination details change Pause the vendor record update and any related transfer until the account owner, amount, and effective date are confirmed outside the email thread.
• Investigate the supporting impersonation infrastructure Review sender domains, reply-to addresses, cloned portals, and contact numbers so the team can spot coordinated fraud rather than a single suspicious email.
• Test staff on realistic diversion scenarios Use simulations that include a genuine-looking thread, a corrected invoice, and a payment-detail change so staff practise the right response under pressure.

Key takeaways

• Invoice fraud exploits trust in a real supplier relationship, so the critical failure is often the approval process rather than the invoice itself.
• The article ties this pattern to more than $3 billion in reported business email compromise losses in the FBI’s 2025 Internet Crime Report.
• Independent verification of bank changes, separate approval, and preservation of evidence are the controls most likely to stop or limit the diversion.

Related NHI Mgmt Group resources: Email Identity and BEC Guide · Fraud Prevention Platform Buyer's Guide · Account Takeover Prevention Guide · MITRE ATT&CK Guide for Defenders

Key terms

• Invoice Fraud: Invoice fraud is a business email abuse pattern where attackers redirect payments, alter supplier details, or request exceptions using convincing impersonation. The technical weakness is not only message delivery, but the absence of independent validation before financial action is approved.
• Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.
• Reply-Chain Hijacking: Reply-chain hijacking is the abuse of an existing email conversation to make a fraudulent request look legitimate. The attacker leverages quoted history, familiar participants, and ongoing context, but the authority behind the message no longer belongs to the genuine sender.
• Out-Of-Band Verification: A confirmation step that uses a different channel or method than the original request. It reduces the chance that a single spoofed email, voice call, or video session can authorize privileged activity or financial transfer.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programmes they already run.