AGLC Centralized Self-Exclusion: Mandatory Integration Requirements for Alberta iGaming Operators

Alberta’s Centralized Self-Exclusion (CSE) program is not a feature to be bolted on after launch. Under the AGLC Standards and Requirements for Internet Gaming (SRIG), issued 14 January 2026 under authority of the Board Chair, API integration with AGLC’s central system is formally designated as the third and final step of the registration process. Operators who have completed due diligence and signed the commercial agreement with Alberta’s iGaming Corporation (AiGC) but have not yet integrated with the CSE are not in a position to go live. This article maps the specific obligations under SRIG Sections 3.4 and 3.5, the technical integration contract, the dual check-point requirement at registration and session start, cross-product exclusion scope, marketing suppression duties, audit-log retention, and the reporting escalation path for incidents.

Regulatory Foundation: SRIG Sections 3.4 and 3.5

The SRIG organises self-exclusion obligations across two adjacent provisions. Section 3.4, “Access Management, Prohibited Persons,” governs the technical enforcement layer. Section 3.5, “Centralized Self-Exclusion,” governs the programme scope and the player-facing mechanics. Both must be read together: the prohibited-persons list maintained under Section 3.4 is the data artefact that CSE enrolments populate, and the API connection mandated under Section 3.4 is the integration channel through which Section 3.5 obligations are discharged.

“AGLC will maintain a centralized list of prohibited persons who are convicted or legally excluded (as per section 34.1 and 34.3 GLCR) or have otherwise been determined to be inadmissible for entry to an iGaming site. All registered Operators must: have effective application programming interfaces (API) connection… to AGLC’s centralized information system on persons who are prohibited from entry to an iGaming site.”

The prohibited-persons list covers two overlapping populations: individuals convicted or legally excluded under sections 34.1 and 34.3 of the Gaming, Liquor and Cannabis Regulation (GLCR), and individuals who have voluntarily self-excluded through the CSE programme. Both categories produce the same platform-level enforcement obligation: the individual must be blocked from registering a new account and from logging into an existing account.

What Is the CSE Programme?

The CSE is a fully digital programme managed by AGLC and available to players across all registered iGaming platforms, following a model similar to national self-exclusion registers adopted internationally and land-based venues including casinos and racing entertainment centres (RECs). When a player initiates self-exclusion, the AGLC registration interface presents three distinct scope options.

Exclusion Scope	iGaming Platforms	Land-Based Casinos &amp, RECs
iGaming only	Yes	No
Land-based only	No	Yes
Combined (iGaming + land-based)	Yes	Yes

This cross-channel architecture means that a player who self-excludes under the combined option also becomes inadmissible to every land-based gaming facility in Alberta. For operators, the practical consequence is directional: an exclusion enrolled at any point in the system, whether at a casino cage or via a competitor’s platform, flows into the same AGLC-maintained list and triggers the same API-level enforcement obligation on every registered operator.

The programme is described in AGLC’s Application Guide as “built to maximize privacy while ensuring players have access to resources that promote healthier gambling habits.” The privacy framing is operationally significant: player personal information exchanged through the CSE API must comply with the relevant Alberta privacy legislation, as explicitly stated in SRIG Section 5 on IT and Security Requirements. Operators transferring or processing exclusion-status data must ensure their data-handling agreements and technical controls are aligned with the Personal Information Protection Act (PIPA, Alberta).

Which Products Require a CSE Check?

Every registered iGaming site in Alberta must integrate with the CSE. The SRIG defines an iGaming site as any site named on an operator’s registration, and each distinct site requires its own registration. The CSE obligation therefore applies per site, not per operator entity. Multi-brand operators holding registrations for separate iGaming sites must implement the API connection independently on each platform: a shared integration at the group level that does not surface a site-specific clearance response for each named site does not satisfy the requirement.

The scope extends to all game types available on the registered site. The SRIG does not carve out sports and event betting, peer-to-peer games, or live dealer products from the prohibited-persons check. Any product accessible through a registered iGaming site is subject to the same dual check-point obligation at registration and login.

The Dual Check-Point Requirement: Registration and Session Start

The SRIG’s language in Section 3.4 is unambiguous on where enforcement must occur. The platform must have “effective controls in place to prevent any individual not cleared by AGLC’s centralized system from registering an account or from logging into an existing account.” Two discrete check points follow from this obligation.

