Fraud Detection: How Online Businesses Detect Suspicious Activity

Fraud detection is the process of collecting evidence about an action, estimating how risky it is, and choosing what should happen next. In an online business, that action might be a signup, login, password reset, checkout, payout change, refund request, or support-assisted recovery. The goal is not to make every user prove they are human. It is to identify activity that does not fit the expected context and respond before the cost becomes difficult to recover.

Detection is one part of a larger control system. Prevention reduces the opportunities an attacker can exploit. Detection finds suspicious patterns. Response contains the incident and helps legitimate users recover. A useful program connects all three. A phishing message can lead to stolen credentials, a changed delivery address and a refund dispute. A script can create fake accounts, redeem a promotion and then disappear. Looking only at the final transaction hides the earlier signals.

The FBI Internet Crime Complaint Center’s 2025 annual report provides public context for cyber-enabled crime, but it cannot tell a particular company where its own exposure sits. That requires the company’s journey data, decision logs and confirmed-case feedback.

For readers comparing vendors, this distinction matters. A fraud detection platform may provide data enrichment, scoring, orchestration, case management or an API, but the business still owns the policy that determines which customers receive friction and how an incident is handled. Start with that policy question before comparing feature checklists.

What Fraud Detection Means in an Online Business

The simplest useful model is observe, score, decide and learn.

1. Observe: collect identity, device, network, behavior, transaction and journey context.
2. Score: compare the event with a baseline, rules, known patterns or a model.
3. Decide: allow, log, verify, limit, delay, review or block according to the risk and the cost of being wrong.
4. Learn: feed confirmed fraud, cleared cases and appeals back into policy and monitoring.

This model is broader than a payment screen. On registration, the concern may be coordinated account creation or promotion abuse. On login, it may be credential stuffing or a session that suddenly changes device and location. On recovery, the most important question may be whether the person requesting access can prove control through a channel the attacker does not own.

Map the Journeys and the Fraud Outcomes

Start with business outcomes, not a vendor feature list. Write down what an attacker could gain: an established account, stored payment credentials, a welcome credit, digital inventory, personal data, a seller payout or control of a recovery channel. Then mark the moments where that asset can change hands.

For each journey, record:

• the action an attacker is trying to complete;
• the normal behavior a genuine user is expected to show;
• the evidence already available before, during and after the action;
• the financial, operational and customer impact if the action is fraudulent;
• the person who owns an uncertain decision and the escalation route.

Avoid a risk statement such as “bad bots.” A testable statement is “automated account creation is redeeming the first-order credit across many apparently unrelated identities.” It names the journey, the behavior and the outcome. Add the current control, the remaining exposure, the owner and a review date to a risk register.

Likelihood alone is not enough. A frequent low-value attack can consume a review team, while a rare recovery attack can expose an entire customer account. Prioritize by consequence as well as frequency, and keep the priority visible when the journey or business model changes.

The map should also include the handoffs around the digital event. A checkout decision may depend on a risk service, a payment processor, a warehouse, a support queue and a dispute workflow. If one team cannot see why another team delayed or released an action, the organization loses time and creates inconsistent customer treatment. Record the evidence that must travel with the decision, the maximum review time, and the safe default when a dependency is unavailable. This turns fraud detection from a dashboard exercise into an operating contract between teams.

Combine Signals Instead of Chasing One Red Flag

No single signal proves fraud. People replace phones, share networks, travel, change payment instruments and make unusually large but legitimate purchases. Detection becomes more defensible when independent evidence agrees and the response reflects the cost of a false positive.

Signal group	Useful questions	Common caveat
Identity and access	Is the account new? Were credentials, recovery factors or profile details just changed?	A new account is not automatically fraudulent
Device and network	Are devices linked across accounts? Is the session using an emulator, proxy or unusual network path?	Shared Wi-Fi and mobile networks create overlap
Behavior	Does the navigation, timing or interaction sequence differ from the user’s baseline?	Accessibility tools and new journeys can look unusual
Transaction	Do amount, frequency, recipient, refund or promotion patterns make sense together?	Large or repeated transactions can be normal for some customers
Context	Is the location, campaign, time, customer history and current threat pattern consistent?	Context changes quickly and needs a freshness check

