Multi-session fraud exposes the blind spot in real-time payment controls

At a glance

What this is: This is an analysis of multi-session payment fraud and its key finding: controls that evaluate each session independently can be bypassed when attackers coordinate concurrent transactions.

Why it matters: It matters to IAM, fraud, and identity teams because session state, concurrent access, and transaction authorisation are increasingly intertwined across human and machine identity programmes.

👉 Read Transmit Security's analysis of the multi-session payment fraud seam

Context

Multi-session fraud happens when the same account is used in more than one live session at the same time and the controls only see each session in isolation. In this case, the gap was not weak authentication but blind spots in session-aware authorisation and balance validation.

For identity and access teams, the lesson extends beyond payments. Any control that assumes one stable session, one request path, or one human action at a time can be defeated when concurrent activity is part of the attack pattern. That makes session correlation a governance problem, not just a fraud operations issue.

Key questions

Q: What breaks when transaction controls only evaluate one session at a time?

A: Per-session controls can approve each request as valid while missing the combined effect across concurrent sessions. That creates a race condition where an attacker can keep every individual payment under threshold but still exceed policy at the account level. The fix is shared-state authorisation that correlates all live sessions before approval.

Q: Why do instant payment rails make multi-session fraud harder to stop?

A: Instant rails compress the decision window so settlement can complete before manual review or downstream monitoring can intervene. When multiple authenticated sessions act in parallel, the system may see no single rule violation until after funds have already moved. That is why real-time correlation matters more than post-event investigation.

Q: How can security teams detect coordinated session abuse early?

A: Look for synchronized logins, repeated balance checks, and near-simultaneous submissions from the same account across multiple browser contexts. Those clustered behaviours are stronger signals than any single transaction amount. Teams should combine identity telemetry with transaction telemetry so the attack is visible before approval.

Q: Who should own controls for multi-session payment fraud?

A: Ownership should sit across IAM, fraud, and payment operations because the failure spans session state, transaction authorisation, and settlement behaviour. If those functions work separately, each may see only a fragment of the attack. Shared control ownership is the only reliable way to close the seam.

Technical breakdown

Concurrent session state and race conditions

A race condition appears when security checks depend on state that can change between evaluation and execution. Here, each browser context saw sufficient funds and an acceptable limit, because the system validated the account separately for each transaction. The flaw was not the transaction rule itself but the lack of shared state awareness across live sessions. Real-time environments make these defects easier to exploit because the attacker can compress multiple approvals into the same decision window.

Practical implication: design controls that evaluate account state across concurrent sessions before approval, not after settlement.

Why session-isolated authorisation fails on instant rails

Session-isolated authorisation assumes each authentication context is a bounded unit of risk. That assumption breaks when an attacker can create parallel sessions that each appear legitimate but collectively exceed policy. Instant payment rails intensify the problem because finality arrives before manual review can intervene. In practice, the control failure sits between identity, transaction, and payment layers, which means neither fraud rules nor pure IAM checks see the full picture on their own.

Practical implication: correlate session telemetry with transaction authorisation signals in real time.

Telemetry patterns that expose coordinated abuse

Coordinated abuse often shows up as synchronized session creation, repeated balance checks, and near-simultaneous submissions from the same identity or device pattern. Those signals matter more than any single transaction amount because the attacker’s objective is to keep each request individually plausible. The important architecture point is that detection has to look for behavioural clustering across contexts, not just threshold violations inside a single session.

Practical implication: alert on clustered session behaviour, not only on threshold breaches.

Threat narrative

Attacker objective: The attacker wanted to extract more money than a single session or transaction would normally allow by exploiting timing and session isolation.

1. Entry: the attacker opened three authenticated sessions on the same account, creating multiple legitimate-looking contexts at once.
2. Escalation: the attacker aligned three payment submissions to the exact same moment so each session passed its own limit and funds checks.
3. Impact: the system approved three payments that should have been blocked collectively, allowing funds to clear on an instant payment rail.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session-isolated authorisation is a structural blind spot, not a tuning problem. The article shows that the controls were individually correct but collectively incomplete because they evaluated each session as if no parallel context existed. That is a classic example of identity blast radius expanding through concurrency, where the account state is shared but the security decision is not. Practitioners should treat concurrent-session correlation as part of access governance, not as a fraud-only enhancement.