At account registration, the platform must query AGLC’s centralized system before completing the registration flow. An individual whose identity matches a record on the prohibited-persons list must be prevented from creating a new account, regardless of whether they have previously held an account on that platform or any other.

At session start (login), the platform must check the centralized system before granting access to an existing account. This is a distinct and separately required control from the registration check. A player who was not on the prohibited list at the time of account creation may have subsequently self-excluded or been added to the prohibited list through a legal or administrative process. The login check closes that gap. Operators whose architecture performs only a one-time check at registration are non-compliant with Section 3.4.

AGLC confirmed that the CSE system was in User Acceptance Testing (UAT) ahead of the 13 July 2026 market launch and that integration testing access was made available to operators well before go-live. Operators who did not begin integration testing during the UAT window face material go-live risk, because the integration must be demonstrated as part of the compliance pre-launch checklist under the Go-Live Compliance Guide published January 2026.

API Connection: Authentication and Security Obligations

The SRIG does not publish a public API specification. The technical contract is delivered to registered operators through AGLC’s iGaming Compliance Branch at the compliance application stage. What the SRIG does specify is the security baseline that any API connection to AGLC’s system must meet.

SRIG Subsection 5.1.6 governs the security requirements for API connections referenced in Section 3.4. Read in conjunction with the broader IT and security provisions, operators integrating with the CSE system must implement multi-factor authentication as part of a secure authenticator. All data in transit must be protected using TLS 1.2 or higher. Encryption algorithms and key lengths must meet or exceed industry standards, with AES-256 and RSA-2048 cited as reference baselines in the SRIG’s IT section, and must be evaluated at least annually for continued adequacy. Private encryption keys must be stored on secure and redundant media accessible only to authorised management personnel.

Access privileges to any system component touching the AGLC integration must be granted, modified, and revoked based on employment status and job function. Access reviews must be conducted quarterly, with attestations and supporting evidence retained for at least two years. Administrative and privileged accounts must be protected by phishing-resistant multi-factor authentication.

What Happens When AGLC Updates the List

Section 3.4 contains a specific obligation that goes beyond the initial integration: “As AGLC updates the centralized list of banned and/or self-excluded individuals, all registered player information must be” cross-referenced against those updates. The practical implication is that the integration cannot be a point-in-time synchronisation. Operators must establish a mechanism to receive and apply AGLC list updates in a manner that ensures any newly prohibited individual is blocked without delay. The precise technical protocol for receiving update notifications is governed by the API specification provided by AGLC at the compliance application stage.

Where an update results in an existing logged-in player being identified as prohibited mid-session, the platform must terminate that session. The SRIG’s obligation to prevent any individual not cleared by the system from “remaining on” an iGaming site confirms this extends to active sessions, not only to new login attempts.

The 72-Hour Discrepancy Report

Any prohibited person who attempts to register or log in to an iGaming site triggers a mandatory reporting obligation. SRIG Section 3.4 requires that discrepancy reports be submitted to AGLC within 72 hours of the event. The SRIG defines a Discrepancy Report as a report prepared by an iGaming Operator or Goods or Services Supplier regarding a security breach or any illegal activity.

Reporting is directed to AGLC’s iGaming Compliance Branch at iGamingCompliance@aglc.ca, as specified in the Go-Live Compliance Guide. Operators must maintain an internal process for identifying, documenting, and escalating these events within their internal controls framework. Compliance teams should map this to their incident-response workflow, treating a prohibited-person access attempt as a Category 1 regulatory incident requiring immediate internal escalation and a timed regulatory submission.

Operators running high-volume platforms during peak periods, including major sporting events or promotional windows, should ensure their fraud and compliance monitoring tools are calibrated to surface access attempts by prohibited persons in near-real time so the 72-hour window can be met. Where the CSE API is unavailable and an operator cannot perform the required check, the operator cannot clear the individual under Section 3.4’s “cleared by AGLC’s centralized system” standard. The conservative position is to block the session or registration attempt and log the event pending API restoration. Operators should contact AGLC’s iGaming Compliance Branch directly for guidance on their specific outage protocol obligations.

Wager Refunds, Balance Return, and Marketing Suppression

SRIG Section 3.5 imposes three downstream obligations that take effect the moment an operator is notified of a player’s self-exclusion status.

