How I redesigned KTO's responsible gambling limits into one hub players could read at a glance.
01 · Context
KTO was a licensed betting platform in Brazil, and Brazil's betting regulation requires operators to give players real tools to control their play. From February 2026, every new player had to set a session limit and a loss limit during registration. Those two limits became mandatory, so players could change them but never delete them.
Until then, a limit was something a few players went looking for. Now every new account started with two of them, and every one of those players could hit a limit in the middle of a bet. The Limits Hub started there: if the product was going to stop people, it had to show them why and when.
02 · The old experience
The old experience let players set a limit and nothing more. A form asked for a value and a duration, and after saving, the product never showed how much of the limit a player had used, how much remained or when it would reset. A player who reached a limit found out when a bet failed.
Finding the tools took effort too, since the controls sat behind two paragraphs of institutional text, in separate tabs for limits, reality check and self-exclusion.
03 · Benchmark
I ran the whole discovery myself, starting with a benchmark of eight operators in Brazil against 15 criteria scored from 0 to 3.
The leaders earned their points on self-exclusion and links to external support. No operator scored above 2 on having one clear panel with every control, and none scored above 1.5 on proactive warnings. That gap became the direction: one place to see every control, and warnings before the limit, not after it.
04 · Research
I mapped the jobs players hired these tools for, starting from real player messages in our Intercom. One player wrote that without a rigid way to stay in control, the whole month ran short because everything went to bets. Another avoided playing at all for fear of getting addicted and losing everything. (Both translated from Portuguese.)
The research made the trade-off clear. The same player can be casual today and at risk on an emotional day. Treating everyone as at risk adds friction that ruins the experience for players who are fine, and treating everyone as casual fails the vulnerable ones. Players also had social and emotional jobs: not being seen as addicted, and not feeling punished for protecting themselves.
I summed it up in one principle that shaped the rest of the project: the best responsible gambling experience is invisible when everything is fine, present when it is needed and firm when it is critical.
The principle outlived the Hub. When I launched ACE's notification and feedback components (toast, banner and info), they had no usage rules, so I proposed this one; the other designers agreed, and the team adopted it.
05 · Trade-offs
The principle put me against the business more than once. Many protective choices cost conversion, and the company accepted them because it wanted to be the operator that cared about its players, not one squeezing every cent out of them. The business's biggest concession was the Hub itself. The regulation required the tools, not this experience, and everything the Hub added, from usage visibility to warnings and the 24-hour wait, was a choice to protect players at some cost to revenue. In return, almost every detail became a negotiation with the product team, and I gave ground too, as with the Edit Limit link below.
06 · The hub
I decided to put every control on one page, grouped by what players needed them for: spending and time limits (loss, session, deposit and bet), behavioral controls (auto withdrawal and reality check) and breaks (a set period, an open-ended break and self-exclusion). The project existed to give players visibility, and hiding the controls behind tabs would have contradicted it.
At the top, an overview showed every active limit with a progress bar. I decided that each limit would show what the player had used, what remained and when it would reset, and the Payments PM and I defined together which of those details to display. Each limit also carried a status, such as Approaching, Limit Reached or Increase Pending, so a player could read their situation without opening anything.
07 · Warnings
I suggested warning players before the limit, and the Payments PM decided the thresholds: a banner at 70% of a limit and another at 90%, each saying what would happen at 100%. At the limit, a modal stated it plainly and gave the exact reset time, and a banner stayed at the top of the app afterwards.
Each warning also carried an Edit Limit link. The product team asked for it, and I disagreed: a one-tap path to edit a limit at 90% could become a shortcut to loosen it at exactly the wrong moment. I conceded, because the project's weight sat elsewhere and the next decision limited the risk. I expected to change the company's mind with evidence that heavy play shortens how long a player stays, by measuring how many players who raise their limits later stop playing altogether. KTO had no such data yet, so I planned to start from published research on gambling harm, and the company closed before I could.
08 · The 24-hour rule
The Payments dev lead raised the asymmetry in grooming: lowering a limit should take effect immediately, and raising it should wait. The alternative was no asymmetry, with every change applying at once. I suggested making the wait 24 hours and designed the flows, screens, messages and notifications that explain it. Someone protecting themselves shouldn't wait, and someone loosening their own guardrail gets a day to reconsider.
The rule only works if players understand it before they save, so the edit screen states the consequence ("If you reach R$300, betting is disabled until the daily reset") and the wait ("Increasing limits takes 24 hours") right under the field. I decided to lock editing while a change was pending, with a status and a countdown on the card, so a player could not stack a second change on top of the first.
Lowering a limit below what the player had already used needed its own guard. A modal explained that the new limit would apply immediately and might block betting until the reset, and it made choosing another amount the main action, so nobody locked themselves out by accident. Removing an optional limit counted as loosening and waited 24 hours as well. Compliance reviewed every message and approved all of them without changes.
09 · Results
The Hub launched on web on 7 May 2026 and reached the app by 9 June, as one of the first surfaces built on ACE, KTO's design system.
In the eight weeks after the web launch, limit-related support requests fell from 13.3 to 4.5 per thousand active players, 66% lower. The absolute count dropped too, from 4,332 to 1,985, about 2,350 fewer limit-related contacts for CX to handle. The active base changed a lot in June and July, which is why I report the rate per thousand players. No other change to limits or their support flows happened in that period, so the Hub is the most likely cause, though a changing player mix could explain part of it.
Weekly self-exclusions rose from about 450 to about 950 in the same period. I read that as vulnerable players finding the tool and using it the way it was meant to be used. Two numbers did not move: the share of players with a real loss limit stayed at 13% to 14%, and limit increases kept outnumbering reductions at the same 2.5 to 1 ratio.
Guided decisions and different levels of protection by vulnerability went to a V2, to be funded only if V1 proved promising. The principle held anyway: the Hub stayed quiet for players who were fine and got firm for the ones who needed it.
If I started again, I would frame the trade-off on day one. I began the Hub designing for what was best for the player, with too little weight on what the business needed, and many of our discussions came from that gap. Had I accepted from the start that every decision would balance protection against conversion, I would have brought proposals already framed that way and avoided several of those arguments.