Judge the pattern after a boundary, not the charm before it

Start with the response to a clear, narrow boundary

State one observable limit: “Do not contact me on other accounts,” “I will not share my location,” or “I do not send money or account codes in a chat.” Then record the response without debating it. A respectful contact may accept the answer, ask a practical clarification, or end the exchange. A concerning pattern appears when the same demand returns, the contact changes accounts, recruits other people, monitors availability, or converts the refusal into guilt, anger, punishment, or a test of loyalty. eSafety defines unwanted contact by its effect and recommends stopping replies, collecting relevant evidence, reporting, and using mute or block controls. The boundary-response pair is more useful than trying to infer intent from a polished profile.

Separate frequency, control, and material requests

Use three lanes in the ledger. Frequency covers repeated messages, calls, comments, reactions, or new accounts after a stop request. Control covers demands for immediate replies, location proof, password sharing, approval over other contacts, secrecy, or leaving a visible group for a private channel. Material requests cover money, gifts, payment details, documents, account access, private media, or moving funds for someone else. A single late reply or disagreement does not belong in all three lanes. The practical signal is a repeated move toward less choice and more access. Categorizing the action keeps the review factual and avoids labeling a person based on style, identity, culture, or one misunderstood sentence.

Notice relationship acceleration followed by a change of objective

Europol describes patterns that can include very rapid closeness or exclusivity, pressure to move private conversations elsewhere, inconsistent stories, requests for private media, and a later shift toward money or financial details. These signs should be read together and over time. A warm new connection is not itself evidence of deception, and someone changing a plan is not automatically a scam. Add a “pivot date” to the ledger: the first moment the conversation changes from getting acquainted to requesting access, secrecy, money, gifts, documents, or an action on another account. Compare later explanations with that pivot. Do not test the person by sending a small payment or a harmless-looking credential; verification should not create the very exposure being assessed.

Use a decision matrix instead of negotiating the story

For repeated contact after a stop request, preserve the minimal pattern and restrict or block the available routes. For pressure around location, private media, passwords, codes, or administrator access, decline and review permissions and active sessions through the product’s real settings. For money, gifts, payment instructions, or financial details, do not continue the transaction from the conversation; use independently reached service channels if an existing account or payment needs attention. The FTC explains that relationship scams may build trust before money requests and recommends ending contact and reporting a suspected scam. You do not need to prove the other person’s full story before maintaining your boundary. A decision can be based on the requested action alone.

Preserve a minimal pattern record before reducing contact

When it can be done without prolonging the exchange, capture the service, profile URL or in-app identifier, date and time, the relevant request, your boundary, the next contact, and any report reference. eSafety’s evidence guidance notes that repeated unwanted contact can require context across incidents; a short dated log often explains the pattern better than a pile of unrelated screenshots. Keep only what is necessary for the report. Avoid widely forwarding private conversations or duplicating sensitive media. Use the closest report category—unwanted contact, impersonation, deceptive request, or another current option—then mute, restrict, block, or narrow profile visibility. Keep the receipt because a report does not predetermine the platform’s response.

Test the product boundary with your own accounts

With your own secondary account or a consenting test partner, send an ordinary contact request, decline it, and verify whether it stays declined. Check whether mute, restriction, and block have different effects on messages, profile discovery, group invitations, mentions, and old conversation visibility. Review what the report form says it will include before submission. Do not simulate harassment against an unsuspecting person, create a deceptive relationship, or reproduce scam scripts. Record app version, device, test relationship, expected result, observed result, and any residual route. Repeat after changes to discovery, groups, message requests, or blocking. This bounded negative test evaluates product controls without turning a safety review into harmful contact.

Keep exploring this topic