The casino balance is only one number on the screen

Read the label before the amount

A casino balance, a session result and net deposits describe different things. A large number in the lobby cannot answer all three questions. To understand the screen, first identify what the number counts, the period it covers and the page that supplies its detail.

The useful design question is whether those distinctions remain visible when the interface compresses an account into a small header.

This is a document-based reading method for online-casino interfaces serving Great Britain. It uses the Gambling Commission's account and transaction standards, its balance-display guidance and its fair-terms condition. No named casino account has been inspected, and the examples are original illustrations rather than measured interface results.

They show how to read information, without recommending a deposit or a game.

The method has three fields: label, scope and supporting record. Label is the name printed beside the amount. Scope means the account, session or period that amount describes.

Supporting record is the history or explanation that lets the reader check it. If any field is missing, write unknown. Guessing from colour, position or type size defeats the purpose of the exercise.

Sources: RTS 1: Customer account information; RTS 2: Displaying transactions.

A balance needs an account context

RTS 1A requires a logged-in customer's current balance to appear on gambling and money-transfer screens in the account currency. Where displaying it on a gambling screen is impractical, easily accessible links can provide the information. The provision is about access to a defined number, rather than a prescribed position in a header.

For an interface reading, note the exact label and currency. A figure labelled wallet might be intelligible when viewed beside its account details but ambiguous when copied into a screenshot. Do not silently rename it cash available or money withdrawn.

Those are different claims. If the screen supplies a tooltip, help link or balance breakdown, record that text alongside the displayed amount.

Then consider the surrounding information hierarchy. A decorative coin icon can draw attention without explaining a balance's scope. A quieter text label may do more explanatory work.

This is a design judgement, not a measured finding about a particular site's customers. The practical test is whether another reader, given the same label and record, would know which question the amount answers.

Sources: RTS 1: Customer account information.

Deposit and bonus balances must remain distinguishable

The Commission's guidance says deposit and bonus balances should be displayed separately and prominently. It also explains that the separate pots need not appear in the in-game view if the account homepage provides them. A single in-game total therefore needs to be read with the wider account presentation before drawing a compliance conclusion.

For a hypothetical example, imagine an account page showing a £30 deposit balance and a £10 bonus balance. The arithmetic total is £40, but a header showing only £40 has removed information about the composition. Our proposed clearer presentation keeps both labels next to their amounts and supplies a route to the relevant explanation.

This is an original diagram of information architecture, not a screenshot or an approved operator design.

The point is not to interpret the bonus contract here. A reader may need a separate explanation of what applies to each pot. Felt & Form's question stops earlier: can the reader tell that there are two pots and locate the explanation without mistaking their sum for a different financial quantity?

A mathematically correct total can still be an incomplete label.

Sources: Restrictions on withdrawing deposit and deposit winnings.

Three quantities in one worked example

Take a fictional account with no bonuses, fees, transfers, pending transactions or currency changes. It opens at £0. Across its lifetime the holder deposits £100, withdraws £30 and finishes with a £45 balance.

The account's net deposits are £70: £100 minus £30. Under these deliberately simplified assumptions, its overall gambling result is minus £25: £45 minus £70.

Now suppose its latest session began with £50 and ended with £45, with no money moving into or out of the account during that session. That session's result is minus £5. We now have three valid numbers: current balance £45, lifetime net deposits £70 and latest session result minus £5.

None is an alternative spelling of either of the others.

The example's design problem is what happens when a compact display drops the period. A minus £5 labelled result might describe the session correctly while leaving a reader with the wrong impression about the whole account. Similarly, £70 beside deposits would obscure the fact that withdrawals have already been subtracted.

The fuller label net deposits, lifetime makes the calculation intelligible.

This arithmetic is a controlled example, not a reconstruction of a real customer's statement. Introduce a bonus adjustment, another product wallet or an unsettled item and the reconciliation needs more fields. The illustration's exclusions are part of its method; hiding them would make a neat diagram look more authoritative than it is.

Sources: RTS 1: Customer account information; RTS 2: Displaying transactions.

Session information belongs beside the game

RTS 2E requires casino gaming sessions to display the customer's net position since the session began; peer-to-peer poker is excluded from that provision's stated scope. The implementation guidance defines the position using winnings and losses across the session. Elsewhere RTS 2 addresses the amount committed to a gamble and the clarity of conversions between currency and credits or chips.

Those are separate display jobs. A stake control answers what the next commitment will be. A result display answers what happened in the session.

An account balance answers what the account currently holds. A screen may place all three close together, but proximity does not make them interchangeable. In an inspection note, draw a small boundary around each label and write its job underneath.

If a game uses credits, preserve the conversion shown on screen before interpreting the numeral. A large credit count should not be rewritten as pounds. This article does not test any conversion control; it identifies the explanatory relationship to look for.

The value and unit need to travel together whenever the number is copied into a note or support request.

Sources: RTS 2: Displaying transactions.

The history view supplies the missing dimension

RTS 1B calls for easy access to at least three months of account and gambling history without contacting the licensee, with a minimum of twelve months available on request. Its detail includes time-period selection and a summary total. RTS 1C separately addresses net deposits and explanation of the timeframe used.

On paper, draw the history screen as three parts: the selected period, the entries and the summary. The selected period should stay attached to any total you transcribe. A figure for this month and a lifetime figure cannot be compared as though the only difference were their font.

Record both start and end dates where shown, together with any statement about what the total includes.

For a repeatable review, use an empty observation row: page label; selected period; displayed total; explanation found; unresolved question. Leave every field blank until it has actually been observed. A missing observation is not proof that the site lacks the feature.

Equally, a promised export is not a downloaded statement. This distinction keeps an interface worksheet from turning into an invented dataset.

Sources: RTS 1: Customer account information.

Write a question that points to the ambiguity

The fair-terms condition requires accessible, transparent contractual terms and notification of material changes before they take effect. That gives context to a design review: the explanation behind an account label matters as well as the label itself. It does not mean a reviewer can decide a contract's meaning from a single isolated screen.

An effective clarification request identifies the missing relationship. For the fictional £40 total above, it might read: the account page shows £30 under deposit balance and £10 under bonus balance; which of those amounts does the header total include? For the session example, it might ask which start point the minus £5 covers.

Both questions can be answered without guessing what the user intended.

Avoid replacing the question with an accusation. A confusing presentation, a missing explanation and an incorrect calculation are three different findings. Record the observed wording first, then the consequence for understanding it.

That order helps an editor, designer or support agent reproduce the issue without having to accept the reviewer's first interpretation.

Sources: Fair and transparent terms and practices, licence condition 7.1.1; Restrictions on withdrawing deposit and deposit winnings.

Make the observation useful to the next reader

A useful balance annotation can fit in one paragraph. State where the amount appeared, reproduce its label, preserve its currency, describe the period and point to the supporting history. Add the time of the observation if it came from a live account.

Do not publish account numbers, transaction identifiers or personal financial details merely to illustrate a layout issue.

For the worked example here, the finished annotation is: £45 is the current balance; £70 is lifetime deposits less withdrawals; minus £5 is the latest session's net result. The account-wide minus £25 is our separate calculation under the stated exclusions. Giving each figure its own sentence is more informative than ranking them by visual prominence.

A well-explained interface allows the reader to connect a headline number to its constituent records. This article provides a method for judging that connection. It supplies no operator score, measured click count or claim about typical industry practice.

Those would require a defined sample and an actual inspection, with the result tied to a date, account state and specific screen.

Sources: RTS 1: Customer account information; RTS 2: Displaying transactions; Fair and transparent terms and practices, licence condition 7.1.1.