How ATM Networks Actually Work

An ATM withdrawal looks like a small local operation. A customer inserts a card in Athens, enters a PIN, chooses €80, waits for cash, and walks away. The machine looks like the bank. In many deployments it is only the visible endpoint of a distributed payment system.

Behind that screen sits a chain of specialised components: terminal software, encrypted PIN handling, an acquirer switch, sometimes an interbank network, the issuer authorisation stack, the dispenser controller, journal storage, reconciliation feeds, and later settlement files. Each component owns a narrow part of the problem because no single system can safely own customer authentication, cash inventory, card routing, money movement, dispute evidence, and interbank obligations at the same time.

This article explains ATM networks from the inside. It focuses on message paths, state transitions, failure handling, idempotency, reconciliation, and the operational controls that keep the system correct when networks, devices, hosts, and files do not behave cleanly.

The ATM Is A Payment Terminal Attached To Cash Hardware

An ATM is not just a screen with a cash drawer. It is a payment terminal married to physical devices that can capture cards, count notes, reject notes, print receipts, and record what happened at each step. The software has to coordinate the banking protocol with motors, sensors, shutters, and note-present timing.

That combination makes ATM design harder than ordinary card acceptance. A card purchase usually ends when the issuer approves or declines. An ATM can still fail after approval because the dispenser jams, the shutter does not open, the customer never takes the notes, or the machine loses power halfway through the sequence. The network therefore has to model both financial state and physical state, and it has to keep enough evidence to repair any mismatch between them.

The Acquirer Side Owns The Terminal And The Cash Estate

The acquirer side usually owns the machine, the terminal estate, the host connection, and the cash operations around replenishment and balancing. Even when the card belongs to another bank, the acquirer decides which host the ATM talks to, which message format the terminal uses, how journals are uploaded, and how local faults are handled.

In practice this means the acquirer switch is the first serious decision point. It validates terminal identity, checks whether the machine is in service, applies routing rules, enriches the request with terminal metadata, and decides whether the transaction is on-us or needs to go to a domestic switch, a scheme network, or another processor. The acquirer also owns a large part of the operational evidence, because only it sees the terminal state, the cassette counters, and the local journal before any issuer response comes back.

The Issuer Side Owns The Cardholder Decision

The issuer side decides whether the cardholder should be allowed to withdraw cash. It sees the account, the card status, the PIN result, the available balance, daily limits, fraud signals, country controls, and any temporary restrictions on the customer profile.

That decision is separate from terminal ownership. A machine in Lisbon may belong to one bank, route through a domestic network, and still rely on an issuer in Frankfurt to say yes or no. The issuer therefore answers the financial question, while the acquirer and terminal still have to answer the physical one: did the machine actually deliver the money that was just approved?

PIN Verification Depends On HSM Boundaries

PIN handling is one of the oldest places where ATM design becomes security-critical. The terminal never sends a plain PIN through the network. It encrypts the PIN inside a secure PIN entry device and sends a PIN block under keys managed by hardware security modules, or HSMs.

Depending on the network and issuer setup, PIN verification may happen in the issuer HSM, in a shared network service, or through offset-based verification using stored PIN verification values. The important operational fact is that ATM traffic crosses a hard cryptographic boundary here. If key management is wrong, the system does not become merely inconvenient. It becomes unsafe to run.

ATM Authorisation Is A Real-Time Risk Decision

An ATM withdrawal request usually travels under a tight latency budget. The customer is standing in front of a machine waiting for cash, so the issuer cannot disappear into batch logic or slow reconciliation queries. The authorisation path is built for fast checks against balances, velocity limits, card status, regional restrictions, and risk models.

A simplified path often looks like this:

ATM
  -> acquirer switch
  -> domestic or scheme network
  -> issuer processor
  -> issuer ledger and fraud controls
  -> response back through the same chain

The approval is usually permission to continue, not proof that the machine has already paid out. Mature systems keep that distinction explicit because cash dispense can still fail after the issuer says yes.

The Dispenser Is A Physical State Machine

Once the host tells the terminal to continue, the ATM moves into a sequence that looks more like industrial control than web software. The dispenser selects notes from specific cassettes, counts them, validates them through sensors, moves them to a present position, opens the shutter, waits for customer take, and then decides whether to retract any untaken notes.

Those steps matter because each one changes the repair story. A transaction approved but never dispensed is one class of problem. A transaction partly dispensed and partly rejected to the purge bin is another. A transaction fully dispensed but never acknowledged upstream is another again. The network cannot collapse these into one generic failure without creating customer harm later.

