A familiar supplier can send a genuine message that is still insufficient authority to redirect a payment. The safe response is to hold the affected funds, verify the change through a route established independently of the request, approve the exact beneficiary version and check that version again at release.
The verified message
An invoice arrives from a supplier the company has paid for years. The goods were delivered. The amount matches the purchase order. Later that afternoon, a message arrives in the same email thread:
We have changed banks. Please use the attached account details for this invoice. Everything else remains unchanged.
An AI assistant extracts the new details, updates the payment draft and presents it for approval. The finance manager sees the familiar supplier, the correct amount and a green verification badge. They approve.
This is a hypothetical workflow, not a reported incident. It needs no spectacular model failure. The assistant can read every document correctly and still help send money to the wrong place.
The unanswered question is what the badge verified: the message’s origin, its integrity, the sender’s identity, the sender’s right to change this beneficiary, or the buyer’s approval of that exact destination. A payment workflow becomes unsafe when one answer quietly substitutes for another.
A genuine account can carry an unauthorized request
The FBI’s Internet Crime Complaint Center describes business email compromise as a scam frequently carried out through compromised legitimate business email accounts, leading to unauthorized transfers.1 A familiar address and an existing conversation are insufficient grounds for accepting changed payment instructions.
The same problem can occur without a compromised account. A real employee may send a real message from the supplier’s real system. They might be allowed to discuss delivery dates and forward invoices, but not redirect receivables. Or their authority may cover one subsidiary while the invoice belongs to another.
Message integrity, sender identity and commercial mandate are separate questions. A cryptographic signature can preserve origin and content without establishing the signer’s authority for this transaction. NIST describes digital signatures as supporting origin authentication, data integrity and signatory non-repudiation when properly implemented.2 Those properties are useful, but they do not show that the signer may change a beneficiary.
The buyer has a distinct authority question. Approval of the debt confirms that an amount is owed; it does not approve where the money should go. This is one practical application of the distinction between evidence, authority and action, but the payment can be made safe without adopting a general control architecture.
Hold, verify, approve and enforce
The assistant may read the message and prepare a change request. It should not turn the request directly into an active supplier record. The existing beneficiary remains unchanged, the proposed change remains pending and affected payments are held. The system should not silently fall back to the old account: a legitimate change may mean that account is no longer usable.
Verification must begin from information established before the disputed request. IC3 recommends using secondary channels or two-factor authentication to verify requests for account-information changes with the intended recipient.1 The buyer should use a controlled contact route and someone recognized under the supplier’s agreed change procedure.
A telephone number extracted from the message is not an independent route. Nor are an email and its attached letter independent merely because they use different formats. The confirmation should name the supplier legal entity, beneficiary, account details, affected invoices or future-payment scope and effective date. “Spoke to supplier, all fine” leaves the destination ambiguous.
Once the check succeeds, an authorized buyer representative approves that exact change. The approval must cover the beneficiary version and transaction scope, rather than attaching only to the supplier’s name. At release, every payment path checks that the destination still matches the approved version and that the approval has not expired or been revoked.
A failed check leaves the change unapproved with a reason and escalation route. It does not automatically establish fraud. The request may be legitimate but incomplete, outside the sender’s mandate or inconsistent with another instruction. Staff need a way to resolve uncertainty without labelling a long-standing supplier an attacker or bypassing the control to keep business moving.
The detailed beneficiary-version mechanics and tests matter when implementing this path, but the operating rule is compact: hold, independently verify, approve the exact destination and enforce that approval at execution.
A callback and a click have limits
A callback avoids letting the disputed request define its own verification route. It does not prove that a familiar voice has authority, and a known employee can still make a mistake. The procedure depends on sound onboarding, maintained contact records and an agreed way to identify who may instruct the buyer. If those foundations are missing, automating the call cannot repair them.
Human review deserves the same scrutiny. If the reviewer sees only a supplier name, an amount and a reassuring badge, their click may transfer responsibility without improving the decision. The interface should show the proposed change, its supporting evidence, unresolved checks and the precise scope of approval.
Signatures and approval screens preserve useful evidence. Neither is a substitute for an execution rule. A background integration, administrator path or payment export that can ignore the approved destination leaves the workflow unsafe.
Start with the controls already in place
For a buyer with a manageable supplier base, a controlled supplier master, established confirmation routes, separate approval responsibilities and retrievable records may be sufficient. Accounting and banking tools may already support much of the required process. I would fix and test that path before proposing a shared ledger or verification network.
Additional infrastructure is worth examining only when several organizations repeatedly need to rely on the same history and bilateral records no longer meet the need. The case for going beyond internal audit logs depends on recurring reconstruction or dispute cost, not on the mere presence of AI.
For the payment at hand, the essential evidence is specific: the instruction, the supplier authority behind it, the independent confirmation, the buyer’s approval of the exact beneficiary and proof that release used that version. If the existing systems can retain and enforce those facts, they are enough. If they cannot, that is the engineering and operating problem to solve before giving an assistant more access.
Footnotes
-
Business Email Compromise, FBI Internet Crime Complaint Center. ↩ ↩2
-
Digital signature, NIST Computer Security Resource Center Glossary. ↩