On wager refunds: if a player enrols in the self-exclusion programme before the commencement of an event or series of events on which the outcome of their wager is to be determined, the operator must refund that wager. If the player enrols after the commencement of the relevant event, the operator is not required to refund. The pre/post-commencement dividing line is the operative test, and operators must document the timestamp of both the exclusion enrolment notification and the event commencement to establish which rule applies.

On unused account balances: operators must provide a mechanism to facilitate the return of the balance of unused funds when requested by a self-excluded player. This obligation arises on request and the mechanism must be in place before it is needed. Compliance teams should ensure the balance-return workflow is accessible to a player who cannot log in to their account and does not require the player to navigate the platform to initiate it.

On direct marketing suppression: operators must exclude self-excluded players from all marketing efforts once the operator has been notified of the exclusion. The SRIG defines direct marketing to include direct messaging via social media, emails, texts, and phone calls. Suppression must be immediate on notification and must persist for the duration of the exclusion period. Operators using third-party CRM or marketing platforms must ensure their data pipelines propagate the exclusion flag to those systems without latency.

“[Registered Operators must] exclude any self-excluded players from all marketing efforts once the Operator has been notified, and provide a mechanism to facilitate the return of the balance of unused funds, when requested, to a player who has self-excluded.”

Break-in-Play vs. Self-Exclusion: A Distinct Product

Compliance engineers building the responsible gambling control stack must distinguish between AGLC’s CSE programme and the break-in-play feature mandated separately in SRIG Section 3.3. These are not interchangeable.

Break-in-play is an operator-level control offering short-term voluntary pauses of one day, one week, one month, two months, or three months. During a break, the player is blocked from placing further wagers but retains access to their account balance, profile, and responsible gambling features. Break-in-play operates entirely within the operator’s platform and does not interact with AGLC’s centralized system or produce a prohibited-persons list entry. A player on a break-in-play pause is not self-excluded and must not be treated as such.

CSE enrolment is categorically more severe: it is centrally recorded, cross-platform, potentially cross-channel, and generates mandatory reporting obligations on every registered operator. A player who requests a break through the operator’s UI and a player who contacts AGLC to self-exclude through the CSE programme are in entirely different regulatory categories. Platform architecture must handle these states separately and must not allow a break-in-play event to be logged as a CSE enrolment, or vice versa.

Audit-Log Retention and Record-Keeping

SRIG Section 5 requires operators to retain event and security logs for at least one year online and seven years in archive, or as otherwise required by regulation. This standard applies to logs generated by the CSE integration, including API call records, response payloads, check-point outcomes, and session-termination events triggered by exclusion status. The seven-year archive requirement means operators cannot rely solely on live system logs: a structured archival process meeting the WORM/immutability or cryptographic signing standard (SHA-256) referenced in the SRIG must be in place from day one.

Compliance records more broadly, those relating to adherence with control activities including the prohibited-persons check, must be retained for a minimum of three years under SRIG Section 4 on Records. The 72-hour discrepancy reports submitted to AGLC are part of this record set. Operators should maintain a searchable, timestamped internal register of all discrepancy reports filed, cross-referenced to the underlying incident log, so that AGLC inspectors can reconstruct the event sequence on demand.

How Does This Differ from Ontario’s BetGuard?

Ontario launched its centralised self-exclusion platform, BetGuard, on 14 May 2026, approximately two months before Alberta’s market opened. The comparison between the two provincial models is instructive for compliance teams entering both markets.

Dimension	Alberta (AGLC CSE)	Ontario (BetGuard)
Programme operator	AGLC (regulator)	iGaming Ontario (commercial entity)
Integration timing	Pre-go-live (registration prerequisite)	Post-launch rollout
Land-based scope	Yes (optional combined exclusion)	Online only
Exclusion term options	AGLC-defined (details in API spec)	6 months, 1 year, 5 years, custom
Mandatory API connection	Yes, SRIG Section 3.4	Yes, operator obligation under iGO agreement
72-hour discrepancy report	Required, SRIG Section 3.4	Not specified in published AGCO standards
Marketing suppression trigger	On operator notification	On enrolment
Balance return mechanism	Must be available on request	Same obligation under AGCO standards

The structural difference that carries the most operational weight is the timing of integration. Alberta positioned CSE integration as a registration prerequisite: AGLC’s Application Guide lists it as Step 3, the final gate before an operator is cleared for market access. Ontario’s BetGuard launched as a new tool within an already-operating market, meaning that Ontario operators were live before the centralised system existed. Alberta’s architecture positions CSE integration not as a post-launch compliance task but as a threshold condition that gates the entire go-live process.

