Learn to Spot an Unverified Bank Change

The Practical Check

A request to change a supplier's payment destination is a claim, not a fact. It earns more trust only after a person checks it outside the message that made it. The usual ordinary check is a callback through a contact route stored before the request. A call is a second communication type regardless of storage; suitability separately needs provenance and current trust. It is not proof of independence, of the identity of whoever answers, or of current trust, because a stored route may be stale or compromised. The record should hold what the person who answered reported, not a claim that the supplier recognized the request. Nor does the check prove that an account belongs to the supplier. The responsible human must check current route trust under local policy. If that is unresolved, the hold stays. Two decisions follow the check and stay separate: whether to change the supplier master, and whether to release payment. A finance operator can prepare the record. A separate authorized approver decides under local policy. AI can help organize a record. It cannot call anyone, confirm who a person is, or approve a payment. A smooth AI sentence such as 'verified and safe to pay' is only text. If no check happened, the sentence is false.

Your Starting Facts

A request is a claim until it is checked outside its own message. A phone number printed in the request is not a stored route. A call is a second communication type, not proof of route suitability, identity or current trust. Verification and authorization are different steps with different owners. If the contact cannot be reached or route trust is unresolved, the hold stays.

Worked Example

Supplier S-14 has approved invoice INV-28 for USD480, due November 6. On November 1 an email asks for a changed payment destination and offers a new phone number. Contact reference VC-07 was stored before that email. No callback has been made. The supplier master is unchanged and payment is HELD and not released. The USD480 is a fictional example amount, not a limit, and says nothing about taxes, fees or any unpaid balance. An AI draft says: 'The change is verified and safe to pay.'

Try the Judgment Exercise

What is the right response to the AI draft?

Accept it, because the draft is detailed and confident.Reject the claim, keep payment held, and prepare a callback through VC-07 for a separate approver to review.Call the new phone number in the email, then update the supplier master.

Use the Checking Prompt

Copy this prompt into your own AI tool with non-sensitive inputs, then check the answer yourself. OpenAid does not send this text to an AI service.

Using only the fictional example above, return a classification table: statement | supplied fact, claim or unknown | evidence or gap. Treat an AI draft assertion as a claim, not proof. Return only the table: no next steps, recommendations or approval advice. Do not assume the user has decision authority. Keep route provenance/current trust, identity and account ownership UNKNOWN where not supplied. A human checks classifications against the example and actual policy; this exercise authorizes nothing.

Continue With the Resource

Verify a Supplier Bank Change Before Payment

Source and Scope

NCSC phishing guidance
Making it easier for users to recognise fraudulent requests; second communication channel
AI guide for small businesses (NCSC New Zealand)
Overview page only; unreliable or manipulated outputs
Internal financial controls for charities (CC8)
Sections 4.2 and 6.4

Fictional examples for practice. Completing an exercise does not certify competence.

From OpenAid · www.opendevelopmentaid.org/learn/learn-spot-an-unverified-bank-change · free to use with credit