Account Takeover Fraud Guide

Why account takeover is a different problem from onboarding fraud

Most fraud controls are built around the moment a customer signs up. You collect documents, run checks and decide. Account takeover (ATO) breaks that model because the attacker never has to pass your onboarding. The account was verified months or years ago, it has history and trust, and the person using it now is not the person you verified.

That has three practical consequences for risk and product teams:

The identity is real, the session is not. The question shifts from "is this a real person?" to "is this the same person who owns the account?"
The damage is often in the changes, not the login. A login alone usually costs nothing. The loss happens when the attacker changes the email, phone number or payout details, then moves value out.
Your own recovery flows become the attack surface. Password reset, "lost my phone" and support-agent overrides are often weaker than the login they replace.

This guide covers how ATO happens, what it looks like in your data, and the controls that apply after sign-up. It does not cover checkout or card-level fraud in depth; see Transactional Fraud: Types, Signals and Controls for that, and Payment Fraud Risk Management for programme-level strategy. For the wider topic, see the fraud detection hub.

How account takeover happens

Attackers rarely use one technique. A typical operation combines a source of credentials, an automated or manual way to test them, and a method to get past whatever second factor exists. The table summarises the main routes.

Attack	How it works	What it exploits	Typical footprint in your data
Credential stuffing	Automated login attempts using username and password pairs leaked from other services	Password reuse across sites	High login volume, many accounts from few devices or IP ranges, high failure rate with occasional successes
Phishing and fake login pages	The user is lured to a lookalike page or message and enters credentials, sometimes a one-time code as well	User trust, weak or relayable second factors	Successful login with correct credentials from an unfamiliar device, often straight after a user clicked a link
SIM swap	The attacker persuades a mobile carrier to move the victim's number to a SIM they control, then receives SMS codes and recovery messages	SMS as a second factor or recovery channel	Normal password or reset flow completed with a valid code, followed by a new device and contact detail changes
Session hijacking	Session tokens or cookies are stolen, for example through malware, and replayed	Long-lived sessions with no re-check	No login event at all; a session suddenly appears on a different device, IP or location
Malware and remote access	Malicious software on the user's device captures credentials or acts inside the real session	Compromised endpoint	Familiar device but unusual behaviour: pasted inputs, fast navigation, new payee set up
Social engineering of support	The attacker impersonates the user to a support agent to reset access or change details	Manual overrides and weak knowledge-based checks	Account change initiated by an agent rather than the user, followed by a login from a new device
Insider or third-party access	Someone with legitimate system access abuses it	Excess permissions, poor audit	Changes with no matching customer session

Credential stuffing in more detail

Credential stuffing is the volume engine behind much ATO. Attackers take lists of credentials exposed in breaches elsewhere and replay them against your login, relying on people reusing passwords. The success rate per attempt is low, but the attempts are cheap and automated, so a small percentage still yields a large number of accounts. OWASP describes the technique and its mitigations in its credential stuffing overview.

The key point for defenders: the credentials are valid, so there is nothing "wrong" with the password. Detection has to rely on how the attempts arrive (device, IP, velocity, automation) rather than on the credential itself.

SIM swap in more detail

In a SIM swap, the attacker does not need to touch the victim's device. By taking over the phone number, they receive SMS one-time passcodes and account-recovery links. This matters because many services treat "can receive an SMS at this number" as proof of identity. If your reset flow ends in an SMS code, a successful SIM swap can turn a leaked password into a full takeover. It is one reason to treat SMS as a weaker factor and to add other signals around it, such as whether the device is known.

The ATO sequence: what attackers do after they get in

Looking at ATO as a sequence, not a single event, gives you more places to intervene. A common pattern looks like this:

Access. Credentials are tested or a session is taken.
Reconnaissance. The attacker checks balances, stored payment methods, saved addresses, loyalty points or personal data.
Lock-in. They change the email, phone number, password or security settings so the real user cannot easily get back in or receive alerts.
Extraction. Funds are transferred, a new payee is added, goods are bought with stored details, points are redeemed or data is exported.
Cover. Notifications are suppressed or forwarded, and the account may be abandoned or resold.

