The Vendor Changed Its Bank Details. Should AI Update the Record?

A convincing request is still a request, not proof that the person behind it is authorized.

This fifth-Thursday clinic uses a synthetic scenario. A small distributor receives an email that appears to come from a familiar supplier. It requests new payment details before the next invoice is paid. An AI assistant can summarize the message and prepare a review case; it must not quietly convert that message into a trusted master-record update.

The FBI's Internet Crime Complaint Center recommended verifying payment changes in person or through a known telephone number in an April 2020 advisory. That historical protective principle, not the advisory's old loss figures, is the starting point here.¹

The case on the table

Requested outcome: keep the supplier record accurate without redirecting a legitimate payment to an unverified destination.

Current tools: a shared email inbox, an accounting system with the existing supplier record, an established contact directory and an authorized staff review process. This is a fictional tool arrangement, not a claim that VerShep connects these products.

Authority boundary: reading and summarizing the request are not the same as verifying the requester. Updating the supplier record is a separate authorized action. Making a payment is another decision again.

Evidence gaps: who actually requested the change, how the contact was verified, whether the change is authorized and whether the proposed details match what the authorized supplier confirms. Write “unknown” where the case lacks an answer; the assistant should not fill the gap with a confidence score.

Repair the weak workflow

The weak version extracts the new details, notices a familiar supplier name and updates the accounting record. A more polished assistant does not repair that missing trust boundary merely by writing a better explanation.

For this clinic, I would let the assistant prepare a proposed-change case without writing to the master record. It can identify the existing supplier reference, summarize what the message requests and list the unanswered checks. Sensitive details should remain in the approved review system, not be copied into an unrestricted team message.

The responsible staff member then uses the established contact-verification process. Scamwatch likewise recommends checking changed payee information through independently sourced contact details and warns against using details in the suspect message. Agreement between the message and a phone number inside that same message is not independent confirmation.²

A familiar voice or a fluent conversation should not be treated as a substitute for the organization's identity and authorization checks. The decision owner records the basis for accepting or rejecting the proposed change. If the required evidence cannot be obtained, the case stays held with an owner; urgency does not supply the missing evidence.

Why revisit this now? Microsoft's September 10 security report describes observed executive and invoice impersonation. It reports indicators consistent with AI-assisted template development while explicitly saying those indicators do not independently establish the extent of AI authorship. This is bounded first-party context, not proof that this fictional message is fraudulent or that every scam uses AI.³

Run the smallest useful pilot

Use fictional supplier records in an authorized test environment. Do not change real bank details, contact actual suppliers for a deceptive rehearsal or initiate a payment. Give the team three test requests: a legitimate change with independently verifiable authorization, an impersonation attempt with substitute contact details and a request that remains unresolved.

Keep the assistant's first role narrow: prepare the Verification Case. It should contain:

• Request: what change is proposed and which existing supplier it concerns.
• Independent evidence: where the verification contact came from and what the authorized check established.
• Decision: the responsible owner, permitted action and unresolved conditions.
• Separation: a clear record that approving a master-record change does not itself authorize a payment.

Decide whether the pilot earns another step

Check whether each test produced an owned case, exposed missing evidence and prevented an unverified master-record change. Inspect what the reviewer actually received. Also record the review effort and missed or unnecessary holds; blocking every request is not a complete operating service.

Continue only if the team can explain the decision path and the unresolved cases. Any proposed expansion of write access needs a separate risk review, explicit authorization and fresh testing. A successful drafting pilot does not grant authority to update records or pay invoices.

This clinic is not a complete fraud-control program, a payment instruction or a guarantee that independent contact prevents every deception. It demonstrates one boundary worth rehearsing: the incoming request must not be allowed to manufacture the evidence that authorizes its own execution.