Treat any unexpected request for money as untrusted until you verify it through a separate channel. Check that the sender is real, confirm the request directly with the person or organisation, and avoid clicking links, downloading files, or entering banking details from a message. If the request involves a payment app, only proceed through the official app after confirming the recipient.
Why payment requests in chat apps need a second-channel check
Virtual money requests are attractive because they compress urgency, trust, and action into a single message. That creates room for impersonation, social engineering, and mistaken payment to coexist in the same workflow. The real risk is not just a bad link or a fake QR code, but a recipient identity that has not been independently verified before funds leave the account. NIST SP 800-207 Zero Trust Architecture reinforces the same principle: do not assume trust because a request arrived through an expected channel.
People often treat a familiar chat thread as proof of identity, even though messaging compromise, account takeover, and forwarded requests can all preserve the appearance of legitimacy. In practice, many losses begin when the requester seems known enough that the payment step is rushed and the verification step is skipped.
How to verify the request before any transfer
The safest approach is to verify the request outside the channel where it arrived. Use a separate method you already trust, such as a known phone number, a previously saved contact route, or a direct call to a published organisational number. If the request claims to come from a business, charity, landlord, supplier, or colleague, confirm the payment details against an independent source rather than the message itself. The key question is not whether the message sounds plausible, but whether the recipient and the amount have been confirmed by a channel that the sender of the message could not easily control.
For QR code requests, the same logic applies with an extra check: scan only if you trust the source of the code, then inspect the destination details before approving payment. A QR code can hide the recipient address, reduce human scrutiny, or redirect the user to a payment flow that looks routine but is not. If the app shows a different name, account, or destination than expected, stop and verify again.
- Confirm the sender’s identity through a separate channel before paying.
- Compare the requested recipient, amount, and reason against an independent record.
- Use the official payment app or bank app, not a link sent in the message.
- Pause if the request creates urgency, secrecy, or pressure to bypass normal checks.
- Verify QR code destinations visually before approval, especially for first-time payees.
This guidance breaks down when the requester controls both the message thread and the secondary contact path, or when the recipient details are changed after verification but before authorisation.
When the request looks normal but the payment still is not safe
Tighter payment controls often add friction, so organisations and individuals must balance convenience against the cost of a mistaken transfer. The hard cases are not obviously suspicious requests, but routine-looking ones that exploit context: a known name with a new account, a familiar supplier with changed banking details, or a QR code that resolves to an unexpected destination. Guidance is consistent on one point, but industry practice still varies on how much extra friction is acceptable for low-value payments.
One common edge case is the repeated requester who asks for a small amount first and a larger amount later. That pattern can build false confidence and is easy to miss if people only validate the first payment. Another is the forwarded request in a group chat, where the original sender is not the same person who appears to be asking for money. In both cases, the message layer is less important than the verified identity behind the request.
If a payment app shows a real recipient name but the context is off, treat that as a warning sign rather than reassurance. The safest decision is to slow the transaction, re-check the source independently, and pay only when the person or organisation has been confirmed in a way that would still hold if the chat account or QR image were malicious.
Risk and Threat Considerations
Unexpected money requests combine identity spoofing, urgency, and a low-friction payment path, which makes them a common social-engineering target. The exposure increases when the request arrives through a chat app because the channel itself can be compromised, forwarded, or impersonated while still appearing familiar.
Failure mechanism: The attacker relies on trust in the conversation context, then uses a fake or hijacked account, altered payment details, or a malicious QR code to move the victim into an authorised transfer before verification happens.
Impact: Funds can be sent to the wrong recipient, recovery may be difficult, and the same trust channel may be reused for additional fraudulent requests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management and Access Control | Separate-channel verification reduces reliance on message-based identity trust. |
| PR.DS-1 — Data Management | Payment details must be validated before sensitive account data is used in a transfer. | |
| Recommendation — Require independent identity verification before releasing funds or approving a payee change. Protect payment details by confirming recipient data before any authorisation step. | ||
| CIS Controls v8 | 6.3 — Access Requests and Approvals | Unexpected transfer requests should follow controlled approval and verification paths. |
| Recommendation — Enforce formal approval checks for payment requests that arrive through untrusted channels. | ||
| MITRE ATT&CK | T1566 — Phishing | Chat-based payment fraud commonly uses deceptive messages to induce action. |
| Recommendation — Treat unsolicited payment messages as phishing until independently verified. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Knowing a contact name is weaker than confirming the underlying identity evidence. |
| Recommendation — Use stronger identity proofing when payment depends on a claimed person or organisation. | ||
Practitioner Guidance
What to prioritise: Verify the recipient, not just the message. A real-looking request is not enough if the payee identity, account details, or QR destination has not been confirmed through an independent route.
What to verify: Check whether the request matches a known reason, known amount, and known recipient. If any one of those changes, treat it as a new transaction and re-confirm it before authorising payment.
Decision rule: If the request creates pressure to act immediately, move the conversation to a separate channel and confirm first. If the requester resists that step, treat the request as higher risk even if the wording sounds routine.
Practitioner takeaway: The safest control is not message inspection alone, but payment verification that survives compromise of the chat thread, the QR image, or the conversation history.
Related resources from NHI Mgmt Group
- How should finance teams verify a wire transfer request before releasing funds?
- How can financial institutions detect APP fraud before money leaves the account?
- Who is accountable when a low-code app exposes sensitive data through weak authentication?
- How should financial institutions verify AI-assisted code before release?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
