Account takeover is the fraud category that most frustrates teams running transaction-level rules engines. The transaction itself often looks unremarkable -- the amount is reasonable, the card is valid, the merchant category is consistent with the account's history. The anomaly is in the session and account behavior that preceded the transaction, not in the transaction itself.
Why transaction-level signals miss ATO
A rules-based transaction fraud engine typically evaluates fields present on the authorization request: card number, billing address, transaction amount, merchant category code, IP address. These are good signals for certain fraud types -- card testing, BIN attacks, high-risk merchant categories -- but they are structurally insufficient for account takeover detection.
ATO happens at the account level before the transaction occurs. An attacker obtains credentials through a breach, a phishing campaign, or credential stuffing against a list of known email/password combinations. They log in as the legitimate user, update the shipping address or payment method, then initiate a transaction. By the time the transaction hits your authorization pipeline, the card is valid, the account exists, and the user is authenticated. The transaction-level signal says "this looks normal." The behavioral signal says "something is very wrong with this session."
The behavioral signature of ATO
Account takeover has a consistent behavioral signature that holds across fraud types and platform categories. It is detectable if you are looking at the right signals:
Login anomalies preceding the transaction. The most reliable ATO signal is a login from a device fingerprint or IP that has not been seen on this account before, particularly when followed quickly by a high-value transaction. A new device is not itself fraud -- users log in from new devices legitimately -- but a new device + same-session high-value purchase within 15 minutes is a pattern worth scoring heavily.
Credential reset activity. Password reset requests in the 24-48 hours before a transaction are a strong ATO signal. The attacker either reset the password to lock out the legitimate user or the legitimate user triggered a reset after noticing suspicious activity. Either way, the presence of a reset event in the pre-transaction window is meaningful.
Shipping address or payment method updates. Legitimate users occasionally update their stored addresses and cards. Attackers frequently update them immediately before a purchase, because the point is to redirect the goods or funds somewhere they control. An address or payment method update within the same session as a high-value purchase is a strong ATO signal on most platforms.
Session velocity anomalies. Account takeover sessions often move faster than legitimate user sessions. An attacker who has obtained credentials and wants to complete a purchase quickly will navigate directly to checkout, with minimal browsing behavior. Unusually short time-on-site before a transaction, especially on mobile where navigation is slower, is worth scoring.
Device fingerprint graph signals. A device fingerprint that has been seen on multiple distinct accounts in a short window is a strong signal. Credential stuffing attacks use automation to test many accounts, and that automation often runs from a small number of devices or device profiles. Seeing the same device fingerprint across 20 distinct accounts in an hour is not consistent with any legitimate use case.
Why your current rules engine probably misses most of this
Rules engines are built around fields that are present at transaction time. Most rules logic does not have access to session data, login history, or cross-account device graph signals -- those require state lookups that the typical rules engine infrastructure is not set up to perform in the authorization window.
More fundamentally, the above signals are most predictive in combination. A new device alone is not fraud. A new device plus a payment method update plus a high-value transaction in the same session is a very different picture. Building rules that capture multi-dimensional combinations across session and account context becomes unwieldy -- you end up with dozens of rules that overlap, conflict, and generate false positives on legitimate but unusual customer behavior.
ML models handle this better because they can learn from the joint distribution of these signals across historical data. The gradient-boosting models in Riskgrove's scoring engine evaluate session context, account history, and device graph signals simultaneously, weighting each according to how predictive it has been in historical ATO cases. The model does not need a rule written for each combination; it learns the combinations from data.
What your fraud stack actually needs
Effective ATO detection requires three things that purely transaction-level fraud engines typically do not have:
First, a session context layer. You need to know, at transaction time, what this account's session has looked like before the transaction: when the last login occurred, what device was used, whether there were any account mutations (address, payment method, contact info) in the session. This data needs to be available in real time, within the authorization window.
Second, a historical account baseline. What does a normal session look like for this account? Accounts that transact weekly from the same device and location have a different baseline than accounts that transact monthly from varying devices. Anomaly scoring that does not have a per-account baseline will produce false positives on legitimate customers who have unusual but consistent patterns.
Third, cross-account device graph signals. This is where rules engines fall down hardest. Detecting that a device fingerprint is appearing across multiple accounts requires maintaining a graph of device-to-account relationships and querying it in real time. Building and maintaining that infrastructure is significant work; it is core to what we do at Riskgrove.
If your current fraud stack does not have all three of these capabilities, it is likely missing a meaningful fraction of ATO. The symptom you will observe is a cluster of chargebacks that, when you investigate them, look like "normal" transactions -- valid card, correct merchant category, consistent amount -- where the customer reports they did not make the purchase. Those are almost always ATO.