A cardless ATM is a cash machine that lets a customer withdraw money without inserting a physical debit card. The transaction is typically initiated and authenticated through a mobile device, then completed at the ATM using a secure code, app approval, or similar digital verification step.
Expanded Definition
A cardless ATM is not a new account type or a different deposit network; it is an access method for cash withdrawal that replaces the physical card with a mobile-authenticated step. The core boundary is that the customer still relies on an ATM, an issuing bank, and transaction authorisation, but the proof of access shifts from card possession to a phone-based approval, one-time code, QR flow, or similar digital handoff.
That distinction matters because cardless access can reduce card skimming exposure while introducing a new trust chain across the mobile device, banking app, backend session, and ATM terminal. It is best understood as an authentication flow layered onto an existing payment account, not as a separate payment rail. Guidance-vs-consensus note: there is broad agreement on the user convenience and fraud-resistance benefits, but implementation details vary widely by bank, region, and ATM operator.
A common boundary mistake is treating cardless withdrawal as automatically safer. It can remove one attack surface, but it does not remove account takeover, device compromise, or session abuse risks.
Examples and Use Cases
- A customer starts a cash withdrawal in the banking app, receives an approval prompt, then enters a temporary code at the ATM to release funds.
- A bank issues a QR-based cardless withdrawal flow where the phone initiates the session and the ATM reads a short-lived token from the screen.
- A traveller uses a cardless ATM feature after a card is misplaced, allowing temporary access without waiting for card reissue.
- A bank deploys cardless ATM support for branchless customers who rely primarily on mobile banking and do not carry a physical card.
- An operator limits cardless withdrawals to enrolled devices because the mobile app becomes part of the authentication chain and must be trusted as much as the terminal.
The main trade-off is convenience versus dependency: if the phone, app, or network path is unavailable, the withdrawal path can fail even when the customer account is healthy. That operational fragility is often overlooked in customer-facing descriptions.
Security Implications
Cardless ATM changes the fraud profile rather than eliminating it. The security gain is that card cloning, magnetic stripe theft, and some skimming attacks become less useful when no physical card is presented. The security cost is that adversaries can focus on the mobile workflow, app session, temporary code, notification channel, or enrolment process.
Misunderstanding the flow can lead to weak controls around device binding, out-of-band verification, and transaction freshness. If a mobile approval can be replayed, forwarded, or socially engineered, the ATM terminal may still release cash to an unauthorised actor. If the ATM session and app session are not tightly linked, a captured code can become a reusable token rather than a one-time authorisation.
Practitioners should also watch for operational symptoms such as failed approvals, duplicate withdrawal attempts, and customer confusion when mobile and terminal states drift out of sync. Those symptoms often indicate a trust or synchronisation problem, not just a user-interface issue.
Domain and Governance Relevance
In banking and payments, cardless ATM is a customer authentication pattern with clear governance implications for identity proofing, transaction authorisation, fraud monitoring, and incident response. It shifts accountability from the plastic card lifecycle toward the mobile identity lifecycle, including device enrolment, app integrity, push approval controls, and step-up verification.
For identity teams, the important question is not whether the card is absent, but what now establishes possession and intent. If the mobile device becomes the effective authenticator, then lost-device handling, recovery workflows, and fraud escalation paths need to be defined with the same care once reserved for card replacement and PIN reset.
From an NHI perspective, the term is only indirectly related: the same design pattern of app-mediated approval can appear in machine or agent workflows, but the primary subject here is consumer banking access rather than non-human identity governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authentication Assurance Levels | Cardless ATM relies on stronger remote auth than card-only access. |
| Recommendation — Use AAL-aligned controls to match withdrawal risk to the strength of mobile authentication. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access to System Components | ATM withdrawal flows depend on strong user authentication and session assurance. |
| Recommendation — Enforce strong authentication and session controls for any cardless withdrawal path. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Cardless ATM is an identity and access control problem at the transaction boundary. |
| Recommendation — Apply PR.AC controls to verify device, user, and transaction linkage before cash release. | ||
| CIS Controls v8 | 5 — Account Management | Cardless ATM depends on secure account and device enrolment governance. |
| 6 — Access Control Management | The core risk is over-broad or weakly bound withdrawal access. | |
| Recommendation — Manage enrolment, recovery, and account lifecycle events for cardless access paths. Restrict cardless withdrawal access to approved devices and time-bound sessions. | ||
| MITRE ATT&CK | T1110 — Brute Force | Repeated code or approval attempts can be abused to guess or force access. |
| Recommendation — Monitor and rate-limit repeated authentication attempts against cardless flows. | ||
