The 3 P2P Crypto Scams That Still Work (and the Simple Rules That Stop Them)

P2P crypto trading feels “easy” because the flow is simple: agree on price, get paid, release coins. Scammers love simple flows—because one rushed click can be irreversible.

This post is a practical, operator-style checklist based on three scam patterns that show up again and again. If you run a brokerage, prop firm, or fintech that touches crypto rails (directly or indirectly), these are the rules your team should internalize and bake into SOPs.

1) Fake payment proof: screenshots are not settlement

The classic opener: “Bro I paid, release fast” followed by a bank screenshot (or a PDF “receipt”) that looks convincing enough to trigger panic. The scam works because people treat visual proof as bank settlement.

Rule: No money in YOUR bank app = no crypto release. A screenshot has zero evidentiary value because it can be edited, generated from templates, or taken from an unrelated transaction.

Operationally, treat this like a two-step control:

• Step 1: Verify inside your bank app (or bank portal), not via images, not via email notifications, not via SMS.
• Step 2: Release only after you see the credit posted to the correct account and in the correct currency.

If your staff is handling P2P flows on behalf of the business, make “bank app verification” a mandatory checkbox in the runbook—and audit it.

2) “I paid extra, send a refund”: the refund-to-third-party trap

This one is more subtle because it starts with money arriving. The buyer “accidentally” sends $1,100 for a $1,000 order, then asks you to send $100 back—often to a different account, wallet, or payment method.

If you comply, the scammer can later claim the original payment was unauthorized, reversed, or disputed (depending on the rail), while you’ve already sent “the refund” to an account you can’t recover from. Even when the original payment is legitimate, refunding to a different beneficiary creates a clean laundering path.

Rule: Refund only to the SAME account that paid you. If the payer wants a different destination, the correct response is: cancel, return funds to the original source, and have them place a new order.

Add two practical controls:

• Name matching: payer name should reasonably match the counterparty identity on the platform (expect edge cases, but treat mismatches as higher risk).
• Refund logging: record original transaction ID, refund transaction ID, timestamps, and who approved it.

From a compliance perspective, this also reduces third-party payment risk—something regulators and banking partners care about. Always check local regulations and your banking partner’s policies.

3) “Let’s trade on WhatsApp”: off-platform = no escrow = no protection

The moment someone says “Binance is slow, DM me,” you’re being steered away from the only thing that makes P2P survivable: platform controls (chat logs, dispute tooling, and escrow).

Off-platform, you lose:

• Escrow enforcement (coins can be released under pressure with no recourse)
• Dispute resolution (no ticket trail, no mediator)
• Evidence quality (screenshots and forwarded messages are easy to forge)

Rule: Never leave the platform chat. Keep communication and file sharing inside the platform where it’s logged and reviewable.

For teams, make this a hard policy: if a counterparty requests Telegram/WhatsApp/email to “speed things up,” the trade is cancelled—no exceptions. Speed is the scam’s lever.

The golden rule for P2P: verify first, then release

If you only remember one thing, make it this:

Check your bank app first. Then click “Release.”

That’s it.

In practice, “verify” should mean:

• The funds are credited (not “pending,” not an alert)
• The amount is correct for the order
• The currency and account are correct
• The payer details are not obviously inconsistent with the order

This is also where many ops teams fail under pressure—especially during peak hours. If your process depends on a human being calm and careful every time, it’s not a process; it’s a hope.

Turn these rules into an ops playbook (what to standardize)

Brokers and prop firms don’t need to run a full P2P desk to be exposed. Many businesses touch similar patterns via crypto deposits/withdrawals, PSP exceptions, manual refunds, or “VIP” handling. The goal is to standardize decisions so staff don’t improvise.

A lightweight playbook can be:

• A “release checklist” (bank app verification + amount/currency match)
• A “refund checklist” (same-source-only + approval threshold)
• A “communications policy” (no off-platform negotiation)
• A “stop-trade script” staff can paste when pressured (“We can only proceed inside platform chat and after confirmed settlement in our bank portal.”)

Also define escalation paths:

• When to freeze the trade
• When to request additional verification
• When to involve compliance

If you’re operating across jurisdictions, document local constraints and always check local regulations—especially around third-party payments and recordkeeping.

Where Broker/Prop risk shows up: fraud, AML, and reputation

Even if the direct loss is “only” one bad release, the second-order impact is what hurts operators:

• Fraud losses and operational drag: time spent on disputes, manual reviews, and customer complaints.
• AML exposure: third-party refunds and mismatched counterparties can look like layering—raising flags with banks and PSPs.
• Reputation risk: users remember the one time you “didn’t help” or “took too long,” even if the root cause was a scam.

This is why the best teams treat P2P-style fraud as an operations design problem, not a training problem. Training matters, but controls matter more.

The Bottom Line

P2P is simple—but that simplicity is exactly what scammers exploit.

Treat screenshots as noise, never refund to a different account, and never move negotiations off-platform.

Most importantly: verify inside your bank app first, then release.

If you want to operationalize these controls across payments, refunds, and risk workflows, Brokeret can help—start here: /get-started.