Running a crypto ATM fleet: cash, cassettes, compliance

A crypto ATM is a cash machine that runs both ways: a customer feeds it banknotes and receives crypto, or sends crypto and collects banknotes. Running a fleet of them is a logistics business wearing a software interface. The screen quotes and confirms, but the hard parts are physical — cash sitting in cassettes, machines standing in places you are not, and an exchange happening at every cabinet that has to reconcile to the cent. Anyone who thinks of a crypto ATM as an app has looked at the easy half.

So this is a teardown of the operational half: the two subsystems inside the cabinet, the exchange at the glass, the cassettes nobody puts in a demo, the forecasting problem a fleet becomes, and the discipline of controlling and reconciling machines you cannot see.

Two machines in one cabinet

A crypto ATM is really two subsystems bolted together: a cash-handling machine — note acceptor, validator, a dispenser or recycler, and the cassettes that hold the notes — and a crypto terminal — a wallet, a network connection, and a screen that quotes and confirms. A buy runs cash to crypto: the customer inserts notes, the validator counts and stacks them, and the machine sends crypto to the customer's wallet. A sell runs crypto to cash: the customer sends crypto to the machine's address and, once the transfer confirms, the dispenser counts notes out of a cassette. Everything hard lives where those two halves meet, because notes are physical and irreversible once stacked while crypto is digital and irreversible once confirmed — and the machine must not commit either side until the other is certain.

The exchange at the glass

At each machine an exchange happens, and it is governed by the same locked-quote discipline as a counter terminal: the screen quotes a rate, holds it for the session with a countdown, and the customer transacts against that quote or the session re-quotes. Ordering is the safety model. On a buy, the machine releases crypto only after the notes are validated and stacked — not merely inserted, because a note still in the escrow throat is not yet money. On a sell, it dispenses not a single note until the incoming transfer has enough confirmations, because a dispensed note cannot be clawed back. The irreversible action always goes last, only after the other side is final. Get that order wrong and you have built a machine that gives away crypto for notes it never kept, or cash for a transfer that never landed.

Cassettes: the physical half nobody demos

Cash lives in cassettes — removable boxes of notes, typically one per denomination, that slot into the machine. A recycler can pay out the same notes it took in; a simpler dispenser draws only from cassettes an operator has loaded. Each cassette carries two numbers: the count the software believes and the count that is physically true. The operator's entire job, reduced to one sentence, is keeping those two equal. Every accepted note increments a believed count, every dispensed note decrements one, and a cash-collection visit resets it against a physical count. When the believed count and the counted count disagree at a collection, that gap is the single most important number in fleet operations — it is a miscount, a jam, or something worse, and it is found by counting, never by hoping.

Cash levels, and why a fleet is a forecasting problem

One machine is a chore; a fleet is a forecasting problem. A dispenser that runs empty turns customers away, and a note acceptor whose stacker is full stops taking cash — both are outages, and neither shows an error light a passer-by would notice, because the machine simply cannot complete the transaction the customer wanted. So the console tracks cash level per cassette per machine and turns those levels into routes: which cabinets need a fill and which need emptying, before either hits the wall. A fleet run well is mostly a cash-in-transit schedule — who drives to which cabinet, carrying how much, on what day — and the software exists to build that schedule from live levels instead of guesswork and Friday-afternoon panic.

Remote lock, and acting from a console

The machines stand in places the operator is not — a lobby, a shop floor, a station concourse — so control has to be remote. From the console an operator can lock a single machine or the whole fleet instantly, and a locked machine completes nothing new. Lock is the response to a jam, a suspected fault, a cash discrepancy, or a machine that must be frozen while someone drives out to it. Keys and cassettes stay where they are; the machine just stops transacting until a human clears it. The discipline is that dangerous actions happen from the console with a reason attached and land in a log — not by someone tapping the machine's own screen in the field, unrecorded, where no one can later reconstruct what was done or why.

A crypto ATM fleet is not a software product with some hardware attached. It is a cash-logistics operation with a screen on the front — and every number on that screen has to reconcile to a banknote you could hold in your hand.

— Protocore · Payments engineering

Reconciling a machine you cannot see

Reconciliation is the daily proof that a fleet is honest. Every session at a machine leaves a record — notes in and crypto out, or crypto in and notes out, with the locked rate, the wallet addresses, and the confirmations attached. Sum a machine's sessions since its last collection and you get the cash it should be holding; count the cassettes on the visit and you get the cash it is holding; the two must meet. The crypto side reconciles the same way, against the machine's wallet balance. A fleet that reconciles per machine, per day, catches a bad cabinet on day one — a jam, a skim, a miscount — instead of discovering it as a quarter-end hole nobody can explain. The whole point of the per-machine ledger is that it survives an audit precisely because it was never allowed to drift.

Compliance is the operator's job; the software enforces and records

The operator of a crypto ATM fleet carries the obligations. The permissions it must hold, the identity checks it must run, and the transaction limits it must honour vary by where each machine stands, and they belong to the operator — not to the box, and not to the vendor of the box. What the software does is deliberately mechanical: enforce whatever per-customer and per-day limits the operator configures, prompt for whatever identity step the operator requires at whatever threshold the operator sets, and record every note, every transfer, and every limit decision so the operator can answer for the fleet later. The machine does not decide policy; it applies the operator's policy the same way at every cabinet and writes down what happened. Getting the policy right is the operator's discipline. The software's contribution is making that policy uniform and auditable across a fleet no single person can watch all at once.

The honest boundary

A single machine in one location barely needs a fleet console — a spreadsheet and a weekly count would do. The machinery here earns its keep at fleet scale, where the numbers stop fitting in one head: cash levels across many cabinets, cassette counts that must reconcile per site, remote lock for machines hours away, and a per-machine ledger that stands up to an audit. Run one cabinet and this is overhead; run twenty and the schedule, the reconciliation, and the remote controls are the difference between a business and a pile of cabinets slowly drifting out of balance. The fleet console is at /products/atm, and the terms — cassette, recycler, reconciliation, settlement — are in the /glossary.