A customer's app shows one balance and the ATM shows another. How should available balance be defined?

Two numbers, two different claims about reality

The ledger balance, also called the book or posted balance, is the sum of the entries that have actually posted to the account. It is a statement about history and it is provable from the entries themselves. The available balance is a statement about the future: how much of that money the customer may commit right now without the bank taking a risk it has not agreed to take.

Because the second is a forward-looking judgement, it is not derived from the ledger alone. It is the posted balance, less amounts committed but not yet posted, less amounts posted but not yet usable, less amounts the bank is legally obliged to hold back, plus any credit facility the customer is entitled to draw on. Each of those four adjustments has a different owner and a different set of rules, which is exactly why channels drift apart when each computes its own version.

The adjustments, and where each comes from

Committed but not posted is mostly card authorisations. A tap or an online purchase creates an authorisation that reserves funds without moving them; the movement happens later when the transaction is presented for settlement. Some categories authorise an estimate and then settle a different amount — fuel pumps, hotels and car hire are the classic cases, sometimes with incremental top-ups during the stay. A payment instruction you have accepted but not yet released to the rail behaves the same way, and so does a scheduled standing order due today.

Posted but not usable is the uncleared-funds problem. A cheque deposit or an inbound debit that carries a return right is on the books, but the bank may reverse it, so the funds are made available on a schedule the bank sets. How large this bucket is varies enormously by market: where cheques are still common the float is a visible part of the customer experience, and where domestic transfers are instant and irrevocable it has all but disappeared, which changes what customers expect of the number.

Legally held back means earmarks and liens: a court order, a garnishment, a regulatory freeze, a security interest against a loan, or a pledged deposit. These are not risk decisions and they do not expire because a timer ran out. They must be modelled separately from operational holds precisely because releasing one in error has consequences an expired card authorisation does not.

Available credit is the arranged overdraft or the unarranged tolerance the bank is prepared to allow. Whether this is included in the displayed figure is a product and conduct decision rather than a technical one, and in several markets how it is presented is itself regulated, because showing a customer a number that includes borrowing they will pay for is a fairness question.

Model holds as records, not as a running total

The design that fails is a single mutable available_balance column that every process increments and decrements. It cannot be explained, it cannot be rebuilt, and the first crash between two updates leaves a number nobody can reconcile.

Hold each reservation as its own row: the account, the amount, the currency, the reason code, the originating reference, when it was created, and when it expires. Available balance is then a query — posted balance from the entries, minus the sum of live holds, minus unavailable value-dated credits, plus the facility limit. It is reproducible, it is explainable line by line to a complaint handler, and an expiry is a property of the data rather than a job that must remember to run.

The awkward part is the join between a hold and the posting that supersedes it. The settled amount arrives with a reference that should let you find the authorisation, release it, and post the real movement in one transaction. When the reference is missing or the amounts differ, you need a stated rule: match within a tolerance and a window, release the hold, post the settled figure, and record that the match was inexact. Release the hold without linking it and you will double-count; post without releasing and the customer's money stays reserved twice.

The failure this question is really testing for

Interviewers ask this because the symptom is common and the cause is almost always architectural: availability logic implemented independently in the mobile app, the card authorisation path, the branch teller screen and the batch that decides whether a direct debit bounces. Each was written by a different team, each rounds a different way and treats a different hold class as live, and the customer sees the disagreement. There is no amount of testing that fixes four implementations of one rule.

One service owns the definition, every channel asks it, and the answer comes back with its components rather than as a bare figure — this much posted, this much held for these reasons, this much of your overdraft. That decomposition is not a debugging convenience; it is what lets a branch employee answer "where is my money" in one sentence instead of escalating.