GamStop explained, the scheme, the periods, the checks

What GamStop is, plainly

GamStop is the national multi-operator self-exclusion scheme for online gambling in Great Britain. It is a not-for-profit register run by the National Online Self-Exclusion Scheme Limited, and its purpose is to let a person enrol once and be blocked from every remote gambling site that holds a UK Gambling Commission operating licence. The scheme is voluntary at the point a person joins it, in the sense that nobody is placed on the register without their own action, but it is binding on the operator side once the enrolment is live. Every remote licensee in the UKGC's register of licensed operators is contractually obliged to integrate with GamStop under Social Responsibility Code Provision 3.5.5 of the Licence Conditions and Codes of Practice, and that obligation runs from the day the licence is granted until the day it is surrendered or revoked. The operator does not choose whether to participate. It chooses only how to build the integration cleanly enough to survive an inspection.

From the compliance seat inside a mid-sized UKGC-licensed remote casino, GamStop is not a policy document that lives on a shelf. It is a live technical dependency running on the back of every registration form and every login page, and its event stream is one of the first things a safer gambling analyst looks at in the morning stand-up. The scheme's own systems return a match or a no-match on each check the operator runs, and the operator's downstream logic decides what happens next inside the account journey. A match is a hard stop with no override path. A no-match is a licence to proceed to the next control layer, which is age verification under Licence Condition 17, identity verification under LCCP SRCP 2.1, and the operator's own suite of markers of harm sitting on top of that. Nothing on this page reveals anything a competitor could not read for themselves in the LCCP text on the Commission's own website, but the wiring diagram is one that most players never see.

The three periods, and what each commits you to

A person joining GamStop chooses one of three fixed periods at the point of enrolment. Six months is the shortest option and reads, in the register's own language, as a short reset that gives the enrolled person time to step away and see whether the reasons that led to the exclusion resolve on their own. One year is the middle option, and is the period the safer gambling team at my old operator saw most often on the incoming match log for customers who had already used one shorter period and returned. Five years is the longest option available on the scheme, and it is often chosen by people who have been through the sector for a decade or more and want the register to hold at a length that outlasts most of the marketing cycles that would otherwise reach them by post, by email and by targeted advertising. Whatever length is selected at enrolment, the register applies it in full and does not allow it to be shortened whilst active.

What each period commits the enrolled person to, from the operator's side, is a hard block against every UKGC-licensed remote site for the full duration. It does not commit the person to attending treatment, does not commit them to informing a family member, and does not commit them to anything the register itself cannot see. It is a technical exclusion, and the compliance value of that technical exclusion is that the person on the register has made a decision whilst calm and has removed their own ability to unmake it whilst not calm. That is why the minimum period cannot be shortened, and it is why any conversation the compliance team ever has with a customer about the length of their period happens after the period expires, never during it.

A closer look

Inside the operator, the length of a match tells the safer gambling team something about the customer sitting behind it, even before any interaction begins. A six-month match on a returning customer's file is a different signal from a five-year match returning after a long absence, and the internal decision on what enhanced-monitoring window to apply on re-registration is calibrated against the length of the last exclusion the customer completed. None of that judgement work is visible to the customer. What is visible is the plain-language screen that returns when the register match hits, and the closure of the account journey at that point.

How the block reaches every UKGC-licensed site

The technical shape of the integration is straightforward once it is drawn out. On the customer's device, a registration or login attempt lands on the operator's front-end, which passes the identity attributes into the back-end account service. The account service composes a hashed lookup packet against the customer's verified name, date of birth and address details, and sends that packet to GamStop's application programming interface over an authenticated channel with strict transport security and mutual certificate verification. The register replies with a status code and a match indicator. If the match indicator is positive, the operator's account service raises an internal event, writes it to the compliance log, and returns a short screen to the customer that explains the block without giving away any detail the register would not want disclosed.

