How should crypto platforms reduce scam losses without slowing legitimate users?

Why This Matters for Security Teams

Crypto platforms do not lose money only because authentication fails. They lose money when a scammer can stay just credible enough to pass normal checks, then pressure the user into approving a transfer that looks routine on paper. That is why guidance increasingly favours layered controls, not a single hard gate. The NIST Cybersecurity Framework 2.0 reinforces the need to detect, respond, and recover continuously rather than rely on one-time identity checks.

The real challenge is preserving fast paths for legitimate users while inserting friction only when the transaction context changes. In crypto, that means combining identity proofing, behavioural signals, device reputation, and transaction risk scoring at the moment of action. NHIMG research shows why this matters at scale: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which underscores how quickly trust can be abused once an identity path is compromised. In practice, many security teams encounter scam losses only after funds have already been authorised, rather than through intentional prevention design.

How It Works in Practice

The most effective model is step-up intervention based on transaction intent, not blanket suppression of activity. A platform should evaluate the session, the payee, the amount, the frequency, the device, and the recent behaviour of the account before allowing a transfer to complete. When signals align with normal usage, the customer moves through with little friction. When signals diverge, the platform can introduce a delay, additional confirmation, or manual review.

For this to work, risk scoring has to happen at the moment of action. That is different from static KYC alone. A user may be fully verified, yet still be operating under coercion, impersonation, or a social-engineering flow. Current guidance suggests using layered controls such as:

• identity verification for account setup and sensitive account changes
• behavioural analytics for typing cadence, navigation, and session anomalies
• transaction-level risk scoring for destination, amount, velocity, and first-time payees
• friction controls such as warnings, cooling-off periods, and out-of-band confirmation for high-risk actions
• rapid human review for cases where the model confidence is low but the loss potential is high

This approach aligns with the NIST CSF emphasis on risk-based safeguards and with lessons from NHIMG’s Emerald Whale breach, where trust boundaries and operational shortcuts mattered as much as raw technical controls. The key operational principle is to make friction proportional to risk, so legitimate users are not punished for ordinary behaviour. These controls tend to break down when platforms rely on delayed batch reviews or fixed rules for all transfer types because the scammer can adapt faster than the review queue.

Common Variations and Edge Cases

Tighter transfer controls often increase abandonment and support overhead, so organisations must balance fraud reduction against user conversion and service load. That tradeoff becomes most visible in high-frequency trading, cross-border transfers, and first-time deposits, where legitimate behaviour can look abnormal even when it is not.

Best practice is evolving on how aggressive the friction layer should be. There is no universal standard for this yet, but most mature programmes separate low-risk, routine activity from high-risk actions such as new beneficiary setup, large withdrawals, or irreversible blockchain transfers. For example, platforms may allow instant movement for trusted patterns while requiring additional review for a transfer to a new wallet with no prior relationship.

Another common edge case is account takeover combined with scam coaching. In that scenario, the customer appears authenticated and cooperative, so simple login checks fail. NHIMG’s CI/CD pipeline exploitation case study is a useful reminder that once trust is misplaced, downstream controls are harder to recover. The practical answer is to preserve fast paths for stable behaviour, but trigger stronger review when intent, velocity, or beneficiary history does not match the account’s established pattern. When that pattern mismatch is ignored, the platform usually discovers the scam only after the transfer is final.

Related resources from NHI Mgmt Group

• How should dating platforms reduce fraud without making signup unusable?
• How should platforms implement age assurance without over-blocking legitimate users?
• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams reduce risk from malicious npm package installs?