Account Takeover vs New Account Fraud: Signals, Owners and Shared Metrics

Account takeover and new account fraud are usually run by different teams, watched through different signals and counted in different reports, so the losses that cross between them are the ones nobody owns. Account takeover (ATO) is a criminal gaining control of a genuine customer's existing account; new account fraud (NAF) is a criminal opening an account that should never have existed, using stolen, fabricated or synthetic identity data. The first is an authentication failure and the second is an identity proofing failure, which is why security teams tend to own one and fraud teams the other. This guide compares their attack chains, signals, ownership, overlaps and shared metrics. It is for fraud, CIAM, security operations and risk leads; controls are covered in the linked guides.

Key takeaways

• Different failure, different moment. ATO defeats authentication of someone who was properly onboarded; NAF defeats identity proofing before any customer relationship exists. Signals and controls follow that line.
• The signal sets barely overlap. ATO shows up in login telemetry, session behaviour and changes to contact details; NAF shows up in application data consistency, evidence checks, device reuse across applications and early account behaviour.
• Split ownership by decision, not by fraud type label. Security usually owns the login and session decision, fraud usually owns the onboarding decision, and both must jointly own account recovery and the handover of signals.
• The two fraud types feed each other. Accounts opened fraudulently often receive the proceeds of takeovers, and account recovery is a second onboarding that ATO crews target. Linking the two is where most extra value sits.
• Share a small set of metrics. Report both on the same loss basis, with detection point, time to detect and good-customer friction measured the same way, so neither team can improve its own number by pushing loss to the other.

The short answer

If the account belonged to a real customer who was properly verified and someone else is now using it, it is account takeover. If the account was opened by someone who was never entitled to it, whether with a stolen identity, a synthetic identity or a bot-registered throwaway, it is new account fraud. FinCEN's analysis of identity-related suspicious activity reports draws the same line by the identity step that was exploited: impersonation targets validation, circumvention targets verification, and compromise targets authentication, with account takeover a subtype of compromise. In the 2021 Bank Secrecy Act data it studied, compromise was 18 per cent of identity-related reports but 32 per cent of their value; impersonation was 69 per cent of reports and 57 per cent of value.

Account takeover: threat model and attack chain

Threat model: the attacker wants the value already in, or reachable from, a trusted account: balances, stored cards, loyalty points, a verified identity or a high-reputation profile.

Architecture in words: the attack crosses four control points in order. The credential (password, one-time code, passkey) is checked by the authentication service. The session (cookie or token) is trusted by downstream services. The profile (email, phone, address, devices, recovery details) lets the attacker lock the owner out and redirect alerts. The value movement (payee, transfer, order, redemption) is where loss is realised.

Common chains:

1. Credential stuffing: bots replay breached username and password pairs through residential proxies.
2. Real-time phishing: a look-alike site or a caller impersonating the bank or a support desk relays the password and one-time code. The FBI's Internet Crime Complaint Center recorded more than 5,100 such ATO complaints, with losses above $262 million, from January to late November 2025 for schemes impersonating financial institution support, including search adverts that place phishing pages above the genuine site.
3. Session theft: infostealer malware or an adversary-in-the-middle proxy captures the session cookie, so no authentication is needed.
4. Recovery abuse: password reset, phone number change, SIM swap or a support agent, human or AI, is persuaded to hand control to a new contact point.

Failure modes: trusting a successful MFA as proof of the real customer; scoring the login but not later actions; allowing a contact change and a new payee in one session without delay; and treating support-assisted recovery as customer service rather than authentication. Full prevention detail is in the Account Takeover Prevention Guide.

New account fraud: threat model and attack chain

Threat model: the attacker wants an account the organisation will extend credit, payment rails, promotions or reputation to, without any intention of honouring the relationship. The Federal Reserve's focus group defines synthetic identity fraud as using a combination of personally identifiable information to fabricate a person or entity for dishonest gain; stolen identity (true-name) fraud uses a real person's details unchanged; automated fake accounts, which OWASP catalogues as OAT-019 Account Creation, are opened in bulk for spam, laundering cash or goods, malware distribution and manipulation of reviews.