What most players do not see is that the check is not a one-off. In the operator I worked in, the check ran at every registration, at every login, and again at the point of a funded action when the last check had aged past the freshness window the compliance team had set in policy. The freshness window matters because a customer can enrol on GamStop halfway through an existing account's lifetime, and the operator has to catch that enrolment on the next natural touchpoint. On the compliance side, a technical failure of the check is treated as a serious incident rather than a routine bug. It is the kind of incident that goes on the operator's key events return under Licence Condition 15.2 if it lasts long enough to have plausibly allowed a self-excluded person through, and it is the kind of incident a compliance manager will personally sign off before it is closed.

What happens when your period ends

The register does not release a person on the day the calendar hits the end of the period they chose. It waits for the person to make an active decision, and that decision has to be taken by the person themselves through the register's own identity-verified process. This design choice sits at the centre of the scheme and is deliberate. The scheme's authors took the view that the moment a self-exclusion expires is precisely the moment the enrolled person is most exposed to the same triggers that led them to enrol in the first place, and that a passive release on the calendar date would strip out the last piece of protection the register still offered. On the operator side, that means a compliance team can never assume a customer whose original period has passed is safe to re-approach. The customer has to come back through the front door, and the front door is at GamStop's end, not the operator's.

Once the customer contacts GamStop, passes the identity check and confirms they wish to end the exclusion, the register schedules the release with a 24-hour delay attached. During that delay, UKGC-licensed operators continue to see the match on every check, and the operator's registration or login flow continues to close out. At the end of the delay, the register clears the match and the next check the operator runs will return no-match. What follows next on the operator side is not a normal customer journey. It is an enhanced-monitoring flow that treats a returning customer as inherently higher risk than a new one, and it stays in force for a period the compliance team defines by internal policy, usually six months from the release date, sometimes longer where the original exclusion length or the customer's prior play history justifies it.

The twenty-four hour cool-off explained

The 24-hour cool-off is one of the quiet safety features of the scheme and it is often misunderstood by people who read about GamStop from outside the industry. It is not a delay imposed to make the customer wait for a queue at the register. It is a deliberate window built into the release path, and it exists because the moment of maximum craving is often the moment a person will contact the register to end an exclusion. In that moment, a person is not making a calm decision. They are making a decision they may regret when the window closes, and the register's own designers took the view that placing a fixed pause between the request and the release protects the person from themselves in a way the scheme's other features cannot.

From the operator's side, the cool-off has an equally important role in the compliance log. Every check the operator runs during the cool-off returns a match, and the check history over that day forms part of the audit trail that supports the customer's re-entry into the licensed sector. The compliance team does not use the cool-off to make any decision about the customer's account. That decision has already been made by the customer at the register, and the operator's job is simply to keep the block in place until the register lifts it. What the team does use is the shape of the return that follows. A customer whose first login after release lands within minutes of the cool-off ending, and immediately attempts a deposit at the customer's prior peak stake, is a different profile from a customer whose return unfolds slowly over the following week. The compliance policy does not treat those two returns identically, and the enhanced-monitoring configuration reflects that.

A closer look

The cool-off is also the point at which the operator will typically send a short welcome-back message to the customer, drafted by the safer gambling team rather than the marketing team, and cleared under LCCP SRCP 5.1 on marketing to customers who have used self-exclusion. The message contains no offer, no bonus, no promotional link. It contains the helpline number, a reminder that deposit limits can be set on the account before any play resumes, and a plain statement that the operator is applying enhanced monitoring for a defined period. The tone is deliberate, the wording is reviewed on a rolling schedule, and the audit trail on the send is kept for the standard record-retention period under Licence Condition 4.2.

The seven-year auto-extension nobody warns you about

