A message can look familiar and still ask for something that does not fit. A colleague who normally shares information may suddenly request a payment; a supplier may ask you to change account details in an email thread. Those differences deserve attention, but they do not prove the message is fraudulent: people’s responsibilities and circumstances can change. Compare the request with what the sender usually does, what the conversation has been about, and how this kind of task is normally handled. If something does not line up, pause and verify through a separate, trusted route before acting.
The useful bits
- Compare the requested action with the sender’s usual responsibilities.
- Check whether the request fits the conversation and expected process.
- Verify independently before sharing information, changing details or sending money.
Start with the action, not the tone
Read the message once to understand what it asks you to do. Then set aside its urgency, friendliness or formal wording and describe the action plainly: approve a payment, disclose information, open a file, change an account detail, or send a code. This makes it easier to assess the request itself rather than being reassured by a familiar name or convincing style.
Ask whether this action fits the sender’s usual responsibilities. A manager may request a project update, for example, but a request to provide a sign-in code may be outside the normal task. A mismatch is a prompt to check, not a verdict about who sent the message.
Compare the sender with the request
Think about the sender’s role and the kind of requests they ordinarily make. Consider whether they have a clear reason to ask for this particular action and whether the request would normally come from them. A familiar sender can pass along a legitimate request, but familiarity alone does not establish that the request is expected.
Look carefully at the displayed sender and the message details available to you. If you cannot tell whether the message came from the person you expect, do not resolve that uncertainty by replying to the same message and treating the reply as independent confirmation. Use a contact method you already trust, such as a known phone number or a separate established conversation.
Place the request in its conversation
Check what came before. Does the message continue a known discussion, refer accurately to the agreed task, and name the right people or project? Or does it introduce an unexpected demand, unusual secrecy, a new recipient, or a sudden change to payment or delivery details? Any one difference can have an innocent explanation, but several unexplained changes increase the reason to pause.
Be alert to messages that appear in a familiar thread but make a new kind of request. A conversation’s history provides useful context; it does not, by itself, confirm that a new payment instruction or sensitive request is genuine.
Check the usual process
Compare the message with the steps your organisation or team normally uses. For example, if changes to supplier payment details require confirmation by a second person, keep using that process even when an email says the change is urgent. If a request asks you to bypass an approval, use a different account, or keep the action from the usual reviewer, treat that deviation as a reason to verify.
Use the established process rather than a new link, phone number or contact detail supplied only in the message you are checking. Ask the relevant person through a route you have used before, or follow the documented procedure available to your team. Do not make a high-impact change just because a message presents it as routine.
A quick comparison in practice
Suppose a message appears to come from a supplier you have been discussing an invoice with. It asks for payment to go to a different account and says the change must be made immediately. The existing invoice discussion is relevant, but it does not confirm the new account instruction. Compare the change with the supplier’s usual process, then contact the supplier using contact details already on file—not details in the message—to confirm what is being requested.
Message: “Please send the payment to our new account today. Use the details below instead of the invoice.” Check: Is an account change expected? Does the sender normally handle payment instructions? Does the request follow the established approval process? Next: Pause payment and verify the change through a previously trusted contact route.
Verify, then close the loop
When something does not fit, ask a neutral, specific question through the separate trusted route: “Did you send the request to change the account details?” Confirm both the sender’s intent and the details of the action. For a consequential request, use the relevant approval steps rather than relying on a quick confirmation from an unverified channel.
You can confirm the check worked when the person or responsible team has confirmed the request through the independent route and the action matches the expected process. If they did not send it, or cannot confirm it, do not proceed; follow your organisation’s reporting procedure. If they did send it, you can continue through the normal process. The aim is not to label every unusual message as fraud, but to resolve the mismatch before acting.
- Name the requested action.
- Compare it with the sender’s role and the conversation so far.
- Check it against the normal process.
- Verify through a separate, trusted contact route before acting.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction