Fraud Prevention Guide for Digital Businesses

Digital businesses lose money to fraud twice: once to the fraud they miss, and again to the good customers they block, delay or annoy while trying to stop it. Reported losses keep rising: the FTC recorded more than $12.5 billion in consumer fraud losses for 2024, and the FBI's IC3 received 859,532 complaints with losses above $16 billion. This guide covers the fraud types that hit e-commerce, marketplaces, lenders, gaming platforms and public services; the signals, rules engines and models used to score risk; how fraud operations and review queues should run; and how to balance friction against loss with metrics that hold up. It is written for fraud managers, risk and payments leads, product owners and the security and identity teams who share the problem.

Key takeaways

• Run fraud as a programme, not a tool. GAO's fraud risk framework (Commit, Assess, Design and Implement, Evaluate and Adapt) applies to any business: a named owner, a written risk tolerance, a fraud risk profile and outcome metrics.
• Decide with layers of signals. Identity, device, behaviour, network, payment, phone and graph signals each catch different attacks; no single score or vendor sees everything.
• Use friction as a dial, not a switch. Most risky events should get step-up authentication, holds or review rather than a hard decline, because false declines cost revenue and customers.
• Check the phone number before you trust the OTP. NIST SP 800-63B-4 restricts SMS and voice codes and says verifiers should consider SIM change, device swap and number porting first.
• Measure loss and insult together. Track fraud loss rate, false positive rate, manual review rate and approval rate as a set, and test every rule change in shadow mode first.

Fraud types digital businesses face

Fraud follows money and value, so the mix depends on what your platform moves. OWASP's Automated Threats catalogue names the bot-driven forms, which is useful for shared vocabulary with security teams.

Public programmes show the cost of weak prevention at scale: GAO estimates pandemic unemployment insurance fraud was likely between $100 billion and $135 billion, about 11% to 15% of benefits paid (an estimate the Department of Labor said was likely overstated). In the UK, the Payment Systems Regulator set mandatory reimbursement for Faster Payments APP scams at up to £85,000 per claim from 7 October 2024, with the cost shared between sending and receiving firms, which makes receiving-side mule detection a direct cost issue.

Building a fraud prevention programme

GAO's Framework for Managing Fraud Risks was written for federal programmes but is the clearest public model for any fraud function. It stresses prevention over "pay-and-chase".

• Commit: a dedicated fraud function with defined authority and a direct line to senior management. In smaller firms this is a named owner, not a committee.
• Assess: a fraud risk profile listing each fraud scenario, its likelihood and impact, existing controls and residual risk, plus an explicit risk tolerance ("Determine fraud risk tolerance" is a named practice). Tolerance should be written as numbers, for example a target loss rate in basis points and a maximum false decline rate.
• Design and implement: an antifraud strategy with preventive and detective controls, data analytics, a response plan and collaboration with payment providers, banks and law enforcement.
• Evaluate and adapt: GAO says "Measure outcomes, in addition to outputs". Rules written and alerts reviewed are outputs; losses prevented and good customers approved are outcomes.

Fraud sits between product, payments, security, legal and customer support. Agree who owns each decision point (sign-up, login, checkout, payout, account changes, recovery) and who can change rules in production.

Signals and data

Score events with signals from several independent families. When one family is spoofed (a residential proxy hides the IP, a farm of real phones defeats emulator detection), the others still carry information.

• Identity: name, date of birth, address and document consistency; email age and domain; identity proofing results. See the Identity Proofing and KYC Guide.
• Device: device identifiers and fingerprint stability, emulator, root or jailbreak indicators, number of accounts seen on the device.
• Behavioural: typing and navigation patterns, copy-paste into identity fields, time to complete forms, session flow anomalies.
• Network: IP reputation, proxy, VPN, hosting provider and Tor indicators, distance between IP and billing location.
• Payment: card BIN country, AVS and CVV results, 3-D Secure outcome, number of instruments per account, bank account age for payouts.
• Velocity: counts per entity per time window (cards per device per hour, applications per phone per day, payouts per bank account per week).
• Graph and consortium: links between accounts through shared devices, phones, addresses, bank accounts and payment instruments; shared fraud data from industry consortia.

The PSD2 strong customer authentication rules, Commission Delegated Regulation (EU) 2018/389, set a useful minimum for payment monitoring. Article 2(2) requires transaction monitoring to consider lists of compromised or stolen authentication elements, the amount, known fraud scenarios, signs of malware in the authentication session and, where the provider supplies the device or software, abnormal use of it.

