How ATM card transactions work: operational procedures, transaction steps, and network security protocols

You insert your Card into the Card Reader, type your PIN, and $60 appears. How does money move so fast? The ATM is just a terminal, not the bank: a Display, a Card Reader, and a Cash Cartridge locked in the Vault. Your Card never carries your balance.

So where does the money actually move? Here is the shape of it. A card and ATM terminal send the request to the acquirer, then on to the card network — Visa or Mastercard — and finally to the issuer bank. The response travels back along the same chain.

We’ll follow one sixty-dollar withdrawal through this path, and we’ll look at it on three layers: the operational steps, the ISO 8583 messages, and the security that protects them — the encrypted PIN, the HSM, and the MAC. The hint for everything ahead: the ATM is only the front door. The decision lives at the issuer. First, you put your card in.

The chip sends the EMV data — account number, expiry date, and service code — and creates a one-time code called ARQC. Next, the ATM asks for your PIN. The moment you type it, the PIN is encrypted right there inside the secure terminal, using DUKPT and Triple DES, and becomes an ISO 9564 PIN block. The PIN itself never travels as clear text.

Then the terminal builds the ISO 8583 authorization request: amount sixty dollars, terminal ID, and STAN. Finally, the acquirer routes that request toward the card network. It has not reached the issuer yet. The issuer receives the ISO 8583 request and sends its response back through the same path: Issuer, Card Network, Acquirer, ATM.

Inside the issuer, the hardware security module decrypts the PIN block and verifies the PIN. It checks the balance and the daily limit, and validates the ARQC or MAC. Our $60 request passes every check, so the issuer returns an approval code. The ATM dispenses $60 and prints the receipt.

But this is only authorization. The approval says the bank will pay — it does not move the money yet. Settlement transfers the actual $60 later. Here's the part that matters: the ATM never decides.

Your issuer bank approves or declines, and your PIN stays encrypted end to end. Approval is not settlement. Start with $200 in the account. You request $60, and your daily limit has $100 left.

The issuer checks: balance at least $60, and limit at least $60. Both are true, so the network approves. After approval, the available balance is $140. But if the limit were only $50, it would decline, even with $200.

Quick tip: limits are separate from your balance. The $60 is authorized now, and settled later. Here's what happens with a wrong PIN. Attempt one wrong: issuer counter goes to one, ATM says retry.

Attempt two wrong: counter two, still retry. Attempt three wrong: issuer declines and blocks the card. That counter lives at the issuer, not on the card — so even a cloned card fails. Three tries is a security protocol, not an ATM quirk.

Same event, two useful maps. On the left, follow the message: PIN block, ARQC, ISO 8583. That's the lens for debugging security and message formats. On the right, follow the money: cardholder, ATM and acquirer, card network, then issuer.

The same four-party flow as a shop purchase. Use it for authorization, clearing, settlement, fees and chargebacks. If the issuer is offline, the network can stand in and approve on its behalf. Two lenses, one event.

Here's the whole map. Your card and the ATM send an encrypted PIN and an ISO 8583 request to the acquirer, then to the card network, and on to your bank. The bank decides. If it approves, sixty dollars leaves the ATM now, and the settlement happens later.

Approval is not settlement. The ATM asks; the bank decides.