Part 0 · 2 chapters · ~20 min

Why These Surfaces Are Different

The three axes that separate a withdrawal from a settings page (irreversibility, regulation, the user's state of mind), scoring a screen to find its design budget, and the seven-state anatomy every money or identity action shares: intent, review, authorise, submit once, pending, settled, receipt.

1

Why these surfaces are different

three axes
  1. Irreversibility: who can undo it, at what cost? A profile edit: the user, instantly. A cleared transfer: nobody. A KYC rejection: a review queue, in days. The axis decides whether the action needs a review step, a cooling period, an undo window, or nothing. Most money actions sit at the far end: the UI is the last check before something that cannot be taken back.
  2. Regulation: what must be shown before (fees, rates, terms), kept (statements for years; an audit of what the user saw and agreed to), confirmed (strong customer authentication over a threshold), reported (transactions over a limit). It changes by country; the screen must know where it is.
  3. State of mind: rent money on the last day of the month; a card declined at a till; a selfie demanded by a machine; a lockout from the account that holds a salary. Anxiety narrows attention and removes tolerance: ambiguity reads as failure, a spinner reads as loss, a vague error reads as "they took my money". Design for the anxious user and the calm one is served too.
scoring, and the budget it buys
  1. Score each screen on the three axes. A transfer confirmation is high on all three and gets a review step, "this cannot be undone", an idempotent submit, a visible pending state with a reference, a receipt, and designed timeout and expiry states. A theme toggle scores zero and gets a switch.
  2. Each requirement costs design and engineering: idempotency, resumability and designed degraded states are each weeks. The score says where to spend; treating every screen the same over-designs settings and under-designs withdrawals.
what the Core Banking module built
The ledger: double-entry, idempotency keys, holds, event sourcing, reconciliation. This course is the other end of those guarantees: what the user sees, taps and trusts. Part 8 maps each one to its screen.
THREE AXES THAT MAKE A SURFACE DIFFERENT
irreversibility, regulation, and the user's state of mind, scored per screen
swipe the figure sideways, or tap expand for full screen
1/6
irreversibility
Irreversibility: a profile edit is reversible by the user in a second; a transfer to another bank is reversible by nobody once it clears; a KYC rejection is reversible by a review queue in days. The axis decides whether the action needs a confirmation step, a cooling period, an undo window, or none. Most money actions sit at the far end: the UI is the last check before something that cannot be taken back.
2

The anatomy of a money action

seven states, every time
  1. Intent: the form. Validate the input (format, known limits); resolve what the client can (the destination account's name from a lookup) so the review shows what the system understood. Validation is not authorisation.
  2. Review: everything that will happen, in the user's terms, including what they did not type: fee, rate, what the recipient receives, arrival time, the resolved counterparty, "this cannot be reversed". Nothing changes between review and submit; if a rate moves, the review re-renders and the user re-confirms. What was shown is recorded. This is the step products skip for "friction" and the one that prevents most incidents.
  3. Authorise: the proof of presence the rule requires (PIN, biometric, one-time code, passkey), scaled to amount and risk, and bound to the exact action (amount and destination in the signed payload) so a captured code cannot authorise a different transfer.
  4. Submit, once: an idempotency key minted at review time (not at click: a double-click or a retry after a timeout must reuse it); the button disabled on first click; the key kept until a terminal state; the server returns the same response for the first and the retried request. The single most important line of code on a money screen.
  5. Pending: a named state with a reference, a timestamp, what happens next and when, and what the user can do. It survives reload (fetched by reference), session expiry (visible after re-login) and the app closing (a notification on settlement). A spinner is not a pending state.
  6. Settled or failed: terminal, with a reason in words ("the receiving bank declined: account closed", never a code alone) and the money's whereabouts ("returned to your wallet").
  7. Receipt: reference, amounts, fees, parties, timestamps, the authorisation method; it exists the moment the state is terminal and is reachable from the transaction list, because the user may have closed the success screen.
the exercise, for every part
Take one money or identity screen you own and lay it against the seven states. The states it does not show are the incidents it will have. Parts 1 to 7 each take one surface through the skeleton with the specific failures that surface attracts.
THE ANATOMY OF A MONEY ACTION
intent, review, authorise, submit, pending, settled, receipt: seven states the UI must show
swipe the figure sideways, or tap expand for full screen
1/6
intent
Intent: the form. Amount, destination, purpose. Validation here is about the user's input (format, limits the client knows about); it is not the authorisation. The client resolves what it can (the destination account's name from a lookup) so the review step shows what the system understood, not what the user typed.