What happens when cardless ATM withdrawals depend on a single channel such as SMS or QR codes?

Why single-channel cardless withdrawals are brittle

Cardless ATM designs work best when the user’s presence, the transaction request, and the final dispense approval are not collapsed into one weak link. A single SMS, QR, or similar channel can become the whole control plane for the withdrawal. That makes the flow easier to use, but it also means one intercepted or redirected step can defeat the rest of the design.

The main technical weakness is that the channel is doing too much. If it carries both proof of possession and approval, the system has less room to distinguish a legitimate customer from someone who has captured the message, copied the code, or manipulated the session. In practice, the safer pattern is to separate authentication, intent confirmation, and cash dispense authority so that compromise of one step does not automatically unlock the others.

Channel choice also changes the failure mode. SMS depends on mobile network trust and device custody, while QR-based flows depend on the user scanning the correct code at the right time and from the right context. A design can be perfectly functional for ordinary use and still be fragile under interception, replay, or session substitution. That is why cardless cash withdrawal should be treated as a security-sensitive transaction flow, not just a convenience feature.

Where the control breaks down in practice

Single-channel withdrawal flows are vulnerable when attackers can hijack the same path the customer uses to prove presence or approve the transaction. For QR-based journeys, the risk often starts with a malicious or substituted code, or with a redirect that moves the customer into an attacker-controlled approval step. For SMS-based journeys, the problem is weaker trust in the delivery channel and the possibility of message interception, SIM-related abuse, or social engineering that captures the code before the ATM session is completed.

The most important design question is whether the approval step is bound tightly enough to the specific cash withdrawal request. If the channel only proves that a message was received, but not that the customer approved this exact transaction at this exact ATM, the control can drift into generic login assurance rather than transaction authorisation. That is why cross-device flow security guidance matters here: the protocol must resist consent phishing, session transfer abuse, and weak binding between the device flow and the target action.

For QR variants specifically, the security model also overlaps with phishing by image and redirect abuse. A customer can be sent a QR code that looks operationally normal while actually steering the flow into an attacker-controlled endpoint. That is why the QR Code Phishing (Quishing) Guide is relevant to this pattern: if the scan step is the trust anchor, attackers will target the scan step.

SMS also inherits the broader weakness of one-time code and approval workflows when the same channel is asked to prove identity and convey authority. If the code can be relayed, observed, or triggered outside the customer’s intended context, then the ATM does not really know whether the approving party is present. The safer pattern is to make the approval transaction-specific, time-bound, and difficult to replay, rather than assuming the delivery channel itself is enough.

What resilient cardless withdrawal design should separate

Resilient flows separate three questions: who is the customer, whether the customer intends this withdrawal, and whether the ATM may release cash. Those are not the same control. A strong design uses one factor or channel to start the session, another to confirm the transaction details, and a final policy decision to authorise dispense only when the request still matches the original context.

That separation matters because the attacker’s goal is usually to collapse the steps back into one exploitable moment. If the same code, scan, or message both authenticates the user and approves payout, the security boundary is thin. If the workflow instead binds approval to the exact amount, location, time window, and session state, the attacker has to defeat multiple checks rather than one brittle channel.

Designers should also consider whether the customer’s device is the right place to hold approval power at all. For some deployments, a stronger pattern is a dedicated authenticator app, a push approval with transaction details, or a device-bound cryptographic method rather than a transport channel that was never meant to be the sole trust anchor. The choice is less about convenience than about reducing the chance that a single compromised path can authorise cash dispense. The Authenticator Apps and OTP Guide is useful here because it shows why enrollment, backup, and migration details matter when the approval step is security-critical.

Risk and Threat Considerations

When one channel carries both proof of presence and transaction approval, the failure blast radius is larger than it looks. An intercepted, spoofed, or redirected SMS or QR flow can convert a convenience feature into a cash-out path, especially if the request is not strongly bound to the specific ATM session.

Failure mechanism: The attacker abuses the trust placed in a single approval channel, then reuses or relays that approval to satisfy both user verification and dispense authorisation.

Impact: The customer may lose funds without being physically present at the ATM, and the organisation may face disputed transactions, fraud losses, and confidence damage in the withdrawal channel.

Practitioner Guidance

What to verify: Check whether the approval message or QR step is cryptographically or session-wise bound to the exact withdrawal amount, ATM, and time window. If it is only a generic approval or a reusable code, treat the flow as materially weaker than it appears.

Decision rule: If one channel alone can approve cash dispense, raise the control bar immediately with transaction binding, shorter validity, and independent confirmation of intent. If the channel can be observed or redirected, do not rely on it as the only trust anchor for withdrawal authorisation.

Practitioner takeaway: Cardless withdrawal is safe only when the channel confirms participation, not when it is asked to carry the whole trust decision by itself.

Related resources from NHI Mgmt Group

• How should security teams defend against malicious URLs across email, SMS, and QR codes?
• How should banks implement cardless ATM withdrawals without weakening account security?
• Why do QR code ATM withdrawals reduce some fraud risks compared with magnetic stripe cards and PIN entry?
• What happens when customers use cardless ATM access on a lost or stolen phone?