ATM Design: When Software Must Agree with a Physical Machine

₹10,000, a monsoon storm, and a blinking screen

Mr. Iyer withdraws ₹10,000 at the village ATM during a storm. The notes come out. At that same second, lightning knocks out the mobile tower the ATM uses to reach the bank. The screen freezes on "Please wait..." He walks home holding the cash, not sure whether his account was debited. (Mr. Iyer, the bank, Leela and every number here are made up for teaching.)

Leela is an engineer on the bank's ATM team. Her design has to answer a question that most software never faces:

A printer can repeat a page. A cash machine must not repeat cash.

An ATM connects an account system to physical hardware. A "dispense" message can reach the machine even when the machine's reply never reaches the server, and once cash is in someone's hand, no database rollback can bring it back. The answer is a combination of four things:

• durable transaction identity,
• hardware evidence,
• controlled state transitions,
• reconciliation.

This is a conceptual architecture lesson. It isn't a complete bank-network protocol, a certified device implementation, or a guide to operating banking infrastructure.

In 30 seconds, as an architect would frame it: "The bank owns balances and authorisation, and the terminal owns the device and its local evidence. Every withdrawal gets one transaction ID, persisted before anything happens. The terminal journals each step: intent, authorised, dispense commanded, sensor result. Every message to the bank reuses the same ID, so retries are deduplicated. When the physical outcome is unknown, the system stops and reconciles the terminal journal against the bank ledger. It never re-dispenses to 'try again'."

1. The boundary: who owns what

In scope: card-and-PIN authentication, balance inquiry, withdrawal, deposit intake and transfer requests.

• The bank owns account balances and authorisation.
• The terminal owns device control, local transaction evidence and the customer session.

Deposits may stay pending until verification: an accepted envelope or cheque isn't spendable money yet. Cash in the machine is separate from funds in the account.

The rules:

• One logical withdrawal has one durable transaction ID.
• A retry must not create another debit, or another dispense attempt, without first resolving the first one.
• Money values carry a currency and use fixed precision.
• A missing response is an unknown outcome, not proof of failure.
• Customer secrets don't belong in ordinary application objects or logs.

The smallest design: the terminal asks the bank