Architecture in words: the controls run as a pipeline. Data collection captures the application and device. Validation checks the claimed attributes exist and are consistent with authoritative or credible sources. Verification checks the applicant is the owner of those attributes, for example with document and selfie checks. Fraud checks look for known-bad data, devices and patterns across applications. Account opening then sets initial limits, and early-life monitoring watches the first weeks of use. NIST SP 800-63A-4 makes the fraud check stage explicit: credential service providers SHALL run a fraud management programme including a check that the applicant is not deceased, which it ties to synthetic identity and stolen identity fraud, and SHOULD check SIM swap history, phone and email tenure, high-risk mailing addresses, device fingerprints for duplicate enrolments and velocity.

Common chains:

1. Stolen identity application: real personal data used with an email and phone the fraudster controls.
2. Synthetic build and bust-out: a fabricated identity builds a credit profile, then draws every line at once.
3. Mule account opening: accounts opened in stolen, synthetic or recruited identities exist to receive and move other fraud proceeds.
4. Bulk sign-up: bots register many accounts for promotion abuse, spam or later sale.

Failure modes: checking that data exists but not that it belongs together; treating document verification as all of proofing; scoring each application alone; and approving full limits with no early-life monitoring. Detail is in the Account Opening and Application Fraud Guide, the Synthetic Identity Fraud Guide and the Fake Account Creation and Sign-up Fraud Guide.

Signals at login versus signals at onboarding

The two problems are detected from different telemetry, often held in different systems. The table lists the signals each team needs and the one most often missing.

The OpenID RISC Profile 1.0 (final, 29 August 2025) event types reflect both sides: account-disabled can carry the reason hijacking or bulk-account, and recovery-activated, recovery-information-changed and identifier-changed are exactly the profile events that precede takeover losses. See the Shared Signals Framework Guide.

Where the two meet

• Mule accounts close the loop: takeover proceeds have to land somewhere. Accounts opened with stolen or synthetic identities are a common destination: a confirmed ATO payee is a lead for onboarding, and a new account receiving first-time transfers from unrelated senders is a lead for the ATO team. See the Money Mule Detection Guide.
• Recovery is a second onboarding: when a customer has lost every authenticator, the organisation has to re-establish who they are. NIST SP 800-63A-4 lists account recovery as a condition that can trigger reverification. It runs on proofing controls the login team often does not own. The Meta AI Instagram account takeover shows the pattern: an AI support assistant sent reset links to an email address the requester supplied, affecting 20,225 people, while accounts with two-factor authentication were not taken over.
• Same infrastructure, both attacks: the residential proxy pools, device emulators and phone number suppliers used for credential stuffing are also used for bulk registration. A shared device and network reputation store serves both teams.
• Classification drift: a fraudulent account opened months ago and later "taken over" by its own creator is first-party fraud dressed as ATO. Count it once. See the First-Party Fraud Guide.

Who owns what

US creditors and financial institutions already have a legal hook that spans both: the FTC Red Flags Rule, 16 CFR 681.1, requires a written identity theft prevention programme for covered accounts that addresses identity theft "in connection with the opening of a covered account or any existing covered account". The board or a committee approves the initial programme. One programme, two attack surfaces: a basis for a single accountable executive.

Operating models (aligned, integrated or fusion centre) are covered in the Fraud and Cyber Convergence Guide. Whatever the model, recovery and bot defence on sign-up fail most often, because each team assumes the other has them.

Controls by attack, linked out

Most controls act on one side only. Phishing-resistant authentication, breached-password screening and session binding change ATO outcomes: NIST SP 800-63B-4 requires AAL2 verifiers to offer at least one phishing-resistant option, caps consecutive failed attempts at 100 per authenticator, and sets AAL2 reauthentication at no more than 24 hours overall and 1 hour inactive. Document verification, liveness and data linkage checks change NAF outcomes. Device intelligence, SIM swap checks and bot management work at both doors, which is why they belong on a shared platform. See the Passwordless and Passkeys Guide, Session Hijacking and Cookie Theft Guide, Document Verification vs Liveness Detection, Device Intelligence and Fingerprinting Guide, SIM Swap Fraud Guide and Bot Management Guide.

Worked scenarios

Scenario 1: a takeover that pays a mule

A bank customer reads a one-time code to a caller posing as the fraud team. Within twelve minutes the attacker adds an email address, registers a device and sends the daily maximum to a new payee. The money went to an account opened three weeks earlier with a recently ported phone number and a device seen on two other applications. Split model: security sees a successful MFA login, fraud sees a transfer within limits, and onboarding never hears that its new account received stolen funds. Joined model: the profile change plus new payee within one session triggers step-up and a hold; the confirmed ATO payee is fed back to onboarding, which finds the two linked applications sharing the device and closes all three.