Cash Cassettes Turn Accounting Into Inventory Control

ATMs do not only move balances. They also manage physical inventory. Each cassette has a denomination, a loaded count, reject behaviour, low-cash thresholds, and an expected remaining stock after each withdrawal. Replenishment crews and balancing teams later compare those expectations with what they physically count.

This is why ATM accounting often feels halfway between payments and warehouse control. If a machine starts the day with 2,000 notes of €20 and 1,000 notes of €50, the host should be able to explain why those counts changed, which withdrawals consumed them, how many notes went to reject, and whether any cassette totals drift from the electronic record. A mismatch is not just a device problem. It can become a customer dispute or a loss event.

Electronic Journals Are Evidence, Not Decoration

The electronic journal is one of the most important ATM records. It captures terminal events such as card inserted, PIN tries, menu choices, amount selected, host response, dispense start, notes presented, notes taken, retract event, receipt printed, or terminal fault. Good journals are timestamped, sequence-aware, and linked back to stable transaction references.

When a customer says, "My account was debited but the machine gave me nothing," the journal is often the first place investigators look. It does not settle the case on its own, but it provides the local narrative that ledger postings and network messages cannot. Without the journal, operations teams are forced to infer physical events from financial records that were never designed to describe motor behaviour.

Partial Dispense Creates The Hardest Customer Cases

Partial dispense is one of the nastiest ATM failure modes. Suppose the issuer approves €80 and the machine intends to present four €20 notes. During note transport, one note is detected as malformed and diverted to reject. The customer receives €60. The host may already have an approval and a terminal success path in motion unless the dispenser state is propagated correctly.

This is why ATM protocols usually include advice and reversal paths in addition to the request-response pair. The final financial outcome cannot be trusted until the machine reports what happened with the notes. Operations then need enough data to tell whether the customer should see a full debit, a reduced debit, or no debit at all.

Reversals Repair Authorisations That Did Not Become Cash

A reversal says, in effect, "the earlier approval should not stand as originally authorised." In ATM flows this often happens because the terminal timed out, the dispenser failed, the cardholder cancelled before cash presentation, or the machine retracted untaken notes.

The timing matters. A prompt reversal can release the customer's available balance quickly and keep the issuer ledger clean. A delayed or missing reversal leaves the customer staring at a debit or hold that no longer reflects reality. ATM systems therefore treat reversal generation and delivery as core correctness work, not as optional housekeeping.

Timeouts Create Uncertain Financial State

A timeout does not mean the withdrawal failed. It means one participant stopped hearing from another before the story was complete. The issuer may have approved and logged the transaction while the acquirer lost the response. The ATM may have dispensed cash while the host lost the completion advice. The customer may walk away before either side agrees on the final state.

This is why mature ATM systems keep explicit uncertainty states. They need to answer questions such as: was the request received, was it forwarded, was it approved, did the terminal acknowledge, did the notes leave the cassette, did a reversal arrive, and has reconciliation closed the case? Flattening all of that into "error" makes later repair much harder.

A practical duplicate guard uses the business key first and transport metadata second:

if command_key exists and final_response is known:
    return stored final_response
if command_key exists and outcome is uncertain:
    attach retry to existing investigation state
otherwise:
    create command record and process once

This is not glamorous code, but it is central to financial correctness. Many severe incidents begin when a retry is treated as a new business instruction because the first attempt disappeared from the caller's point of view.

Fees And Surcharges Are Part Of The Message Contract

ATM withdrawals often carry more than the requested cash amount. There may be an issuer fee, an acquirer surcharge, a foreign usage fee, or a dynamic currency conversion path that changes what the customer sees before authorisation. Those amounts must be represented consistently across screen prompts, authorisation data, receipts, customer statements, and later settlement.

If the customer selects €80 and accepts a €2 surcharge, the network must preserve whether the issuer authorised €80, €82, or separate financial components with different reporting rules. When these details are muddled, disputes become harder because the customer, the ATM owner, and the issuer may all be looking at different number sets.

On-Us And Foreign Withdrawals Behave Differently

An on-us withdrawal, where the ATM owner and the card issuer are the same bank, can be relatively direct. The acquirer and issuer logic may sit inside the same institution, use the same customer reference model, and reconcile against internal ledgers.