Scoring the phone number before sending an OTP

SMS and voice one-time passcodes are only as strong as the phone number. NIST SP 800-63B-4 classes the PSTN as a restricted authenticator, treats changing the registered number as binding a new authenticator, and states that "Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior)" before using it. In practice:

1. Check for a recent SIM swap through the mobile operator. The CAMARA SimSwap API's /check operation returns whether a swap occurred within maxAge hours (default 240, range 1 to 2400), and /retrieve-date returns the last swap date.
2. Check line type, carrier, recent porting and how long the number has been tied to the account.
3. If risk is high, do not send the code: use a passkey, an in-app confirmation or a delayed callback instead.
4. Throttle OTP sends per number, account and IP, which also limits SMS pumping, a form of what OWASP calls cost-inflation fraud (OAT-003).

Rules engines, scoring models and graph analysis

Most mature programmes run all of these together, with rules expressing policy and hard limits and models ranking risk.

Explainability: analysts need reason codes to review cases, and some decisions carry legal duties. In US credit, CFPB Circular 2022-03 says adverse action reasons "must be specific and indicate the principal reason(s) for the adverse action" whatever model produced the decision. Under the EU AI Act, Annex III point 5(b) makes creditworthiness scoring high-risk "with the exception of AI systems used for the purpose of detecting financial fraud", but where a fraud model effectively decides credit access, expect scrutiny. Automated declines of individuals can also trigger GDPR Article 22 and a DPIA.

Balancing friction against loss

Every decision point should support at least four outcomes: allow, step up (MFA, 3-D Secure, document check), hold or review, and decline. A useful rule of thumb is to decline only where the expected fraud loss exceeds the expected value of the good customer you might be turning away: probability of fraud times loss, against probability of legitimacy times margin and lifetime value. That pushes most grey-zone traffic to step-up rather than decline.

In the EEA, PSD2 makes this explicit through the transaction risk analysis exemption (Article 18 of Regulation 2018/389). A payment service provider may skip strong customer authentication for remote payments if its fraud rate, calculated on "a rolling quarterly basis (90 days)", is at or below the reference rate for the amount band, the payment is within that band's threshold, and real-time analysis has found no abnormal spending, unusual device, malware, known fraud scenario or abnormal location.

Because the exemption depends on the payment provider's own fraud rate, a merchant's fraud levels influence how often its customers face a challenge at checkout.

Fraud operations, review queues and investigation

• Review queue design: route only the score band where human review changes outcomes. A queue that approves 98% of cases is a friction tax; tighten the band or automate.
• Service levels: set review time targets by product (a held payout can wait hours; a checkout cannot wait minutes) and auto-decide on timeout using a documented default.
• Analyst tooling: one case view with the score, reason codes, linked entities graph, prior decisions and customer history; one-click actions with mandatory reason labels.
• Labels and feedback: analyst decisions, chargebacks, customer disputes and confirmed ATO reports must flow back as labels. Without them, models learn nothing.
• Investigation: investigators work rings and repeat actors across cases, prepare law enforcement referrals and evidence for chargeback representment, and feed new patterns into rules.
• Controls on the fraud team: reviewers can approve payouts and change account data, which makes them targets for bribery and social engineering. The Coinbase breach, where bribed support agents exposed customer data, shows why support and review tools need least privilege, data masking and monitoring.

How to implement

1. Baseline: measure current loss rate, chargeback rate, approval rate, false positive rate and review volume by product and channel for at least one full chargeback cycle.
2. Map decision points: sign-up, login, profile and payout changes, recovery, checkout, payout. Add event logging with consistent entity IDs before adding tools.
3. Quick wins: breached password checks and throttling at login (NIST SP 800-63B-4 caps consecutive failed attempts at 100 per authenticator, and lower limits are allowed), velocity limits, and step-up on payout and contact detail changes.
4. Shadow mode: run every new rule or model in log-only mode first, and backtest it against labelled history. Compare catch rate and false positives against the current setup.
5. Pilot: enable on a slice of traffic (one market, one product, or a champion and challenger split) with daily review of declines and complaints.
6. Roll out and roll back: version every rule and model, keep the previous version deployable, and define automatic rollback triggers such as approval rate dropping by more than an agreed number of points.
7. Govern: monthly rule hygiene to retire stale rules, quarterly model performance and drift reviews, and an annual refresh of the fraud risk profile.