The NIST Digital Identity Guidelines address a wider identity problem, but their risk-based assurance principle is useful here: a public read, a familiar login and a payout-destination change should not inherit the same verification requirement.

Device context is one view among many. The device spoofing problem shows why a single identifier is not enough. If several accounts share device traits, timing and the same promotion pattern, the combination merits investigation. The device signal alone is not a verdict.

For automated traffic, promotion abuse is one business outcome that can make otherwise weak signals meaningful. The important design choice is how evidence is combined, not whether one signal is labeled “AI.”

Turn Detection Into Real-Time Decisions

Rules, anomaly detection and machine learning solve different parts of the problem.

• Rules express known constraints, such as velocity, payout changes or promotion limits. They are explainable and quick to change, but can become brittle.
• Anomaly detection compares an event with a user, device or journey baseline. It can surface new patterns, but needs careful treatment of seasonality and sparse data.
• Machine learning combines many features and can rank complex patterns. The emerging AI fraud problem makes review discipline more important because automation can change faster than a static rule set. It still needs representative labels, drift monitoring, review controls and a clear fallback when confidence is low.

The output should not be a forced allow-or-block decision. A practical response ladder is:

1. log low-risk activity for measurement;
2. allow familiar, consistent sessions;
3. add step-up verification when risk is uncertain;
4. rate-limit, hold or route a sensitive action to review;
5. block clearly abusive automation or repeated policy violations.

Step-up verification can serve as a human-verification layer when a session crosses a risk threshold. It should be one decision outcome inside the broader workflow, not a substitute for account, device, transaction and recovery controls. The same principle applies to MFA, payment checks and manual review: each addresses a different part of the risk.

Reduce False Positives and Improve After Review

A detection program that catches suspicious activity but rejects too many legitimate customers is not healthy. Track cleared cases, appeals, abandoned challenges, support contacts and repeat attempts alongside confirmed fraud. Sample decisions from every risk band so analysts can see where the score is useful and where a threshold is merely noisy.

When an incident occurs, contain it first: invalidate sessions, pause a payout, limit a promotion, revoke credentials or place the action in review. Preserve the decision context and timestamps before changing the system. Give the legitimate user a recovery path that does not depend on the email address, phone number or session the attacker controls.

The FTC’s phishing guidance is useful for employee and customer education. Internally, trace the entry path rather than stopping at the final purchase. Ask which signal was missing, which control fired too late, and which exception made the path easier. Then assign an owner and a review date to the repair.

Measure and Govern the Detection Program

Report outcomes with enough context to support a decision. A compact scorecard can include:

• confirmed fraud loss and prevented-loss estimates with documented methodology;
• attack rate by journey, channel and pattern;
• challenge, completion and abandonment rates;
• false-positive rate, appeals and successful reversals;
• time to detect, contain, review and recover;
• repeat incidents after a rule, model or process change;
• manual review volume, support contacts and operating cost.

Split these measures by journey. A sitewide challenge rate can hide an over-protected signup flow and an under-protected recovery flow. Annotate promotions, launches, traffic-source changes and policy releases so a predictable shift is not misread as a model failure.

Governance makes the numbers actionable. Name who can change a threshold, who reviews exceptions, who approves enforcement and who owns a customer-impacting rollback. Keep a short decision log for material changes. Review the control after an incident, a new journey, a meaningful change in attack behavior or a fixed operating interval.

Good governance also protects the detection data itself. Limit access to decision logs, document retention and deletion rules, and separate investigative notes from customer-facing explanations. Analysts need enough history to recognize coordinated activity, while product and support teams need a concise reason code they can act on. Review whether the data used for scoring still represents current customers and channels; an old baseline can make a legitimate seasonal pattern look dangerous or let a new abuse path blend into normal traffic. These checks do not replace security or privacy review, but they make the detection program easier to operate responsibly.

The objective is not the highest block count. It is a defensible balance of lower fraud exposure, tolerable friction, safe recovery and evidence for the next adjustment. A Business Rules Engine can express changeable business policy separately from scoring logic, but it is not a complete detection program.

Fraud Detection FAQ