New account fraud red flags: what to check before activation

Explore checkers, demos and evaluation routes →

New account fraud is abuse carried through accounts opened for that purpose. It includes coordinated registrations, stolen or synthetic identity use and accounts created to exploit a benefit or service. Useful red flags combine device, network, contact and account evidence. One unusual field does not establish a fraudulent customer.

Distinguish a new account from an account takeover

A fraudulent registration creates access that did not previously exist. Account takeover uses someone else’s existing account. The controls can share device and network evidence, but the known facts differ: a new account may have no prior session history, while a takeover investigation can compare the login with an established owner’s activity.

Do not require a first-time visitor to have a trusted history on your site. Equally, a verified inbox or a plausible identity record does not establish that the account’s intended activity is permitted. Describe the specific abuse you are trying to stop: spam, repeated welcome offers, false seller listings or identity-based application fraud.

Stripe’s buying guide treats signup signals, decisioning and legitimate-user handling as separate evaluation questions. Use that structure to avoid buying a broad “fraud” label without knowing the protected action.

Review red flags as evidence, not automatic labels

Keep missing data separate from a positive finding. An unavailable device result is an operational condition. A network-history provider not seeing an identity is a coverage result. Neither should silently become “confirmed fake account.”

Connect the registration to earlier activity where available

An account can look ordinary in isolation while sharing meaningful relationships with other registrations. Device continuity, reused contact details, payout destinations and timing can strengthen an investigation. They do not make every linked account the same physical person.

ShieldLabs combines live device/network intelligence with returning identity and account-level abuse context. SEON’s new-account guide describes contact enrichment and connected registration patterns. Sift’s multi-accounting article adds event and workflow considerations. Verify which relationships exist on the first visit and which depend on later associated activity.

Put the result before the relevant privilege

“Before signup” can mean before a database record is created, before activation, before sending a message or before granting a bonus. Choose the actual boundary for your system. A pending record may be useful for retries and review while the account remains unable to use protected features.

Record the risk result separately from the action taken. Include a reason, campaign or product context and a stable registration reference. If a reviewer later changes the action, retain enough history to understand what changed. The integration guide covers session association and delayed results.

Measure the action and the underlying case separately

A step-up request is an action, not a fraud label. A customer abandoning that step may reflect friction, disinterest or an abusive attempt. A later payment can be genuine even when the account violated a one-customer promotion rule.

Use independently known legitimate applicants and controlled ineligible cases. Keep unresolved cases separate. Report legitimate activation, confirmed abuse allowed, legitimate access restricted, missing results and review effort. State the observation window rather than treating a quiet first session as evidence that the account can never become abusive.

FAQ

Sources

Checked October 21, 2026: Stripe, ShieldLabs, SEON, Sift. Compare all ten products and the complete guide.