Small and large organisations

• Small businesses and marketplaces: start with your payment provider's built-in risk scoring, 3-D Secure on risky transactions, payout holds for new sellers and a short manual review band. Buying a full fraud platform before you have labelled data usually just adds false declines.
• Mid-sized firms: add a configurable rules engine, device intelligence and phone risk checks, and a small review team with case management.
• Large firms and lenders: in-house models, graph analytics, consortium data, a separate investigations unit and model risk governance. Separate rule authoring from approval so one person cannot quietly change production decisions.

Where identity fits

Much digital fraud is identity abuse: fake identities at sign-up, stolen credentials at login, and social engineering at recovery. The 23andMe breach began with credential stuffing on about 18,000 accounts, and the Meta AI Instagram account takeovers came through an AI support assistant that sent recovery links to attackers. Treat recovery and support channels as decision points with their own risk scoring. Non-human identities matter too: the API keys your checkout uses to call fraud and payment services can approve or exfiltrate data if leaked, and AI shopping agents now transact on behalf of customers. See the Identity Fraud Prevention Guide, the Account Recovery and Help Desk Security Guide and the Agentic Commerce Identity Guide.

Detection and measurement

Log every decision with its inputs, score, rule hits, outcome and later label, so any decision can be replayed. NIST SP 800-63B-4 also requires organisations to assess fraud indicators "for efficacy" and include them in the privacy risk assessment. Track these metrics together, by product and channel:

• Fraud loss rate: fraud losses divided by total value processed, in basis points (PSD2 Article 19 uses value of fraudulent transactions over total value).
• False positive rate (insult rate): share of declined or challenged events later confirmed legitimate, measured with a holdout or appeals data.
• Approval rate: share of legitimate attempts completed without hard decline.
• Manual review rate and review hit rate: share of events sent to review, and share of reviewed cases confirmed as fraud.
• Chargeback rate: by count and value, against card scheme monitoring thresholds.
• Time to detect new attacks: from first fraudulent event to rule or model response.

Framework mapping

Common failure patterns

• Decline-first culture: fraud teams measured only on losses, so they tighten rules until approval rates and revenue fall. Give the team a false decline target as well.
• Rule sprawl: hundreds of overlapping rules nobody owns, each added after an incident and never retired. Version and review them like code.
• Trusting SMS codes blindly: sending OTPs to numbers that were swapped or ported yesterday, then treating the code as proof of identity.
• Weak recovery and support channels: strong checks at login and checkout, but a chat or phone agent can change email and phone details on request. The Arup deepfake fraud shows how convincingly attackers can now impersonate trusted people.
• No feedback loop: chargebacks and analyst decisions never reach the model, so it keeps scoring last year's fraud.
• Checking only the sending side: payments and marketplaces that ignore inbound mule accounts and new sellers receiving unusual volumes.

Practitioner checklist

• Name a fraud owner and write a numeric risk tolerance for losses and false declines.
• Build a fraud risk profile per product and decision point, and refresh it yearly.
• Combine identity, device, behaviour, network, payment, velocity and graph signals.
• Check SIM swap, porting and line type before sending SMS or voice OTPs.
• Offer allow, step-up, review and decline outcomes, and keep hard declines for high confidence.
• Run all new rules and models in shadow mode, pilot them and keep rollback ready.
• Feed chargebacks, disputes and analyst decisions back as labels.
• Apply least privilege, masking and monitoring to support and fraud review tools.
• Report loss rate, false positive rate, approval rate, review rate and chargeback rate together.

Standards and references

• NIST: SP 800-63B-4, Authentication and Authenticator Management
• NIST: SP 800-63-4, Digital Identity Guidelines
• EUR-Lex: Commission Delegated Regulation (EU) 2018/389, RTS on strong customer authentication
• GAO: A Framework for Managing Fraud Risks in Federal Programs (GAO-15-593SP)
• OWASP: Automated Threats to Web Applications
• MITRE ATT&CK: T1110.004 Credential Stuffing
• CAMARA Project: SimSwap API
• CFPB: Circular 2022-03, Adverse action notices and complex algorithms

Related NHI Mgmt Group resources: Identity Fraud Prevention Guide · Identity Proofing and KYC Guide · KYB Guide · Financial Services Identity Security Guide · Customer IAM (CIAM) Guide