Your AI should never approve a change to who gets paid

Payee and bank-detail changes need an out-of-band human check, because a convincing request is exactly what scammers now generate.

Share
Your AI should never approve a change to who gets paid

Payee and bank-detail changes need an out-of-band human check, because a convincing request is exactly what scammers now generate.

audio-thumbnail
Never approve a payee change brief
0:00
/88.096508

The most expensive email in your inbox

It usually looks routine.

A supplier emails to say they have changed banks. The message uses their logo, their usual sign-off and a reference to last month's invoice. It asks you to update their account details before the next payment run. Maybe it arrives in an existing thread. Maybe it comes with a letter on letterhead.

For years, the defence against this kind of fraud has been a sharp-eyed person in accounts who notices something off: a strange phrase, an odd domain, a request that feels rushed.

Now imagine that request is handled by an AI agent that reads the inbox, updates supplier records and prepares the payment file. The agent is fast, polite and thorough. It is also exactly the kind of reader a well-crafted fake is designed to fool.

Why AI makes this both easier to attack and easier to miss

The same tools businesses are adopting are being used against them. In a US survey of small and mid-market business owners published by Nationwide on 15 September, 31% said their company had been targeted by a scam or fraud attempt using generative AI in the past 12 months.

Generative tools make it cheap to produce a request that reads perfectly: correct tone, correct details, no spelling mistakes. The old tells are disappearing.

Inside the business, automation removes the pause where a person might have hesitated. An agent that is good at following instructions will follow a convincing instruction. If it has permission to change payee details and nothing in the workflow tells it to stop, it will make the change and move on.

That is not a flaw in the model. It is a flaw in what the model was allowed to do.

The rule: AI can flag, draft and prepare. It cannot approve.

Some actions are too consequential and too easy to fake to sit inside an automated flow. Changing who gets paid is near the top of that list. My recommendation is a hard rule:

No AI agent approves or applies a change to payee details, bank accounts or payment destinations. Ever.

That does not mean AI has no role. It can be genuinely useful here:

  • Spot the request. Recognise that an email or form is asking for a payment-detail change and route it to the right person.
  • Flag the risk signals. New bank, urgency, change close to a payment run, a reply-to address that does not match, a request to keep it quiet.
  • Prepare the check. Pull the supplier's known contact number from your own records, not from the email, and draft the verification task.
  • Hold the payment. Pause any pending payment to that payee until the change is verified.

The decision and the change itself stay with a person.

What an out-of-band check means

Out-of-band means verifying through a different channel from the one the request came in on, using contact details you already had.

  1. Call the supplier on a number from your own records, not one in the email or attached letter.
  2. Speak to someone you know, or confirm through your usual contact. Ask them to confirm the change, not just "is everything okay?"
  3. Record who verified it, how, and when.
  4. Have a second person approve the change if the amount or relationship is significant.
  5. Watch the first payment. Confirm with the supplier that it arrived.

It takes ten minutes. Compare that with the cost of a payment that lands in the wrong account.

Build it into the system, not just the policy

A rule in a policy document will not stop an agent with the wrong permissions. Make the boundary real.

  • Remove the permission. Agents should not have write access to payee or bank fields at all. If they cannot change them, they cannot be tricked into changing them.
  • Separate the steps. The person who verifies a change should not be the only person who can release the next payment.
  • Make changes visible. Any edit to payment details should notify the business owner or finance lead, every time.
  • Treat urgency as a red flag. Train people and agents to slow down when a request pushes them to hurry.

Questions to ask before your next payment run

  • Can any AI tool or automation in our business edit supplier bank details?
  • When a payee change comes in, what exactly happens, and who checks it?
  • Do we verify using contact details from our own records, or from the request?
  • Would we notice if a supplier's account number changed last week?

If you are not sure about the first question, find out today.

How I approach it at Walter

At Walter, I think about authority in terms of consequence. Drafting a reply is low risk. Changing where money goes is about as high as it gets in a small business. A good chief of staff would never quietly update a supplier's bank details because an email asked nicely. They would stop, verify and bring it to the right person.

AI should hold the same line. Let it spot the request and do the legwork. Keep the yes with a human who picked up the phone.

Join the waitlist at https://hirewalter.ai/