Account takeover fraud detection: how to catch ATO in real time with AI agents
Consider a customer we'll call Blake. Late one evening, someone logs into his account from a phone that has never touched it before. Within nine minutes the email address on file changes, then the password. Five minutes after that, an outbound transfer is queued to an account Blake has never paid.
Each of those events is ordinary on its own. People buy new phones and forget passwords every day. Put together in that order, though, they describe an account takeover in progress, and account takeover fraud detection comes down to recognizing the sequence before the money leaves.
That sequence is what Unit21's product team walked through in the first session of our AI and financial crime masterclass series. This post follows the same path. It starts with building ATO detection rules and stopping risky transfers in real time, then moves to what happens after the alert fires, when an AI agent does the first pass and an analyst makes the call.
In short:
- Single signals like “new device” catch too many good customers. Combining device, location and account-change signals, and watching the order they happen in, is what separates a takeover from a customer with a new phone.
- Fraud teams can describe an ATO rule in plain English, test it against past data and in shadow mode, and only then let it touch live customers.
- Real-time rules can deny a transfer, ask for step-up authentication, or let it through and open an alert for review.
- An investigation agent can assemble the evidence on each ATO alert before an analyst opens it, and the analyst still makes the decision.
Watch the full session: the AI and financial crime masterclass on account takeover is available on demand (about 40 minutes).
Why static rules miss account takeover
Account takeover (ATO) is when a criminal gains control of a real customer's account, usually with stolen or guessed credentials, and uses it to move money or change the account's details. Our dictionary entry on account takeover fraud covers the definition and common examples in more depth.
Two things have made ATO harder to catch. The first is scale. Credential stuffing runs at machine speed now, so a fraud team sees many more takeover attempts than it did a few years ago. The second is that the signals themselves are less trustworthy. Proxies, device spoofing and location spoofing all exist to make a fraudster look like a returning customer. Our guest post on how account hijacking unfolds walks through these attacks step by step.
A static rule struggles with both. Take a simple one: flag every login from a new device. It fires on every customer who upgraded their phone this month, and your team either drowns in those alerts or loosens the rule until it catches very little. Neither outcome is free. Every good customer who gets blocked or held is a real person having a bad day with your product, and some of them will not come back.
Said another way, the question is rarely “is this signal present?” It is closer to “is this combination of signals, in this order, still the account holder?” That is where detection has to start.
Account takeover signals that work in combination
Most useful ATO signals fall into two groups. Some describe the session: the device, where it claims to be, and what is running on it. Others describe what the person does once they are in. A takeover usually shows up in both, and the strongest detection logic joins them.
Notice that almost nothing in that table is conclusive by itself. A password reset is routine. So is a new phone. The demo's example rule only fired when a new device, a changed email or password, and a large transfer all appeared together.
Device signals can come from the Unit21 Device SDK for device intelligence or from custom fields your team already collects. Either way, they become fields you can use in rules. For a longer look at individual warning signs, see our post on the biggest risk signals for account takeover fraud.
Building account takeover fraud detection rules from plain English
A common reason ATO rules lag behind attacks is that writing them requires knowing the data model well. Which field holds the device flag? What is the login event called? Many fraud managers know exactly what they want to catch and still wait on someone else to express it.
In the demo, Nicki started with a sentence instead. She described the pattern she wanted: flag a customer who logs in from a device we have not seen before, changes their email or password, and moves $5,000 or more out of the account. Unit21 turned that description into a draft rule. When the request was ambiguous, the agent asked a clarifying question rather than guessing.
The draft pulled in the fields the pattern depended on. It checked for a successful login, and for the newly seen device flag on that login. Nobody had to look up a field name.
A draft rule is not a live rule, and this matters for ATO more than for most typologies. Imagine deploying a rule that accidentally holds one in ten good customers at login. So the rule goes through two stages first:
- Validation mode runs it against past data, so you can see what it would have caught and how many alerts it would have created.
- Shadow mode runs it on live activity without acting, so you see its real-world impact before any customer feels it.
The same builder works for external signals. One example from the session flagged any customer who had a hit in the Unit21 Consortium in the past 12 months, together with their risk rating. The customer may be new to you, but another institution has already seen them.
Stopping ATO in real time: deny, step up, or review
Scheduled rules are good at slow patterns, such as a dormant account that suddenly wakes up weeks before it is emptied. Most takeovers move faster than that. The fraudster knows their window is short, because the real customer will eventually notice they have been locked out. Catching those means evaluating the transaction as it happens.
The real-time rule in the demo looked at two things at once:
- The recent session. A count of logins in the past ten minutes where the device was newly seen, its time zone did not match the IP, and it was spoofing its location.
- The money. Any transaction over $1,000 in the past minute.
When both conditions were met, the rule returned a decision. That decision can be one of three responses, and choosing between them is where fraud teams protect good customers:
In every case the rule can also open an alert, so a blocked transfer still lands in front of an analyst for follow-up.
Rules can be chained into a flow. In the demo's payment flow, each incoming payment first passed through a high-risk login check. If that did not trigger, it passed to the ATO real-time rule described above. Rule evaluation in Unit21's real-time payment fraud prevention engine runs in under 150ms (as of September 2026), which leaves room for several checks before a payment decision is due.
What an AI investigation agent does before the analyst opens the alert
Detection is half the job. Every ATO alert still needs someone to decide what it means, and that work is where queues back up. Unit21's AI investigation agents pull transaction histories, assemble the evidence and draft a narrative, then present the finished investigation for a human to review.
Choosing what the agent checks
An ATO investigation agent is a set of tasks. Some come ready to use, such as:
- counterparty analysis
- prior alert activity
- how long the customer has been with you
- whether their behavior has changed over time
- mismatches between their address and where they transact
Most teams also have checks specific to their own data and procedures. Those can be built with the Agentic Task Builder, which is how most custom AI agents for fraud and AML get tailored to a team. In the demo, the prompt was as plain as this: you are an L1 analyst evaluating alerts, looking for transactions and events that might indicate an account takeover. You test a task like that against a set of real alerts before publishing it, so you can see whether it references the right data and catches what you expect. A task built for ATO can also run on other alert types where the same question applies.
Deciding how much the agent does
The agent is assigned to a queue, such as the one your fraud team works ATO alerts from. From there, autonomy grows in steps:
- The agent reviews every alert that arrives in the queue, so the work is summarized when an analyst opens it.
- It drafts a narrative in the format your team uses, and recommends whether the alert needs attention.
- Once a team is comfortable, it can close false positives on defined, low-risk alert types. Everything else still goes to an analyst.
What the analyst sees
Back to Blake. When his alert opened, the agent's recommendation was that a person needed to look at it, followed by the reasons:
- four login attempts, an email change and a password change within nine minutes, all from a new device fingerprint and a new IP address
- an attempted outbound transfer five minutes after the password change
- earlier activity in which two-factor authentication was disabled and the phone number was changed
- Tor usage on the session
Each finding links to the agent's work log, so the analyst can see how it reached that view. From there the analyst does the part that needs judgment. They can raise Blake's risk rating, look at the transactions around the same window, check the Consortium data on the alert, and look for network links, such as several accounts paying out to one shared account. Then they decide whether to block the account or release a hold.
Our AI Task Spotlight on account takeover before and after analysis shows one of these tasks being built and backtested on two real alerts.
Tuning ATO rules from how your analysts disposition alerts
Every time an analyst closes an alert as a false positive or confirms it as fraud, they record something useful about the rule that produced it. AI rule recommendations use that record. They look at alert history, rule outcomes and analyst feedback, and suggest specific changes to a rule, each backed by the alerts that support it.
For ATO, this usually means finding the conditions that keep pulling in legitimate customers. A rule might be firing on returning customers who travel often, or on one particular app release that resets device fingerprints. Tightening those conditions lowers the number of good customers who get stopped. It also gives analysts time back for the alerts that are real.
Recommendations apply to any scheduled rule, whether your team wrote it by hand or built it with the agent. Each recommendation can be simulated before it goes live, and run in shadow mode next to the current rule, so you can confirm it keeps catching what it should. Customers have seen up to 60% fewer false positives from rule recommendations (as of March 2026).
What is inbox ghosting, and how do you stop it?
Inbox ghosting is when malware on a customer's device hides or deletes the security alerts their bank sends, so the customer never sees the warning that their password or email just changed. It came up in the Q&A, and it is a difficult case because it disables one of the oldest ATO defenses: telling the customer.
Cross's answer was to stop relying on the customer to see the alert, and to catch the attack in two other places.
- On the device, during the session. Device intelligence can spot remote-control tools and tampered apps while the session is live, and score the risk before any money moves. A high score can trigger step-up authentication or end the session.
- In the behavior. Suppose the fraudster uses a clean device. The takeover still leaves a trail: a new login, a changed email, a new payee, then a fast withdrawal. Real-time rules can catch that sequence and hold the transfer, with rule evaluation running in under 150ms (as of September 2026).
Either the malware gives itself away in the session, or the fraud gives itself away in what happens next. When both are covered, the hidden alert matters much less, because the customer was never the last line of defense.
Frequently asked questions
Can AI agents make the final call on an account takeover alert?
By default, no. The investigation agent gathers the evidence, drafts the narrative and recommends an outcome, and an analyst decides. Teams can later let the agent close false positives on specific low-risk alert types, but that is a choice you make per queue, not a default.
How do you detect account takeover without adding friction for good customers?
Combine signals instead of acting on any one of them, and use step-up authentication where the evidence is suspicious but not conclusive. Test every new rule in validation and shadow mode first, so you can see how many real customers it would stop before it stops any.
Do you need device intelligence to detect account takeover?
It helps a great deal, especially for spotting spoofed locations and remote-access tools during a session. It is not the only route, though. Behavioral sequences, like a credential change followed quickly by a new payee and a large transfer, catch takeovers even on a clean device.
What is the difference between detecting and preventing account takeover?
Detection finds a takeover, often after some of the activity has happened. Prevention stops the damaging action before it completes, for example by denying a transfer or requiring step-up authentication. Real-time rules do both at once. Fraud leaders from Mercury and Treasury Prime share practical account takeover prevention tips from our Fraud Fighters Manual.
Catch the sequence before the money moves
Go back to Blake's evening, which brought a new phone, a changed email, a changed password and a transfer to a stranger. None of those needs to be unusual on its own for the pattern to be obvious once you line them up. Good account takeover fraud detection lines them up quickly enough to act. Rules catch the sequence as it forms, real-time decisions give the legitimate customer a way through, and an agent assembles the case so the analyst's time goes to judgment.
The full session recording runs about 40 minutes and includes the live build of each rule. To see how Unit21 approaches fraud prevention for banks and fintechs more broadly, or how this would work on your own data, get a demo with our team.
Gal Perelman is the Product Marketing Lead at Unit21, where she spearheads go-to-market strategies for AI-driven risk and compliance solutions. With over a decade of experience in the fintech and fraud sectors, she has led high-impact launches for products like Watchlist Screening and AI Rule Recommendations.
Previously, Gal held marketing leadership roles at Design Pickle, Sightfull, and Lusha. She holds a Master’s degree from American University and a Bachelor’s from UCLA, and is dedicated to helping banks and fintechs navigate complex regulatory landscapes through innovative technology.
