Staff often say 'bank details' for two different things. Mixing them sends a supplier request to the wrong control.
Own bank mandate
A bank mandate is the arrangement with your own bank that says who may operate your organization's accounts. CC8 section 4.1 (England and Wales charities) says the mandate should be recorded, reviewed regularly and kept current when trustees change. Mandate changes need dual authorization; the second person should be a trustee.
A supplier email asking for new payment details does not change your mandate. It asks you to change where you send money.
Supplier payment instruction
A supplier payment instruction is the destination a supplier wants you to use. It normally sits in a supplier master, meaning the record of each supplier with its contact route and payment destination.
Four terms to keep apart
| Term | Plain meaning | Limit |
|---|---|---|
| Bank mandate | Who operates your own accounts | Not supplier destination |
| Supplier-master update | Editing stored destination | Not permission to pay |
| Verification | Gathering separate-channel evidence | Not approval |
| Payment authorization | Delegated decision to release | Not proof of authenticity |
Verification versus authorization
Verification gathers evidence. Authorization is a decision by a person with the right delegated authority under your local policy. The Charity Commission decision-making guidance says trustees stay responsible for what they delegate. A finance operator may prepare a verification record. That does not give the operator power to approve.
Neither step proves who owns an account. A phone call is a second communication type regardless of storage. Route suitability separately needs provenance and current trust. It is not proof of independence, of the identity of the person who answers, or of current trust in that route. A stored route may be stale or compromised. Record what the person who answered reported, as a reported statement, never as the contact recognizing the request. The responsible human must check whether the stored route is still trusted under local policy. If that stays unresolved, the hold stays.
Source claims and practice suggestions
- CC8 section 4.2: one person creates an online payment and another authorizes it. Its warning not to answer emails or calls asking for security details concerns your own credentials. It is not a way to authenticate a supplier.
- CC8 section 6.1: set written limits for approving payments.
- CC8 section 6.4: electronic transfers are hard to recall, so limit who can set them up and keep the setup documents.
- NCSC phishing guidance: confirm important email requests through a second channel, and help staff know the usual way payments are handled.
Practice suggestions, ours and not from the sources: hold payment until verification and a separate decision are recorded; keep master edits and payment release as two decisions with two records; record what remains unknown.
AI use boundary
AI output can be unreliable and does not authenticate a contact, route or account. The NCSC New Zealand AI guide for small businesses overview supports risk awareness only. Redaction and human checks here are our suggestions.
Fictional example
Supplier S-14 has approved invoice INV-28 for USD480, due November 6. A November 1 email asks for a changed destination and supplies a new phone number. Contact VC-07 was stored before that email; who stored it, provenance and currentness are unknown. No callback is made. The master is unchanged and payment is held. USD480 is the approved invoice amount, not a threshold or net balance.
Related
Email or callback, record template, how-to, exercise, Finance, Organization.