The cross-channel dimension also distinguishes the two models. BetGuard covers online gambling platforms exclusively. Alberta’s CSE encompasses land-based venues, making it conceptually closer to national self-exclusion register models used in Denmark (ROFUS), Sweden (Spelpaus), and Spain (RGIAJ), which are examined in the Responsible Gambling Compliance hub. For the full side-by-side analysis of how Ontario’s and Alberta’s frameworks diverge on fees, commercial agreements, and responsible gambling controls, see the AGCO vs AGLC comparison.

What Does “Not Cleared” Mean in Practice?

SRIG Section 3.4 sets a clear and binary standard: any individual “not cleared by AGLC’s centralized system” must be prevented from registering or logging in. The cleared/not-cleared determination is the output of the API query, not a judgment the operator makes independently. The operator’s platform cannot apply its own risk assessment or override a negative clearance response. The platform must act on the API response, not on the operator’s internal knowledge of the player.

This has practical consequences for two edge cases. First, where a player has previously held an account on the platform before the market launched, and that player subsequently self-excludes via AGLC’s system, the login check will return a negative clearance. The operator cannot allow that session to proceed on the basis of a prior commercial relationship. The existing account must be deactivated or blocked against login, and the marketing suppression obligation applies immediately. Second, where a re-registering player attempts to open a new account on the same platform after their exclusion period has lapsed, the platform may only process the registration if the AGLC system returns a positive clearance for that individual. The operator cannot rely on its own internal records or on the player’s representation that the exclusion period has ended.

Enforcement Authority and Sanctions

AGLC inspectors have authority under the Gaming, Liquor and Cannabis Act to investigate suspected violations of the SRIG and to prepare Incident Reports. Where an Incident Report documents non-compliance with Section 3.4 or 3.5, it is submitted to the Vice President of AGLC’s Regulatory Services Division, who may refer it to the Board for a formal hearing under the Board Hearing Panel Rules and Procedures. Sanctions available to the Board include warnings, requirements to cease specific activities, conditions on registration, and suspension or revocation of registration.

Failure to maintain the API connection required under Section 3.4, or failure to submit discrepancy reports within 72 hours, is a condition-of-registration violation. For operators entering Alberta from Ontario or other jurisdictions, the enforcement architecture differs from the AGCO model in that AGLC holds both regulatory and enforcement authority directly, without the dual-entity split that characterises AGCO’s relationship with iGO on commercial matters. Compliance teams should treat AGLC as the single point of enforcement accountability for CSE-related failures.

Operators should consult qualified legal counsel in Alberta for jurisdiction-specific advice on how the CSE obligations interact with their specific platform architecture, multi-brand registration structure, or grey-market transition obligations under the iGaming Alberta Act.

For the broader Alberta compliance architecture, including registration fees, AML and FINTRAC obligations, SOC 2 and ISO 27001 timelines, and the AiGC commercial agreement requirements, see the AGLC SRIG framework overview. The AGLC Standards Explorer provides a searchable view of all 335 SRIG standards by risk theme.

Key Resources

AGLC Standards and Requirements for Internet Gaming (SRIG), issued 14 January 2026, authority: Board Chair, primary compliance instrument governing all registered operators and suppliers in Alberta’s iGaming market. Available at aglc.ca.

AGLC Internet Gaming Go-Live Compliance Guide, published January 2026, operational checklist for pre-launch compliance, including CSE integration as a go-live gate. Available from AGLC iGaming Compliance Branch at iGamingCompliance@aglc.ca.

AGLC Application Guide for iGaming Registration, three-step registration roadmap designating CSE integration as the third and final step before market access. Available at aglc.ca.

Gaming, Liquor and Cannabis Act (Alberta) and Gaming, Liquor and Cannabis Regulation, sections 34.1 and 34.3, statutory basis for the prohibited-persons framework referenced in SRIG Section 3.4.

iGaming Alberta Act, enabling legislation for the private operator market and structural basis for the AGLC/AiGC dual-authority model. To begin your CSE integration, contact AGLC’s iGaming Compliance Branch at iGamingCompliance@aglc.ca to request the API specification and credentials needed to start testing in the UAT environment.