How can security teams spot scam activity before funds are lost?

Why This Matters for Security Teams

Scam activity is often treated as a customer awareness problem, but the operational risk sits squarely with security, fraud, and trust teams. Once a payment leaves the organisation, recovery is uncertain and incident handling becomes slower, more expensive, and more political. Control design should therefore focus on pre-transfer detection, not only post-loss remediation. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports layered monitoring, logging, and integrity controls that help surface suspicious activity early.

The mistake many teams make is relying on a single signal, such as keyword filtering in email or manual approval for large transfers. Scam operators adapt quickly. They move across channels, reuse legitimate-looking infrastructure, and exploit ordinary business processes such as beneficiary updates, invoice changes, and executive escalation. For that reason, teams should think in terms of correlated weak signals rather than one decisive alert. In practice, many security teams encounter scam activity only after a transfer has been authorised, rather than through intentional detection engineering.

How It Works in Practice

Effective pre-loss detection combines three layers: channel telemetry, behavioural context, and transaction controls. Channel telemetry covers email, collaboration platforms, SMS, voice, and web sessions. Behavioural context compares current activity against known patterns for the sender, recipient, account, and device. Transaction controls evaluate whether the requested action fits historic payment routes, beneficiary records, geolocation, approval chains, and timing.

A practical workflow usually starts by enriching signals before they reach a decision point. For example, a message that urges urgency may not be malicious by itself, but if it arrives from a newly registered domain, routes through a lookalike login page, and coincides with a first-time bank detail change, the combined risk is much higher. This is where detections should favour correlation over volume. Teams can also use URL inspection, domain age checks, attachment sandboxing, and wallet or beneficiary reputation data where relevant.

• Flag contact bursts that target finance, procurement, or executive assistants within a short window.
• Compare beneficiary edits against previous payment patterns and known approver behaviour.
• Watch for cloned branding, login page mismatches, and domain lookalikes that support impersonation.
• Require step-up verification when payment instructions change, especially for first-time recipients.
• Feed suspicious events into case management so analysts can stop or hold payments before release.

For organisations handling digital identity signals, this is also where trust and identity governance matter. Scam prevention improves when identity proofing, privileged workflow approval, and transaction monitoring are connected instead of treated as separate controls. The CISA scams and fraud guidance is useful for framing the broader threat pattern, while internal controls should map the alert to a specific workflow owner and decision threshold. These controls tend to break down when payment systems are fragmented across business units because no single team can see the full chain of contact, approval, and transfer.

Common Variations and Edge Cases

Tighter pre-transfer controls often increase operational friction, requiring organisations to balance fraud prevention against business speed and customer experience. That tradeoff is real, especially in payments, treasury, and high-volume service desks. Best practice is evolving here, and there is no universal standard for exactly which signal should trigger a hold versus a manual review.

High-risk edge cases include vendor onboarding, executive impersonation, urgent payroll changes, crypto-related transfers, and multilingual scams that bypass simple keyword rules. In these cases, teams should rely on stronger identity verification and process checks rather than content alone. For public-facing or high-value payment flows, the CISA Secure by Design approach is a useful reminder to build friction into the workflow itself, not bolt it on after the fact.

Identity-beyond-IAM teams should also consider whether account recovery, beneficiary change, or device reset paths are being abused as scam enablers. Where an organisation depends on human approval, the strongest control is often a second channel confirmation that is independent of the original request. That said, manual callbacks and callback lists are not sufficient if attackers have already compromised both email and collaboration tools. If the environment includes outsourced finance operations or federated approval chains, the guidance becomes less reliable because ownership and telemetry are split across multiple systems.

Related resources from NHI Mgmt Group

• How do security teams spot malicious activity after a legitimate login?
• How should security teams monitor AI agent activity without disrupting developers?
• How should security teams test partner API onboarding before production?
• How should security teams govern API partner onboarding before access control starts?