Notifications
Clear all
Topic starter
01/07/2026 1:57 am
TL;DR: Fraudsters exploited a race condition by opening three authenticated sessions on one account and submitting three payments at the same moment, so each transaction passed limit and balance checks in isolation, according to Transmit Security. Session-isolated controls can fail when real-time rails and concurrent contexts are combined.
NHIMG editorial — based on content published by Transmit Security: an analysis of multi-session payment fraud and the session state gap
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Transmit Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact sequence of the multi-session fraud scenario and how the timing window was exploited.
- The detection approach used to identify concurrent session behaviour before the exploit scaled.
- The control assumptions that failed in the financial institution's payment architecture.
- The fraud-operations context that explains why the issue becomes more dangerous during peak transaction periods.
👉 Read Transmit Security's analysis of the multi-session payment fraud seam →
Multi-session payment fraud: what IAM and fraud teams need to fix?
Explore further
01/07/2026 2:13 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Multi-session fraud exposes the blind spot in real-time payment controls