A foreign withdrawal adds more participants and more delay. The ATM owner may send the request through a domestic switch or a card scheme. The issuer may approve in one currency while settlement later happens in another. Disputes, fees, and reversals now cross institutional boundaries. The customer experience may still look simple, but the repair path is slower because no one participant owns the whole story.

Settlement Is Separate From Cash Movement

Cash movement at the machine and settlement between institutions happen on different timelines. The customer can receive notes immediately, while the interbank obligation created by that withdrawal may settle later through scheme files, bilateral positions, or central bank processes.

That separation explains why an ATM system needs clearing accounts and settlement controls in addition to terminal logic. The local machine can be perfectly correct and the interbank books can still be wrong if settlement references do not match, files arrive late, or a network participant posts the wrong amount downstream.

Reconciliation Joins Host Logs To Physical Counts

ATM reconciliation sits at the junction of payments and hardware operations. Teams compare issuer and acquirer records, switch reports, electronic journals, reversal feeds, settlement files, and physical cassette counts. A clean withdrawal is one where those sources tell the same story within acceptable timing windows.

A dirty case might look like this: the issuer approved €80, the ATM journal says dispense started, the customer claims no cash arrived, the cassette total is short by three notes, and the reversal file never came. Reconciliation turns that confusion into classified work items instead of leaving it as an anecdote in a support queue.

Fraud Controls Watch Both Cards And Machines

ATM fraud is not only stolen cards and guessed PINs. It also includes skimming devices, cash trapping, malware on the terminal, jackpotting, mule withdrawals, rogue maintenance access, and suspicious machine behaviour that suggests local compromise.

For that reason fraud controls monitor both sides of the system. The issuer watches cardholder patterns such as impossible travel, repeated PIN failures, and rapid cash-out behaviour. The acquirer watches terminal patterns such as unusual dispense velocity, out-of-hours cabinet access, communication changes, or software integrity alarms. A safe ATM network treats the machine itself as a risk subject, not just a trusted endpoint.

Remote Monitoring Turns Device Health Into Payment Risk

Remote monitoring platforms watch cassettes, printer paper, shutter faults, card reader status, network reachability, safe door sensors, temperature, and software health. On the surface that looks like routine device management. In practice it is payment-risk management.

A machine with a flaky note sensor or an unstable network link is more likely to create partial dispenses, orphaned reversals, and customer disputes. This is why operational teams care about hardware alarms long before customers start complaining. Poor device health eventually shows up as financial exceptions.

Testing ATM Networks Requires Physical Failure Cases

A purely logical test suite is not enough for ATM systems. Teams need scenarios where the issuer approves but the ATM loses connectivity, where the dispenser jams after note selection, where the customer leaves notes in the tray, where a reversal arrives late, and where the same request is replayed after an uncertain timeout.

Those tests are uncomfortable because they force the system into the states that cause real losses. They are also the only way to prove that ledger state, customer-visible state, terminal evidence, and reconciliation state stay aligned under pressure.

Incident Recovery Starts With The Journal

When a serious ATM incident lands, operations usually begin with stable references and terminal evidence. They pull the transaction key, journal lines, switch trace, host response, reversal status, cassette counts, and any settlement or dispute links that followed.

The goal is not to retell the transaction poetically. It is to answer a small set of hard questions quickly: did the issuer approve, did cash leave the machine, did the customer receive it, what did the machine record, what did later files confirm, and which correcting entry is now justified? Teams that can answer those questions fast contain losses and support pain. Teams that cannot usually end up with manual archaeology across several systems.

The Smallest Useful Mental Model

The cleanest way to think about ATM networking is to separate four concerns:

1. who authenticated and authorised the cardholder,
2. what the machine physically did with the notes,
3. what accounting state each institution recorded,
4. what later evidence confirmed or repaired the result.

Any architecture that blurs those four concerns will work on an easy day and fail expensively on a bad one.

Final Operational Checklist

A production implementation should be able to answer these questions without manual archaeology:

• What stable reference identifies the business event?
• Which participant received each message?
• Which system was allowed to change money state?
• Which retries were suppressed or replayed?
• Which timeout states remain unresolved?
• Which reversal, advice, clearing, settlement, or report later confirmed the outcome?
• Which customer-facing balance or status was shown at each stage?
• Which evidence can be used during a dispute or regulator review?

If those answers are not available, the system may still process normal traffic, but it cannot be trusted during the cases that matter most. Banking systems are judged by the repair path as much as by the approval path.