Real-time payment design changes the failure mode from review gap to state gap. When settlement finality arrives in milliseconds, the programme no longer fails because humans are slow. It fails because the decision model cannot reconcile multiple live contexts before authorisation completes. The relevant framework lens is Zero Trust applied to session state, where trust cannot be granted to a single context without understanding the surrounding activity. Practitioners must redesign for shared-state evaluation across the identity transaction path.

Multi-session fraud is a named concept for attacks that weaponise parallel identity contexts. The core pattern is not simple over-limit spending. It is coordinated abuse of multiple authenticated sessions so that each request remains individually valid while the aggregate action violates policy. That concept matters because it explains why traditional single-session monitoring misses the exploit. Practitioners should use the term when mapping controls that fail at the intersection of identity, session management, and payment authorisation.

This attack pattern exposes a governance assumption that one authenticated session represents one decision stream. That assumption was designed for human-paced interaction and breaks when an actor can operate multiple concurrent contexts on the same account. The implication is that session count, concurrency, and shared account state need to be governed as first-class identity signals, not treated as incidental telemetry.

The most important control boundary here sits between authorisation and settlement. The exploit succeeded because the system approved each request before it had a chance to reconcile the total effect across sessions. That is why payment teams, IAM teams, and fraud teams need a shared view of the same account state. Practitioners should align transaction controls with identity context correlation, or the attack will keep finding seams.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility.
• Read 52 NHI Breaches Analysis for the breach patterns that show how visibility gaps become exploit paths.

What this signals

Session correlation will become a mainstream identity control as payment systems and fraud platforms continue to converge. Teams that still treat session data as a logging artifact will miss the attack shape described here. The practical shift is toward shared-state authorisation, where identity signals must be evaluated across all live contexts before a transaction can be final.

Multi-session fraud is a useful named concept for board-level risk conversations. It captures a specific failure mode where individually valid actions become collectively abusive. That framing helps practitioners explain why more authentication alone does not solve the problem, and why control design has to move upward into concurrency-aware governance.

Fraud operations will increasingly depend on identity telemetry that is rich enough to identify coordinated behaviour across contexts. For IAM teams, that means the boundary between access governance and transaction fraud is narrowing, and the programme needs to be built for that overlap.

For practitioners

• Implement cross-session authorisation checks Correlate all live sessions on the same account before approving a transaction, so one context cannot be evaluated in isolation from another.
• Alert on synchronized transaction bursts Flag multiple authenticated sessions that submit approvals within the same decision window, especially when the requests share the same account, device, or IP pattern.
• Tie payment limits to shared account state Move limit enforcement to a shared state layer that sees aggregate activity across concurrent sessions rather than per-session counters.
• Test race-condition abuse during fraud exercises Include multi-session timing attacks in red-team and fraud simulations so teams can validate whether controls fail under concurrent approval pressure.

Key takeaways

• The core failure was architectural: the controls saw each session separately and missed the combined account-level effect.
• The attack succeeded because three individually valid transactions were coordinated into one impossible outcome within a millisecond-scale payment flow.
• Practitioners need shared-state authorisation and cross-session telemetry if they want to stop concurrent-context abuse before funds clear.

Key terms

• Concurrent Session Abuse: Concurrent session abuse is the use of multiple live authenticated contexts on the same identity to bypass controls that only inspect one session at a time. The key risk is that each action appears legitimate in isolation, while the combined behaviour violates policy or authorisation thresholds.
• Race Condition: A race condition is a timing flaw where security decisions depend on state that can change before the action completes. In identity and payment systems, it allows attackers to split one harmful outcome into several individually valid steps.
• Session-Aware Authorisation: Session-aware authorisation evaluates a request using the state of all relevant active contexts, not just the current login session. It is a control pattern for environments where concurrency can change the meaning of a single approved action.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Transmit Security: an analysis of multi-session payment fraud and the session state gap. Read the original.