Step 3 is the most useful control point. Legitimate users do change their email and phone, but rarely within minutes of logging in from a new device and rarely immediately before a withdrawal. A "contact detail change followed by a payout" rule is simple and catches a large share of the damage even when the login itself looked clean.

Warning signs of account takeover

Some signs show up in your logs, others in customer behaviour and support queues. Both are worth monitoring.

In your systems

Spikes in failed logins, password resets or "forgot password" requests, especially across many accounts from the same device or network.
A successful login from a device, browser or location the account has never used.
Email, phone, password or MFA changes shortly after a login from a new device.
New payees, withdrawal addresses or shipping addresses added, followed quickly by a transfer or purchase.
Multiple accounts accessed from one device, or one account accessed from many devices in a short period.
Sessions that skip the login step or show behaviour that does not match the user's history, such as pasted passwords, unusually fast form completion or navigating directly to payout screens.

From customers

Reports of unrecognised activity, password-reset emails the user did not request, or loss of mobile signal that is unexplained (a possible SIM swap).
Complaints that the user is locked out and the registered email or phone is not theirs.
A rise in support contacts asking to change contact details on an account.

Detection signals that work after sign-up

No single signal is reliable by itself. The aim is to combine several into a risk score at each sensitive moment: login, reset, contact-detail change, new payee, withdrawal.

Signal family	What to look at	Why it helps
Device intelligence	Is the device known for this account? Is it linked to many accounts? Signs of emulators, automation or tampering	Attackers can copy a password but find it harder to reproduce a long-standing trusted device
IP intelligence	Proxy, VPN or hosting-provider use, location versus the account's usual pattern, IP shared across many login attempts	Credential stuffing tends to concentrate on a limited set of networks
Velocity	Login attempts per device, per IP and per account; resets per hour; accounts touched per device	Catches automation even when each attempt looks plausible
Behavioural signals	Typing and navigation patterns, session duration, order of screens visited	A real session by an attacker often follows a "go straight to the money" path
Contact-point quality	Is a new email address disposable or recently created? Is the new phone number valid and of a plausible type?	Lock-in changes often use throwaway contact details
Change-risk context	Time since login, time since last change, new device plus new contact detail plus new payee	Combinations are far more telling than any one event

ScreenlyyID's IP and device intelligence provides the device and network layer, and email validation and phone validation can be used to assess new contact details before you accept them. These feed into your own rules or into decisioning, where you can decide what happens at each risk level.

The prevention stack

Think in layers, ordered from least to most friction for the legitimate user. Most sessions should pass through the first layers without the customer noticing.

1. Reduce the value of stolen credentials

Block known-bad and automated traffic at the login endpoint using device and IP signals, rate limits and bot controls.
Check passwords against known-breached lists at registration and reset, and encourage password managers. Reuse is what makes credential stuffing work.
Do not reveal whether an account exists through different error messages or timing on login and reset.

2. Strengthen authentication

Offer authenticator apps, hardware keys or passkeys in preference to SMS. If SMS stays, treat it as one signal rather than proof.
Bind sessions to the device and shorten the life of sessions on sensitive actions to limit replayed tokens.
Require re-authentication, not just a valid session, for high-risk screens.

3. Step up on risky changes

This is where ATO is decided. Define a short list of "sensitive events" and attach a risk-based challenge to each:

Changing email, phone, password or MFA method
Adding a payee, withdrawal address or payout account
First withdrawal or large transfer after a change
Account recovery from a device not previously seen

For low-risk cases, a passkey or authenticator prompt may be enough. For higher-risk cases, ask for a fresh identity check: capture an ID document and run a selfie with liveness against the verified record from onboarding. ScreenlyyID's biometric verification supports this kind of re-verification, so the person recovering the account is compared with the person who opened it. Applying this selectively keeps friction for genuine users low.

4. Treat account recovery as onboarding

If a password reset plus an SMS code is enough to take over an account, the stronger login does not matter. Apply the same risk assessment to recovery as to a new sign-up, and consider a short hold on withdrawals or new-payee payouts after a recovery or contact-detail change. A cooling-off period of this kind gives the genuine owner time to react to the alert.

5. Notify and make reversal easy

Send alerts to the old email and phone when contact details change, with a clear "this wasn't me" link that locks the account. Attackers count on changing the alert destination first, so notifications to the previous details are your safety net.

