Skip to content
Fraud & Compliance ← All terms

Account Takeover (ATO)

Definition

Account takeover is fraud where an attacker gains control of a legitimate customer account and exploits the stored payment credentials or account value within it.

Account takeover (ATO) is a fraud attack in which a bad actor gains unauthorised access to a legitimate customer's account — typically through stolen credentials, phishing, SIM swapping, or credential stuffing — and then uses the account to make purchases, transfer funds, or extract stored payment methods. ATO is distinct from new account fraud: the attacker exploits an existing trusted relationship with the merchant rather than creating a synthetic identity.

ATO is structurally harder to detect than payment fraud because it originates from a legitimate account with genuine purchase history. Standard payment risk models that look for suspicious cards or BINs are largely blind to ATO — the card and account are real, the fraud is the person using them.

ATO Attack Vectors

Credential stuffing: Automated attacks that test username/password pairs from previously leaked databases. Successful because users reuse passwords across services. A single data breach at a low-security site can yield credentials that work on high-value e-commerce accounts.

Phishing: Deceptive emails or SMS messages directing users to fake login pages. Particularly effective when combined with brand impersonation of the target merchant.

SIM swapping: Attacker convinces the victim’s mobile carrier to transfer their phone number to an attacker-controlled SIM. Bypasses SMS-based two-factor authentication, giving attackers access to any account secured by the victim’s phone number.

Malware / session hijacking: Keyloggers or browser-injected malware captures credentials in real time. Session token theft bypasses login entirely.

ATO Indicators

Unlike first-party fraud, ATO often produces behavioural signals that diverge from the account’s historical pattern:

  • Device fingerprint mismatch: Login from a device, browser, or operating system never previously associated with the account.
  • IP geolocation anomaly: Login from a geography inconsistent with the account’s historical locations.
  • Velocity anomaly: Multiple failed login attempts followed by success (credential stuffing signature).
  • Password change followed immediately by payment: Attacker secures the account, then monetises it.
  • Shipping address change at order time: Redirecting goods to a drop address the account has never used.
  • Rapid account data edits: Changing email and phone before a purchase removes the legitimate user’s ability to receive fraud alerts.

ATO and Stored Payment Methods

ATO is particularly valuable when the compromised account holds stored payment methods (card-on-file, stored bank account, wallet balance). The attacker can immediately transact without needing a stolen card — the legitimate card is already on the account. Merchants who allow one-click checkout without re-authentication for large orders or new shipping addresses are materially more exposed.

Detection and Mitigation

Account-level signals: Device fingerprinting, behavioural biometrics (typing cadence, navigation patterns), and login velocity rules are the first line of detection. These operate before the payment flow.

Payment-level signals: Address mismatch between stored and new shipping, first use of stored payment method from new device, and high-value transactions immediately post-login from new IP are all high-signal ATO indicators.

Re-authentication thresholds: Requiring strong re-authentication (3DS2 challenge or biometric) for transactions above a threshold, shipping address changes, or logins from new devices creates friction that blocks most opportunistic ATO attacks.

Credential breach monitoring: Services that monitor dark web credential markets and alert on accounts whose credentials appear in breach dumps allow proactive forced password resets before attackers exploit them.

The correct mental model for ATO is that it is an identity problem, not a payment problem — and defences need to operate at the account and session layer, not just at the payment authorisation step.

Related terms