How should organisations stop fraud before a transaction is completed?

They should use layered controls that score intent, counterparty risk, device reputation, and account behaviour before authorisation. The key is to challenge high-risk actions in real time, not after settlement. For payment and crypto flows, prevention needs to sit inside the decision point, where step-up verification or blocking can still stop loss.

Why This Matters for Security Teams

Fraud prevention only works if the control sits before irrevocable value transfer. Once a payment is settled, a crypto withdrawal is broadcast, or a beneficiary change is confirmed, the organisation is moving from prevention to recovery. That shift matters because fraud operations increasingly blend credential abuse, synthetic identities, social engineering, and automation to make a legitimate action look ordinary at the moment of authorisation.

Security teams often underestimate how quickly risk can move from “suspicious” to “approved” when controls are tuned only for post-event detection. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for strong access, monitoring, and decision controls, but the fraud use case requires those controls to operate in-line with the transaction journey rather than around it. That means product, security, risk, and operations teams need shared rules for when to step up, delay, or deny an action.

In practice, many security teams encounter fraud only after a high-trust account has already approved the transaction, rather than through intentional pre-authorisation challenge design.

How It Works in Practice

Effective prevention combines multiple signals at the point of decision. The transaction should be evaluated against account history, device integrity, IP and geo anomalies, beneficiary novelty, behavioural drift, and the risk of the counterparty or wallet. No single signal is enough on its own. The strongest programs use a policy engine that can respond in milliseconds with one of three outcomes: allow, step up, or block.

That decision engine should be fed by identity, device, and transaction telemetry. For example, a known user on a trusted device sending a normal amount to an established payee may pass with no friction. A sudden transfer to a first-time recipient from a new device and unusual location should trigger stronger verification, a cooling-off period, or manual review. For higher-risk domains such as payments and digital assets, organisations should also validate whether the request aligns with normal account purpose and historical velocity.

Operationally, this works best when fraud rules are linked to identity assurance and privileged action governance. A transaction that changes payout details, adds a new withdrawal address, or modifies payment rails is often more dangerous than the payment itself. Mature teams treat those changes as protected actions and require stronger evidence of user intent. That is where account behaviour analytics, step-up authentication, and workflow controls come together.

• Score the request before authorisation, not after confirmation.
• Use multiple signals, including device reputation and behavioural anomaly detection.
• Apply step-up verification to high-risk, high-impact, or first-time actions.
• Introduce manual review or hold periods for irreversible transfers where feasible.
• Log the decision path so investigators can explain why an action was allowed or stopped.

For payment environments, control design should align with secure software and operational safeguards described in NIST SP 800-53 Rev 5 Security and Privacy Controls, while payment security expectations such as PCI DSS documentation are often used to support logging, access, and monitoring discipline. These controls tend to break down when payment decisioning is split across legacy systems and separate fraud tools because latency, inconsistent identity context, and manual exception handling create gaps at the exact moment intervention is needed.

Common Variations and Edge Cases

Tighter pre-transaction control often increases customer friction and operational overhead, requiring organisations to balance fraud loss reduction against conversion, support load, and false positives. That tradeoff is especially visible in sectors where users expect instant settlement or where legitimate high-value transfers are frequent.

There is no universal standard for how much friction is acceptable, so best practice is evolving toward risk-based orchestration rather than static rules. A low-risk retail payment may need only passive scoring, while a first-time crypto withdrawal, a newly added payee, or a profile change should trigger stronger challenge. In some environments, transaction holds are not practical, so the control objective shifts to rapid confidence scoring and immediate denial thresholds. In others, especially regulated finance, delayed release and callback verification may be appropriate.

Identity signals matter here, but they should not be treated as proof of legitimacy on their own. A verified account can still be compromised, and a trusted device can still be remote-controlled or cloned. For that reason, current guidance suggests combining identity assurance with step-up controls, out-of-band confirmation, and transaction-level policy. Where fraud patterns resemble account takeover or automated abuse, teams should also map the attack path to MITRE ATT&CK techniques to improve detection and response design. The control model is weakest when organisations assume a successful login means the rest of the session is safe.

Related resources from NHI Mgmt Group

• How should security teams stop SMS toll fraud before cost accumulates?
• How should organisations stop romance and investment scams before money moves?
• How should gaming platforms stop SMS toll fraud before verification costs spike?
• How can organisations detect onboarding fraud before access is granted?