Use session-level monitoring that looks for device drift, abnormal payment behaviour, recovery abuse, and unusual transaction sequencing. The goal is to catch when a legitimate account begins behaving like an impersonated or hijacked identity after the initial login has already succeeded.
What ongoing-use fraud detection is really watching for
Fraud during ongoing account use is not the same problem as fraud at sign-up. The account has already passed an initial trust point, so the signal comes from how the session behaves over time. Strong detection looks for drift in device characteristics, payment patterns, recovery activity, and transaction order, because those changes often reveal an impersonated or hijacked account in motion.
That means the core question is not whether the login was valid, but whether the post-login behaviour still matches the account’s normal operating profile. A legitimate user can change devices or travel, so the goal is to spot inconsistent combinations of signals, not to block every unusual action.
Good programs treat session telemetry as part of identity monitoring, not just fraud operations. Account use should be evaluated as a sequence of actions, because fraud often becomes visible only after the first authenticated step has succeeded.
Signals that matter after the login succeeds
Useful detection usually combines several weak signals into a stronger picture. Device drift matters when a stable account suddenly appears from a new browser, fingerprint, network, or geography without a matching user explanation. Payment behaviour matters when amounts, payees, timing, or funding sources diverge from historical patterns in a way that suggests monetisation rather than normal use.
Recovery abuse is especially important because attackers often use password reset, email change, or phone change flows to lock out the real user. Unusual transaction sequencing is another strong indicator when actions occur in an order that does not match the account’s ordinary lifecycle, such as rapid profile changes followed by payment updates and then high-value transfers.
Session monitoring should also look for combinations that are individually ambiguous but collectively suspicious. For example, a small device change may be normal, but a device change plus a recovery attempt plus a new beneficiary can be enough to justify step-up review or session interruption.
How to separate normal customer variation from active abuse
The practical challenge is reducing false positives without weakening detection. Organisations should baseline normal behaviour by cohort, channel, and account age, then compare ongoing activity against that baseline rather than against a single global rule. New users, high-value accounts, and accounts that frequently switch devices should not be treated exactly the same.
Risk-based thresholds work better than binary rules when the account has legitimate movement. A travel-related IP change may be acceptable on its own, but a travel-related change combined with a newly added payee and an attempted recovery event is materially different. The best detection logic weights the pattern and the timing of events, not just the presence of one anomaly.
Practitioners should also remember that fraud detection and customer friction are linked. If step-up challenges are too aggressive, users abandon the flow; if they are too weak, the attacker keeps control. The objective is to interrupt suspicious account use at the moment behaviour stops looking like the legitimate user’s normal path.
Risk and Threat Considerations
Once an attacker has a valid session, the main risk is that the account looks trusted even while it is being repurposed. That creates a blind spot where abuse can continue long enough to move money, change recovery controls, or establish persistence inside the account.
Failure mechanism: Weak session-level monitoring misses the transition from normal use to account takeover, especially when the attacker imitates routine behaviour and only changes one or two attributes at a time.
Impact: The organisation may detect the compromise only after funds are moved, recovery channels are replaced, or the legitimate user is fully locked out, which increases loss, remediation cost, and dispute volume.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Ongoing-use fraud abuses legitimate account flows after login. |
| Recommendation — Monitor and restrict high-risk account flows that move value or change control. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | Session-level monitoring is the core detection control in this topic. |
| Recommendation — Monitor authenticated sessions for anomalous device, recovery, and transaction patterns. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Fraud detection depends on usable logs across identity and transaction events. |
| Recommendation — Centralize and review account, session, and transaction logs for suspicious sequencing. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Post-login fraud detection requires analysis of logged behaviour and correlations. |
| IA-5 — Authenticator Management | Recovery abuse and session takeover often exploit weak authenticator lifecycle controls. | |
| Recommendation — Correlate session, recovery, and payment events and escalate suspicious chains. Protect and tightly govern authenticators, resets, and replacement events. | ||
Practitioner Guidance
What to prioritise: Focus first on events that can change control of the account, especially recovery resets, payment instrument changes, new beneficiaries, and rapid changes in contact data. Those actions matter more than low-value anomalies because they often mark the point where an attacker can persist.
What to verify: Confirm that your monitoring can correlate session behaviour across identity, device, and transaction layers. If fraud review only sees payment events in isolation, it will miss the sequence that makes the behaviour suspicious.
What good looks like: A strong program can tell the difference between a legitimately mobile customer and a session that is drifting into takeover behaviour, then escalate only when the pattern becomes coherent enough to justify friction or containment.
Practitioner takeaway: Detecting ongoing-use fraud is mostly a sequencing problem, so the highest-value control is the one that recognizes when a trusted session stops behaving like the account owner and starts behaving like an operator of the account.
Related resources from NHI Mgmt Group
- How should organisations detect fraud rings before they turn into larger account takeover and payment fraud campaigns?
- What happens when organisations do not detect VPN use in fraud-sensitive workflows?
- How should fraud teams use attack rate monitoring during account opening?
- How should fraud teams handle identity theft risk when customers use the right personal details but a different phone number during account opening?