If a person enrolled on GamStop does nothing at the end of their chosen period, the register does not quietly release them back into the licensed sector. It auto-extends the exclusion for a further seven years, and it does so without further contact with the enrolled person. This is one of the least-discussed features of the scheme in public writing about it, and it is one of the most important for a UK adult to know before they enrol. The rationale is again about the exposure created at the expiry moment. Silence at expiry is not treated as consent to be re-exposed. It is treated as the person's decision, by inaction, to stay behind the block for a further seven years. The scheme's designers took the view that this default protects more people than a passive release would, and the operator side has no argument with that reading of the design.

Inside the operator, the auto-extension shows up as an unchanged match on the register check for a customer whose original period would have expired. The compliance team does not treat this as a data anomaly. It is a normal steady-state response from the register, and the customer's account remains blocked in exactly the same way it was blocked during the original period. Where the operator sees a distinction is in the internal metadata on the customer file, where the original period end date has passed and no cancellation request has been logged at the register. That combination is a signal, and it is not a signal to reach out. It is a signal to leave the customer alone, remove them from any residual marketing lists that automated systems may have re-enrolled them into during the period, and confirm on the compliance log that the auto-extension is being respected by every downstream system in the operator's stack.

GamStop and the wider harm-reduction picture

GamStop is not the whole of the UK's harm-reduction architecture and it was never designed to be. It sits in the middle of a wider stack of protections that includes the Gambling Commission's Licence Conditions and Codes of Practice, the safer gambling code provisions in the LCCP, the affordability check regime being rolled out under the White Paper 2023 reforms, the statutory levy that came into force on 6 April 2025 and now funds NHS-commissioned treatment services, the National Gambling Helpline run by GamCare, and the practical money-side controls that UK banks now offer their own customers on card gambling. Each of those layers does something GamStop does not, and GamStop does something none of them do. The value of the register is that it is a single decision, made once, that reaches every licensed operator without the enrolled person having to remember which operators they have accounts with.

From the operator's side, the layered picture is what a compliance team spends most of its time balancing. A customer who has not enrolled on GamStop can still be at risk, and the operator's own safer gambling controls under LCCP SRCP 3.4.1 on customer interaction do not depend on the customer having taken the step of self-exclusion. What the register adds, when a customer is on it, is a hard technical stop that the operator's internal controls cannot substitute for. What the register does not add, when the customer is not on it, is any of the softer signals a safer gambling team relies on to spot a customer whose play shape is changing in ways the customer themselves has not yet noticed. Those signals come from session-level telemetry, from deposit-cadence analytics, and from the customer's own responses to interaction prompts.

Common misreadings of the scheme

The most common misreading of GamStop is that it is a marketing tool operators use to funnel customers into other products. It is not. The register is run by a not-for-profit body funded from the licensed sector but operationally independent of it, and the operator's role is limited to running the integration and respecting the match. A related misreading is that a UK-licensed operator can help a customer end their exclusion early. It cannot. Any operator staff member who suggested such a thing to a customer would be committing a personal management licence breach under the LCCP framework, and would trigger a serious incident on the compliance log that would go on the operator's key events return under Licence Condition 15.2. The register is the only route, the cool-off is enforced by the register, and the operator's job is to keep the block until the register lifts it.

Another misreading that recurs in third-party writing about the scheme is that the auto-extension is a hidden trap. It is not hidden. It is set out in plain English on the GamStop website at the point of enrolment, and the enrolment flow requires the person to read and confirm the periods and their consequences before completing the sign-up. What can look hidden is the interaction between the auto-extension and the expiry date the enrolled person may have written down at home. A person expecting a release on a calendar date, who has not been told or has forgotten that the release requires an active contact with the register, will meet the auto-extension at the moment of trying to log in to a licensed site. From the operator side, the returning match is not treated as a problem to be solved. It is treated as the scheme working exactly as its designers intended.

Read next

• The legal position for UK players outside GamStop
• The risks, explained without the marketing
• Payments and checks, banks, cards, crypto, KYC
• Coming off GamStop, the official route
• Getting support, helplines, clinics, family, money

Frequently asked questions