The 2FA prompt expires in 90 seconds, the withdrawal window stays open

Most withdrawal systems at licensed operators time out a 2FA challenge at 60 to 120 seconds — 90 is the common default — while the withdrawal request itself can sit in a pending queue for anywhere from 1 hour to 72 hours. Those two clocks are unrelated, and that gap is where a specific, under-discussed class of account takeover happens. The code expires; the money doesn't move.

That asymmetry isn't a design flaw in the 2FA itself. It's a design flaw in how the two timers were specified, probably by different teams, at different times, for different reasons.

Why the 90-second clock exists at all

The expiry on a one-time code is a security control, and a reasonable one. A 6-digit TOTP or SMS code has a million possible values, but an attacker who can guess freely against a live challenge doesn't need to beat a million-to-one — they need to beat the rate limit. Short expiry windows shrink the attack surface: the code you intercepted via SIM swap or a compromised email inbox is worthless if you can't use it inside 90 seconds.

Regulators rarely mandate a specific number. What they mandate is "timely" or "reasonable" expiry, which compliance teams translate into whatever the vendor ships by default. And vendors ship 60, 90, or 120 seconds because those are the numbers baked into the reference implementations of TOTP (RFC 6238 suggests a 30-second step with a one-step drift tolerance, so 60–90 seconds is the practical ceiling). It's a standard, not a strategy.

So the 90 seconds is defensible. The problem is what happens on the other side of the prompt.

The withdrawal queue has no such discipline

Here's where it gets interesting. That 90-second prompt authenticates the request. It does not authenticate the execution.

At a typical operator, a withdrawal request enters a pending state for manual or semi-automated review. That window is not 90 seconds. It's commonly:

• Instant-to-15 minutes at crypto-native books with automated risk scoring
• 2 to 24 hours at most licensed sportsbooks and casinos during business hours
• 24 to 72 hours at operators that batch-process, or where the request lands on a Friday afternoon
• Indefinite if the account is flagged for source-of-funds review

During that entire window, the account is live. The user can log in, change the withdrawal method, cancel and re-request, or adjust the amount. In many back-office setups, a support agent can also modify the pending transaction — that's the whole point of "we may reverse or hold withdrawals for verification."

None of those actions typically require a fresh 2FA challenge, because the account is already "authenticated" from the session that created the request.

The session is the weak link, not the code

If an attacker has an active session — stolen cookie, malware on the device, a shared computer the user forgot to log out of — they don't need to defeat the 90-second code at all. They can simply cancel and re-request the withdrawal to their own wallet address, or wait for the pending one and change the destination. The 2FA prompt already passed, minutes or hours ago, for the legitimate request.

Some operators do re-prompt on withdrawal-method change. Many don't. There's no industry-wide standard here, and the ones that do it often apply it inconsistently — a fresh challenge on adding a new bank account, none on switching a pending crypto withdrawal to a different address.

The numbers that matter

A 2023 analysis by a European anti-fraud vendor put account-takeover losses in iGaming at roughly 0.4% of Gross Gaming Revenue for affected operators — small in percentage terms, brutal in absolute terms for anyone running eight-figure GGR. More relevant: the median time between an account compromise and the first fraudulent withdrawal attempt was under 6 hours, which fits neatly inside a 24-hour pending window.

That's the shape of the problem. The attacker doesn't need speed. The system gives them a day.

What actually closes the gap

If you're evaluating an operator — or building one — these are the questions that separate a real control from a checkbox:

1. Does a change to a pending withdrawal's destination trigger a fresh 2FA challenge? It should, every time, regardless of session age.
2. Is the pending window capped, and is the cap enforced? "Up to 72 hours" is not a cap. "Reviewed within 4 hours or auto-approved" is.
3. Can support agents modify a pending transaction without a second authorization? At most well-run operators, no. At many, yes.
4. Is there a cooling-off period after a withdrawal-method change? A 24-hour hold on new destinations kills most of this attack class outright, at the cost of some friction for legit users.
5. Does the user get notified of the 2FA event itself, not just the withdrawal? An email or push saying "a withdrawal was requested, code sent" is the single cheapest intervention available.

For players, the practical takeaway is narrower: log out of casino sessions on shared devices, don't reuse passwords across gambling accounts, and if your operator lets you lock withdrawal destinations to a whitelist, use it. If they don't offer that, that's information.

Where the responsibility actually sits

There's a version of this argument where the operator is at fault for not re-prompting, and a version where the user is at fault for reusing a password from a 2019 breach. Both are true and neither is useful.

The more interesting question is regulatory. Licensing regimes in Malta, the UK, and several US states have spent the last five years tightening KYC and source-of-funds rules — the withdrawal destination is now heavily scrutinized for money-laundering purposes. But that scrutiny is about where the money goes, not who authorized it going there. Account takeover sits in the seam between the AML team and the security team, and in most org charts, nobody owns the seam.

That's the part worth watching. As more jurisdictions require "strong customer authentication" for payment transactions — the EU's PSD2 model, which already mandates dynamic linking between the authentication and the specific amount and payee — the 90-second code stops being sufficient. PSD2's dynamic linking requirement means the challenge has to be bound to that transaction, that amount, that destination. A generic login-time 2FA doesn't satisfy it, and a pending withdrawal that can be edited afterward certainly doesn't.

The 90-second prompt was never the vulnerability. The open window behind it is.

So: when your operator's next compliance review asks whether withdrawal authentication meets the dynamic-linking standard, what happens to the 72-hour queue?