Scenario 2: a bulk registration wave before a promotion

An online marketplace launches a sign-up bonus. Most applications share a small set of device fingerprints and use email addresses created that week. Two weeks later, credential stuffing rises from the same proxy ranges. Split model: marketing counts growth and security treats the stuffing as unrelated. Joined model: the shared reputation store already holds the sign-up indicators, so login defence blocks them on day one and bonuses wait for early-life checks.

Choosing how to split the work

• Small organisations: one fraud and identity owner covering both, with a single risk engine scoring login, sign-up and recovery events. Buy device and bot signals once.
• Mid-size: separate operational teams, but one shared event schema, one device and network reputation store, and a weekly joint review of cases that crossed the line, such as ATO payees and recovery attempts.
• Large or regulated firms: named owners per row of the ownership table, a joint case queue for cross-domain cases, automated feeds between the ATO and onboarding models, and a single executive accountable for identity-related losses under the identity theft programme.
• Credit products: weight NAF more heavily: synthetic identities and bust-out losses are slow and often have no complaining victim.
• Stored-value, loyalty and high-reputation accounts: weight ATO more heavily: value is reachable immediately after login.

Shared metrics

Measure both on the same basis so neither team can improve its figure by shifting loss to the other. Definitions are in the Fraud Metrics and KPIs Guide.

How to implement

1. Agree the classification rule: write down when a case is ATO, NAF, first-party or mule, and how a case that is two of these is counted once. Apply it to 12 months of confirmed cases as a baseline.
2. Map the control points: list every door into an account (sign-up, login, recovery, support channels, AI assistants, partner APIs) and record the owner and the signals collected at each.
3. Build the shared signal layer: one event schema for login, sign-up, recovery and profile change events, and one device and network reputation store. Start with read-only enrichment.
4. Close the mule loop: feed confirmed ATO payee accounts to the onboarding team and early-life pass-through alerts to the ATO team. Pilot on one product with a joint weekly review.
5. Raise recovery to proofing standard: send reset links only to contact points already on file, notify the old contact point of any change, and require reverification for full-factor loss. Test in shadow mode first.
6. Roll out decisions in rings: new rules start in monitor mode, then apply to a small share of traffic, then to all. Keep a documented rollback per rule version and watch good-customer friction daily.
7. Report jointly: publish the shared metrics monthly to the accountable executive, and review cross-over cases quarterly to adjust ownership.

Framework mapping

Common failure patterns

• Recovery owned by nobody: the login team assumes the contact centre verifies callers, and the contact centre assumes the login team has controls. The Meta AI Instagram account takeover is the example.
• Separate device stores: security blocks a device at login while onboarding approves applications from it.
• Counting the same loss twice, or not at all: without a classification rule, a mule-related loss appears in both reports or falls between them.
• Measuring sign-ups as growth only: bulk registration before a promotion inflates growth metrics and is not reviewed until bonuses are paid out.
• No feedback on confirmed cases: each side's models learn only from their own labels.

Practitioner checklist

• Write a classification rule for ATO, NAF, first-party and mule cases and apply it to historical data.
• Name one accountable owner for each row of the ownership table, including recovery.
• Put login, sign-up, recovery and profile change events into one shared schema.
• Run a single device and network reputation store used at both doors.
• Feed confirmed ATO payee accounts to onboarding and early-life alerts to the ATO team.
• Send reset links only to contact points already on file and notify old contact points of changes.
• Offer phishing-resistant authentication and check SIM swap history before sending codes.
• Report loss rate, detection point, time to detect and friction on the same basis for both.

Standards and references

• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• eCFR: 16 CFR Part 681 Identity Theft Rules (Red Flags Rule)
• FinCEN: Financial Trend Analysis, Identity-Related Suspicious Activity
• FBI IC3: Account Takeover Fraud via Impersonation of Financial Institution Support
• OWASP: Automated Threats, OAT-019 Account Creation
• OWASP: Credential Stuffing Prevention Cheat Sheet
• OpenID Foundation: RISC Profile Specification 1.0

Related NHI Mgmt Group resources: Account Takeover Prevention Guide · Account Opening and Application Fraud Guide · Identity Fraud Prevention Guide · Fraud and Cyber Convergence Guide · Account Recovery and Help Desk Security Guide