What is ATM cash deposit testing?

ATM cash deposit testing verifies that an automated teller machine (ATM) accepts a cash deposit, counts and records it correctly, and sends the right transaction and cash-position updates to the bank's systems. It checks the customer journey and the connected software, including how the ATM handles errors, interruptions and deposits that need review. Expected posting and funds availability depend on the bank's rules.

What ATM cash deposit testing covers

The scope depends on the ATM's deposit method. A cash-accepting machine may identify and count notes before confirming the amount; an envelope deposit may require later processing and verification. Tests should reflect the actual device, transaction flow and account rules rather than assume every deposit is credited in the same way.

A typical end-to-end flow includes card and customer authentication, account selection, cash acceptance, amount display and confirmation, transaction authorisation, account posting or pending status, and receipt generation. Testing also checks communication between the ATM, its transaction switch and the core banking system. Cash-management and reconciliation systems may be in scope where the deposit flow updates their records.

The expected outcome should specify the transaction status, account balance treatment, reference number and any customer message. Some banks make deposited funds available immediately; others apply a hold or wait for verification. Testers should confirm the required behaviour against approved business rules.

Conditions and failure cases to test

Use a controlled test environment with a test ATM or simulator, test cards and accounts, and authorised test cash or representative device inputs. Define expected results for each account type and deposit method. Where physical notes are used, follow the bank's procedures for custody, counting and reconciliation. Avoid live customer accounts and production cash unless an approved operational test explicitly permits them.

Include valid deposits and boundary or exception cases. Examples include a rejected or unreadable note, a count that differs from the amount the customer confirms, an unsupported account, a deposit limit breach, a full cash cassette, and a network timeout after cash acceptance. Check whether the machine returns or retains the cash, what status the transaction receives, and whether the customer gets a clear message or receipt. The required response varies by ATM design and bank policy.

Test interruptions at different points in the flow. If a connection drops after the machine accepts notes, the system must avoid losing the deposit or crediting it twice when the ATM retries. Verify transaction identifiers, retry behaviour, reversal or recovery handling, and reconciliation records. Review audit logs and interface messages alongside the screen output, since a successful customer message alone does not prove that downstream records are consistent.

Practical test example

For a cash-accepting ATM, prepare an eligible test account and a test deposit within its configured limits. Insert notes whose accepted value is known, confirm the displayed total, and complete the transaction. Verify that the ATM records the confirmed amount, returns a transaction reference and produces the expected receipt. Then check the account's transaction history and balance state against the defined posting rules, and confirm that the ATM and banking records agree.

Repeat with a controlled interruption after cash acceptance but before the ATM receives the final response. After recovery, check that the deposit has one valid outcome: a correctly recorded credit, or the bank's specified exception state with a traceable resolution. Compare the ATM journal, switch record, core banking entry and reconciliation data where those systems are available in the test scope.

How to judge the result

A deposit test passes when the physical or simulated cash outcome, transaction status, customer-facing information and relevant banking records match the agreed requirements. An unexplained difference in note count, account posting, duplicate handling or audit evidence should be investigated as a defect or operational risk. Link test cases to deposit rules and interface requirements so that changes to limits, posting logic or ATM software can be assessed during regression testing.