Pause the conversation and treat the request as a potential fraud signal. Scammers often use fake profiles, then move targets to phishing pages, identity theft, or direct payment requests once trust is established. Users should avoid sending money, personal data, or verification documents, and they should report suspicious accounts through the platform before further engagement.
What the request is really signalling
When a dating chat shifts from normal conversation to money, verification documents, or off-platform links, the meaning of the exchange changes. The risk is no longer just awkward social pressure, it becomes a trust boundary test. Treat the request as an attempt to move you into a higher-risk channel where fraud, phishing, account takeover, or payment abuse becomes easier.
The safest interpretation is simple: the conversation itself is now evidence. You do not need proof of fraud to stop engaging, because the request pattern is already inconsistent with a legitimate dating interaction.
Why money, verification, and external links are high-risk cues
Requests for money are the most direct warning sign because they convert social trust into financial exposure. Requests for verification details often serve a different purpose, harvesting personal data, one-time codes, or identity documents that can be reused elsewhere. External links are also dangerous because they can lead to lookalike login pages, payment portals, or malware delivery. The common thread is that the scammer is trying to leave the app’s built-in protections and put you on their terms.
That pattern matters even when the message sounds urgent, emotional, or practical. A legitimate person may ask for confirmation through the app, but they should not need your documents, your cash, or a new website to continue the conversation.
If you want a broader verification benchmark for what good authentication and access control should protect against, OWASP ASVS is useful context for understanding why sensitive actions should not be pushed through untrusted links or weak verification flows.
How to respond without escalating the situation
Stop the exchange, do not click anything, and do not send money or documents to “keep the chat going.” If the account is genuine, it can continue without those demands. If it is fraudulent, additional replies usually only increase exposure by confirming that the target is responsive.
Use the app’s reporting and blocking functions before the conversation drifts further. Preserve screenshots of the request, the profile, and any links so that the platform has evidence if the account is later reviewed. If you already clicked a link or shared a code, treat that as a security event, not just a bad conversation, and change credentials or payment details promptly if needed.
For third-party contact and off-platform trust issues, NHIMG’s Third-Party, B2B and Contractor Access Guide is a useful reminder that outside-the-platform relationships need tighter verification, not looser controls.
Risk and Threat Considerations
These requests are dangerous because they often appear after a short period of trust-building, when the target is more likely to comply. The attacker does not need to compromise the app itself, only the person using it, then pivot to payment fraud, credential theft, or identity abuse once the conversation moves off-platform.
Failure mechanism: The scammer uses social rapport to lower suspicion, then introduces a money request, verification request, or external link that extracts value or redirects the user to a hostile endpoint.
Impact: The result can be direct financial loss, stolen credentials, compromised accounts, or misuse of personal information and identity documents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | External links often drive phishing against login flows. |
| V6 — Authentication | Requests for codes or verification details target authentication secrets. | |
| Recommendation — Review outbound login and verification flows for untrusted redirects. Require strong user verification and resist sharing authentication data. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Identity checks matter when a conversation asks for verification details. |
| AC-6 — Least Privilege | Minimise exposure by limiting what a user will share or approve. | |
| Recommendation — Verify identity before accepting any sensitive request. Limit access to sensitive data and actions to the minimum necessary. | ||
| NIST CSF 2.0 | RS.CO-2 — Incident reporting and communication | Suspicious dating-app requests should be reported through the platform. |
| Recommendation — Report suspicious accounts and preserve evidence promptly. | ||
Practitioner Guidance
What to verify: If the other person needs payment, identity proof, or a link to continue, verify why that is necessary before doing anything else. In a legitimate dating context, that need is usually a warning sign rather than a requirement.
Decision rule: If the request includes money, codes, documents, or a URL, treat it as unsafe until independently verified through a trusted channel. If you cannot verify the person through the app itself, disengage.
What good looks like: A normal conversation stays inside the platform, avoids urgency, and never depends on outside links, secret codes, or payment to proceed.
Practitioner takeaway: The safest move is to preserve the boundary, keep evidence, and disengage early, because once a chat asks for money or verification, the risk has already shifted from social interaction to fraud handling.
Related resources from NHI Mgmt Group
- How should security teams handle users who never enrolled a verification app?
- Who is accountable when a mobile app exposes users to one-click code execution through malformed links?
- How should security teams handle TOTP authentication when users want one app for both password management and verification codes?
- How should dating platforms implement selfie verification without creating too much friction for genuine users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
