A request that seems familiar
A family member writes from their usual number and asks for an immediate transfer. The profile picture matches, and the chat history looks familiar. Even so, someone else may temporarily control the account, the device may be compromised, or the request may have been fabricated using earlier messages.
Three different questions
Recognising a contact does not authenticate who is writing at that moment. And authenticating an account does not establish whether its holder freely authorised the instruction. Identity, access to a channel and the intention to carry out a transaction are separate facts. In a dispute, each requires its own evidence.
Signals and limits of verification
Unusual wording, timing or urgency can help prompt questions, but none is conclusive proof. Asking for a call through another channel or using a previously agreed question may reveal inconsistencies, although neither replaces the checks required for high-impact transactions. The level of verification should be proportionate to the potential harm.
Context can completely change what constitutes a reasonable response. Confirming the time of an appointment is not the same as authorising the transfer of an identity document or making an irreversible payment. Individuals and organisations can agree on graduated verification procedures: the greater the consequence, the less the familiarity of the channel should count as sufficient. This avoids turning every conversation into a forensic investigation while recognising that the same account may be used both for everyday information and for high-impact decisions.
If an intrusion is suspected
It is advisable to notify the person through alternative channels, review devices and active sessions, change compromised credentials and strengthen account-recovery mechanisms. Messages, dates and transaction details should be preserved proportionately if the events may need to be reconstructed. Publicly spreading the incident without care may expose third parties.
Designing channels that do not rely on blind trust
Platforms can provide useful alerts, session revocation, robust recovery and clear reporting mechanisms. Organisations that execute payments should incorporate controls proportionate to the risk. No individual recommendation can replace all the security decisions that the service provider is responsible for making.
A photograph, a telephone number or an old conversation creates familiarity, but it does not authenticate every request. The more irreversible a transaction is, the more independent its confirmation should be.
Familiarity is not authentication
A number saved in an address book, a profile picture and years of conversation can create trust. However, these elements identify a channel or a history, not necessarily the person controlling the account when a request is made. A phone may have been stolen, a session may remain open on another device, or an account may have been fraudulently recovered. Assessing an unexpected message requires separating the account holder's identity from the security of the medium being used.
This distinction is particularly important when the nature of the request changes. Arranging a meeting does not require the same checks as asking for money or requesting a copy of a document. The greater the consequences and the harder they are to reverse, the more reasonable independent verification becomes. Protection does not mean distrusting everyone; it means not automatically attributing an instruction to an account holder merely because the account looks familiar.
Verify through a channel independent of the request
If a contact asks for an urgent transfer, replying “Is that really you?” in the same chat may provide no evidence: whoever controls the account can answer. Calling the usual number may help in some cases, but it is not enough if the device itself is suspected of being compromised. It is better to have alternatives agreed in advance, such as a different contact route or a verification procedure established for important transactions.
In the workplace, confirmations may rely on managed directories and separate approvals. A change to bank details or the sending of confidential files should not be resolved solely because the person writing says it is urgent. These controls need to be practical and easy to use, with documented exceptions for genuine emergencies.
Protecting the account after unusual signs are detected
When there are signs of intrusion, the account holder may need to close active sessions, review linked devices, change recovery factors and notify contacts. The appropriate sequence depends on the platform and the account's condition. It is often sensible to secure the primary email account and recovery methods first, because someone who controls them may take over the account again even after its password has been changed.
A subsequent review should preserve relevant messages and dates without indiscriminately sharing screenshots that contain other people's information. It is also necessary to distinguish an attempt to deceive contacts from a transaction that was actually carried out. Receiving a fraudulent request does not, by itself, prove that a payment was made or information was disclosed.
Urgency should not cancel verification
Everyday scams often exploit emotional pressure: someone familiar appears to need immediate help. Verification procedures must remain usable in precisely that situation. Agreeing in advance how to confirm unusual payments or document requests avoids improvising when it is hardest to think calmly. If the transaction has already taken place, it is advisable to preserve information and contact the organisation involved promptly, without assuming that every transfer can be reversed. The aim is not to blame someone for trusting a message, but to design safeguards that work precisely when trust and urgency coincide.
Further references: NIST Digital Identity Guidelines