6. Lock down support channels

Agents should not be able to override authentication on the basis of easily obtained personal details. Give them the same risk signals and step-up tools that the product uses, and log every agent-initiated change.

Response playbook

When you suspect an account has been taken over, speed matters more than certainty. A workable playbook:

Contain. Suspend sessions, freeze outbound payments and withdrawals, and lock credential changes. Do this automatically where the risk score is high.
Verify the genuine owner. Use a fresh identity check rather than knowledge questions, and send the recovery to verified, previously trusted contact points where possible.
Reverse the changes. Restore the original email, phone, payees and settings. Revoke all tokens and sessions, reset credentials, and require a new MFA enrolment.
Trace the spread. Search for other accounts sharing the same device, IP or new contact detail. ATO is rarely a single account. A case-management workflow such as case review helps analysts link and close related cases together.
Recover funds and report. Follow your internal and legal obligations for loss recovery and for notifying affected users or authorities. Requirements vary by industry and jurisdiction, so check the current rules with your regulator or legal counsel.
Support the customer. Tell users to change reused passwords elsewhere. If personal information was exposed, point US customers to the FTC's IdentityTheft.gov for a recovery plan, and see general consumer guidance from the FTC. Customers in other countries should use their local equivalent.
Learn. Record which signal or step caught the case, which did not, and update rules and thresholds.

Metrics to track

ATO programmes often report only losses, which lag. Track leading indicators as well, and measure friction so you do not trade fraud for abandonment.

Metric	What it tells you
Confirmed ATO rate (accounts per 10,000 active)	Overall exposure; trend matters more than the absolute number
Loss per ATO case and total ATO loss	Financial impact, including refunds and goodwill
Time to detect and time to lock out	How long an attacker has between access and extraction; shorter is better
Share of ATO caught before extraction	Effectiveness of controls around contact-detail changes and payouts
Credential stuffing attempts blocked versus passed	Quality of bot and velocity controls at login
Step-up challenge rate and pass rate	Whether you are challenging the right sessions; a low pass rate on challenged sessions suggests good targeting, while a high pass rate may mean you are adding friction for genuine users
False positives and locked-out genuine users	Customer cost of the controls
Recovery completion rate and time	Whether genuine owners can regain access without long support delays
Repeat victimisation	Whether recovered accounts are being taken over again because root causes were not fixed

Time to lock out is the metric that is least often reported and most useful. If you can only improve one number, shorten the gap between the contact-detail change and the point at which a human or a rule intervenes.

A practical starting point

If you are building or tightening ATO controls, a sensible order is:

Map your sensitive events and where recovery can bypass authentication.
Add device and IP signals at login, reset and the sensitive events, and start by logging scores before you enforce them.
Introduce step-up identity checks for the highest-risk combinations only, such as new device, contact-detail change and new payee.
Add notifications to old contact details and a short hold on payouts after changes.
Build the metrics above and review thresholds regularly.

The fraud detection and compliance product page and the fraud prevention solution describe how ScreenlyyID's identity verification, device and IP intelligence and validation tools fit together through a single API.

This article is general information, not legal or compliance advice. Regulatory and reporting requirements change, so check the current rules with the relevant regulator or legal counsel.

Frequently asked questions

What is account takeover fraud?

Account takeover (ATO) fraud is when a criminal gains control of a genuine customer's account and uses it as if they were the owner. Access usually comes from stolen credentials, phishing, SIM swaps or hijacked sessions. The attacker then changes account details and takes funds, goods or data.

What are the warning signs of ATO?

Common signs include spikes in failed logins or password resets, a successful login from a new device or location, and email, phone or MFA changes soon after. New payees followed quickly by a withdrawal, and customers reporting activity they did not do, are also strong indicators. The combination of events matters more than any single one.

How do device intelligence and step-up verification prevent ATO?

Device and IP intelligence show whether a session comes from a device known to the account or from a suspicious or automated source, so you can challenge only the risky sessions. Step-up verification then asks for stronger proof, such as an authenticator prompt or a fresh ID and selfie check, before sensitive actions like changing contact details or adding a payee. Together they stop an attacker who has the password but not the genuine owner's device or identity.

Account Takeover Fraud: How It Works and How to Stop It