Responsible gambling UX requirements define how a player finds, understands and uses protective controls—and how the product proves those controls took effect. A visible button is not enough. Limit settings, time-outs, self-exclusion and support access need unambiguous labels, predictable outcomes and dependable enforcement across the account.
Quick answer: Start with a jurisdiction-specific rules register. Provide clear routes to help and account controls. Explain what each limit measures and when it applies. Treat lower limits, time-outs and exclusions as protection requests, not retention moments. Confirm activation from the server, handle failed requests safely, and test every state with compliance and support teams before release.
This is a product specification template, not legal advice or a claim of universal regulatory compliance. The examples below use Great Britain to illustrate how one market translates policy into testable behavior. Distribution permission belongs in the gambling app submission guide, shared components in the mobile design system guide, and full assistive-technology acceptance in the forthcoming accessibility acceptance brief.
Define Scope, Territory and Account Ownership First
Write down the operating license, product type, territory, eligible account states, channels and applicable version of each rule. A licensee’s obligations may differ from those of a software supplier, and one country’s time-out duration should not become a global product constant.
In Great Britain, the UK Gambling Commission’s Remote Gambling and Software Technical Standards (RTS) 12 were amended for 30 September 2026. The revised wording requires gross deposit limits, describes what may be called a deposit limit and specifies how limit changes work. The Commission also sets rules for remote time-outs and self-exclusion. Their conditions have defined license-category exemptions; the table is not a substitute for a license review.
| Specification item | Question to resolve | Required evidence |
|---|---|---|
| Market and product | Which territory, license class and activities are in scope? | Approved rules register and legal reviewer |
| Control coverage | Are limits account-wide, product-specific or both? | Backend behavior and user-facing definition |
| Account state | What happens to blocked, dormant or excluded accounts? | State diagram and API contract |
| Cross-channel scope | Do app, website, customer service and vendors share one status? | Integration test across channels |
| Exceptions | Which rule or control is not applicable, and why? | Written, dated reviewer decision |
Assign an accountable compliance owner for policy interpretation, a product owner for interaction requirements, an engineering owner for enforcement, and a support owner for customer assistance. Record decisions and changes in a versioned requirements matrix.
Make Help and Player Controls Easy to Find
People should not have to explore a betting journey to find safer-gambling help. Label entry points in plain language: Deposit limits, Take a break, Self-exclusion, and Get support. Avoid hiding all four inside a generic “More” menu or requiring a search query to discover them.
For Great Britain, RTS 12C requires a direct, visible homepage link to financial-limit facilities and access on deposit screens, with minimal navigation. Other markets must be mapped separately. As a design recommendation, also put protection controls in account settings and make the support route available from relevant restricted-account states.
Useful navigation tests include:
- Can a person identify the protective action without knowing the operator’s terminology?
- Does the help route stay recognizable on a small screen, in landscape and when text expands?
- Is a live or offline support option available when account authentication or a third-party service fails?
- Does a self-excluded person see help or account-recovery information rather than a promotional landing page?
- Does the player receive a readable confirmation and a way to review the current status later?
A consistent help location can reduce disorientation. WCAG 2.2’s Consistent Help criterion is relevant when several pages repeat help mechanisms; it does not, on its own, certify a native app as accessible. Accessibility testing remains a separate workstream.
Specify Deposit Limits as Enforceable Account Rules
A limit screen needs more than an amount input. Explain the measure, period, reset rule, coverage, current setting, and effective time. If a customer selects a daily limit, make clear whether “daily” means a fixed calendar day or a rolling 24-hour period. Currency, timezone and the treatment of simultaneous limits must match the rules engine.
For a Great Britain-specific implementation under the September 2026 RTS 12 wording, deposit limit refers to gross deposits into the account over a defined period. The standard includes 24-hour, seven-day and monthly options and says the most restrictive overlapping limits apply. Other limit types may be offered but must not be mislabeled as deposit limits. Do not present these details as worldwide requirements.
Distinguish reductions from increases
A lower limit is a protective change. A request to raise a limit is a different state transition and should not be disguised as an instant edit. In Great Britain, RTS 12D specifies immediate reductions unless technical failure prevents them; increases require at least a 24-hour cooling-off period and a fresh positive confirmation afterward. The app must not display an increased limit as active merely because a request was submitted.
| User action | Expected UX state | Server-side acceptance check |
|---|---|---|
| Create a limit | Explain scope, period and activation | Persist approved rule and show effective time |
| Reduce a limit | Confirm protection without upsell | Apply promptly under applicable market rules |
| Request an increase | Show pending state and next eligible time | Preserve existing enforced limit during cooling-off |
| Confirm after cooling-off | Require a new deliberate action | Confirm only after valid time and authorization checks |
| Reach a limit | State why the action is blocked | Block covered transactions consistently across channels |
| Service unavailable | Show honest status and support route | Fail safely; never infer success from a local tap |
Design the action around an authoritative account response. A confirmation message should contain the effective amount, period and start time. If the request cannot be accepted, explain what failed without exposing internal security details. Keep an audit event for review; the user’s on-screen confirmation is not a replacement for system evidence.
Treat Time-Outs and Self-Exclusion as Different Controls
A time-out is a temporary break from gambling. Self-exclusion is a more consequential restriction with separate operational and, often, regulatory procedures. Neither should be mixed up with account deletion, marketing opt-out or ordinary logout.
For certain remote licensees in Great Britain, LCCP 3.3.4 requires time-out options of 24 hours, one week, one month or another reasonable requested period up to six weeks. Under LCCP 3.5.3, relevant licensees must maintain self-exclusion procedures, prevent gambling participation, suppress gambling marketing and direct customers to help. Some license categories are excluded from individual provisions.
A time-out flow should show duration, start, end, covered channels and what account access remains available. An exclusion flow should explain consequences plainly and let the person confirm a deliberate decision without unnecessary persuasion. An additional confirmation may prevent accidental exclusion, but it should not become an obstructive sequence of retention prompts. The Commission’s self-exclusion guidance emphasizes that a person who has decided to self-exclude should be able to do so immediately.
For each control, product and engineering teams must agree what happens to login, outstanding transactions, funds, support access, scheduled messages and third-party integrations. These outcomes depend on the market and account rules; do not assume that blocking gambling should automatically block access to help or lawful account information.
Operational rule: a protective restriction must be enforced centrally. Removing a mobile button while leaving web, API or customer-support channels unrestricted does not provide the intended protection. The event ledger should capture activation, the rule version and affected accounts or channels without creating unnecessary personal-data exposure.
Write Neutral Copy and Safe Error States
Protective screens should state what happens, not sell a decision. Use straightforward verbs such as “Set limit,” “Reduce limit,” “Take a break,” and “Confirm self-exclusion.” Avoid language that implies a player is missing an opportunity, celebrates continued gambling or suggests increasing a limit as a remedy for reaching it. The UK Gambling Commission’s RTS 14A prohibits products from actively encouraging chasing losses or continuing after a person has indicated they wish to stop.
Example confirmation copy: “Your weekly deposit limit is now £100. It applies to deposits across this account from 14:30 UK time today.” This is fictional UI text, not a recommendation for any particular amount. The back end must supply the real value, locale, period and effective timestamp.
Example pending copy: “Your request to increase this limit is pending. Your current limit remains in place. Return after the cooling-off period to confirm the request.” Do not use a countdown that nudges a person toward increasing their limit.
Example failure copy: “We could not confirm this change. Your existing limit remains active. You can try again or contact support.” Show that message only if the server has verified the prior limit is still active; if the current state is unknown, say so and provide a safe escalation path.
Use a short confirmation for high-impact actions, pre-submit validation for amounts and periods, and a clear route to correct input errors. WCAG 2.2 error-prevention guidance supports reviewing and correcting consequential submissions. The precise accessibility acceptance criteria and assistive-technology test coverage belong in the separate accessibility product brief.
Review the Requirements-to-Acceptance Matrix
Before release, QA should test protection flows using both normal and adverse conditions: app restart, network loss, concurrent web sessions, background refresh, server time drift, invalid currencies, pending requests and support escalation. Review at least one account in each relevant status: no limits, limit active, increase pending, time-out active and self-excluded.
| ID / control | Acceptance evidence | Primary owner | Territory check |
|---|---|---|---|
| RG-01 / Help routes | Direct links and screen recording from critical entry points | Product + UX | Check required placements |
| RG-02 / Limit creation | API event, effective time and UI confirmation match | Engineering | Verify limit types and periods |
| RG-03 / Limit increase | No premature activation; second consent after waiting | Engineering + Compliance | Confirm cooling-off rule |
| RG-04 / Time-out | Gambling access blocked on app and web | Engineering + QA | Check durations and exceptions |
| RG-05 / Self-exclusion | Enforcement, support path and marketing suppression tested | Compliance + Operations | Check scheme and account effects |
| RG-06 / Failure recovery | No false success, safe restriction and escalation | QA + Support | Check incident and retention rules |
The accompanying editable requirements matrix includes additional negative test cases, a market-approval field, an evidence reference and a release-status check. Keep blocked requirements visible rather than deleting them from a release report.
Questions teams ask before sign-off
Is a deposit limit the same as a loss limit? No. A gross deposit limit measures incoming deposits; a loss limit measures a separately defined loss amount. Names and calculations must follow the applicable market’s rules.
Can support activate self-exclusion on behalf of a customer? The answer depends on the jurisdiction and authorized process. For relevant UK remote licensees, customer service and an automated remote route are addressed in LCCP 3.5.3. Verify identity, authority, evidence and immediate enforcement in the approved workflow.
Should excluded users still reach support? The protection objective is to prevent prohibited gambling activity, not to obstruct assistance. Determine permitted account access, fund handling and disclosures with the operator’s compliance team.
Does a passing UX review prove legal compliance? No. Design review, backend enforcement, support procedures, license analysis and current regulator requirements all need independent evidence.
Publication note: Confirm market-specific rules, source dates, legal wording and feature availability immediately before publishing or releasing the app. This article is a reusable product-brief starting point rather than a jurisdiction-neutral checklist of mandatory features.
Editable resources: responsible gambling UX acceptance matrix (Excel); negative test cases (CSV). These templates contain example inputs and require project-specific review before operational use.
