Skip to content
2,151 standards indexed across 19 jurisdictions View the Atlas
3 hubs live · 3 more in the pipeline See all compliance topics
Daily news + multi-week series Browse all insights
3 tools live · 4 interactive tools in development Roadmap
AGLC · Technical Standards 15 min read May 30, 2026

Alberta iGaming Platform Technical Requirements: What the SRIG Demands

AGLC SRIG sets exacting technical obligations for Alberta's July 2026 launch: ATF certification, API integration, log retention, and platform-level RG enforcement. Built for CTOs and QA teams.

Matt Denney

By

Founder, gamingcompliance.io · 15 yrs in iGaming compliance

Published May 30, 2026 15 min read Filed Technical Standards

Alberta’s regulated iGaming market opens on July 13, 2026, under a regulatory framework that demands technical precision from day one. The Alberta Gaming, Liquor and Cannabis Commission’s Standards and Requirements for Internet Gaming (SRIG), issued January 14, 2026, and supplemented by a February 5, 2026 addendum covering IT and security requirements, establishes binding technical obligations across platform architecture, game certification, API integration, audit logging, and responsible gambling enforcement. For CTOs and QA teams preparing for launch, the SRIG standards are not aspirational: they are conditions of registration, and failure to implement them before going live is a registration-blocking event, not a post-launch remediation task.

What Is the SRIG and How Does It Bind Your Platform?

The SRIG is the primary compliance instrument governing all registered iGaming Suppliers in Alberta, a category that encompasses both Registered Operators and registered Goods or Services Suppliers. Its authority derives from the iGaming Alberta Act and the Gaming, Liquor and Cannabis Act (Alberta). The SRIG makes the technical hierarchy clear: anything not specifically permitted is prohibited, and board policies issued under the SRIG are conditions of registration in their own right.

Two entities share regulatory authority over the Alberta market, and both create technical obligations. AGLC acts as regulator, issuing and overseeing registrations, setting standards, and enforcing compliance. The Alberta iGaming Corporation (AiGC) manages operations and holds the commercial relationship with Registered Operators. The SRIG states explicitly that registered Goods or Services Suppliers must adhere to data security standards and data requirements as published for the Application Programming Interfaces (APIs). Those API specifications are published by AiGC, not AGLC, which means platform teams must track two separate standards documents to achieve full technical compliance.

Key Structural Point: AGLC approves the technical architecture and certifies compliance with the SRIG. AiGC publishes the API data specifications your platform must implement. Both obligations are pre-conditions to going live.

ATF Certification: What Must Be Certified and When

All games, random number generators, and components of iGaming systems that accept, process, determine, display, and log details about player bets must be certified by an Accredited Testing Facility (ATF) registered by AGLC before deployment in the Alberta market. The SRIG’s language on timing is unambiguous: certifications must be obtained before any technology goes live. An ATF may not issue a conditional certification that depends on future modifications being carried out.

The scope of mandatory ATF certification is broad. It covers slot games, table games, sports and event betting systems, poker and other card games. For live dealer operations, the requirement extends to physical RNG elements: physical roulette wheels, dice tables, and card shufflers that incorporate electronic components all fall within the certification scope. Any physical component with an electronic element that influences game outcome is treated as a critical gaming system component under the SRIG.

“ATF certifications must: only be issued by ATFs that are registered by AGLC, must ensure technology is certified for all games, random number generators and components of iGaming systems that accept, process, determine outcome, display and log details about player bets… be certified before they are deployed in the Alberta market.”

Source: AGLC, Standards and Requirements for Internet Gaming (SRIG), Section 4.12, issued January 14, 2026.

ATFs must themselves hold ISO accreditation, and the SRIG requires that AGLC’s SRIG be added to the ATF’s scope of ISO accreditation within one year of the ATF being registered as a Goods or Services Supplier in Alberta. This ISO-scope requirement applies within the next scheduled accreditation audit cycle, meaning ATFs with existing ISO accreditation from other jurisdictions cannot simply apply those credentials to Alberta. Alberta-specific scope must be confirmed.

Re-certification is mandatory when any modification or subsequently discovered undetected issue impacts critical gaming system integrity, fairness, security, or compliance with the SRIG. The SRIG defines two fast-track pathways for in-market updates. A Regulatory Fix (emergency fix), meaning modifications addressing regulatory concerns requiring immediate action to correct a live issue, may be deployed prior to certification. However, the fixed technology must be submitted to an ATF for Alberta certification within five business days of release, and the submitting party must maintain all testing records and provide them to AGLC on request. Every other category of change must be certified before deployment.

In practice, operators preparing for July 2026 should complete ATF certification submissions no later than April or May 2026 to allow for review cycles, ATF scheduling, and any remediation before go-live. Teams relying on certifications obtained for other jurisdictions, including Ontario, cannot automatically port those certifications to Alberta without confirming Alberta-specific SRIG scope coverage with their ATF.

RNG Requirements: Probability, Independence, and Server-Side Generation

The SRIG sets two foundational requirements for random number generation. The probability of achieving any specific game outcome must be constant and independent of game history, the player, or any other factor, unless the exception is clearly explained in the terms governing play. This standard prohibits any form of outcome manipulation based on player profile, session history, or system state.

The second requirement addresses architecture: all critical functions, including the generation of the outcome of any game, must be generated by the gaming system independent of the end player device. Client-side RNG, where the player’s browser or app generates outcomes, is not compliant under the SRIG. All outcome determination must occur on the server or gaming system, with the player device used only to display results. This requirement directly affects RGS platform architecture and the design of downloadable game clients.

Games must also operate according to their game specifications, with outcomes determined in accordance with the terms governing play and prevailing payouts as described to the player. Terms governing play cannot be changed during an active game session unless the player is made aware of the change before placing any further wagers. These obligations impose real-time consistency requirements on game configuration management systems.

For sports and event betting specifically, the SRIG states that bets must be committed before the determination of game outcomes. Any wager received after the determination of the associated outcomes must be voided and returned to the player. Platforms offering in-play betting must implement technical controls capable of detecting and voiding late-received wagers before settlement, with sufficient precision to distinguish pre- and post-determination receipt timestamps.

Data Centre and Infrastructure Approval

Data centres and remote gaming servers must be approved by AGLC before operations commence. The approval process covers three elements: data residency designation, cross-border transfer assessment, and encryption key residency review. Operators planning to host Alberta player data or gaming system components outside Alberta, or outside Canada, must complete the cross-border transfer assessment as part of the pre-launch infrastructure approval process. PIPA Alberta governs data collection and protection for player personal information, and player personal information must only be used for the lottery schemes conducted and managed by AGLC or AiGC.

The SRIG requires that gaming system architecture demonstrate security in depth across all components. All gaming systems and devices must validate inputs before processing. Remote access methods must be secure and centrally managed using zero-trust principles, device posture checks, multi-factor authentication (MFA), and session recording for third-party access. Wireless communications must be secured using industry-standard encryption, centrally managed, and may only be implemented with prior AGLC approval. Encryption algorithms and key lengths must meet or exceed AES-256 and RSA-2048 minimums, and must be evaluated at least annually, or upon the emergence of new cryptographic vulnerabilities.

Infrastructure Checklist: Data centre location and encryption key residency must be declared to AGLC pre-launch. Zero-trust remote access architecture, phishing-resistant MFA, and AGLC-approved wireless configuration are each mandatory, not optional controls.

Audit Logging: What Must Be Captured, How It Must Be Stored

The SRIG imposes a two-tier log retention structure that technical teams must design for explicitly. Event and security logs must be retained for at least one year in an online, immediately accessible format, and archived for a minimum of seven years thereafter. General compliance information, including logs related to compliance with the law, the SRIG, and Control Activities, must be retained for a minimum of three years unless a longer period is specified elsewhere in the SRIG.

Continuous logs are mandatory for all critical gaming systems, covering financial accounting and game state history. The SRIG specifies the technical integrity controls that these logs must implement: logs must be protected against alteration using WORM (write-once, read-many) storage or immutability controls, or by cryptographic signing with SHA-256 as a minimum. Logs must be transmitted and stored over TLS 1.2 or higher. Access to logs must be role-based, with segregation of duties between operations and monitoring functions.

“Logs must be protected against alteration (e.g., WORM/immutability or cryptographic signing with SHA-256), transmitted and stored over TLS 1.2+; Access to logs must be role-based, with segregation of duties between operations and monitoring, Logs must be retained per 4.16.1 and made available to AGLC on request, and Implementation of a monitoring function (e.g., SIEM) to correlate and alert on integrity events, with remediation tracked to closure.”

The SRIG additionally requires implementation of a monitoring function, citing SIEM (Security Information and Event Management) as an example, capable of correlating and alerting on integrity events, with remediation tracked to closure. This is an active monitoring obligation, not simply a logging requirement. All time-stamped records across the gaming system must use authenticated NTP synchronisation (citing NTS as a specific example) to ensure cross-system timestamps are consistent and audit-trustworthy.

Access privilege reviews are required on a quarterly basis. Reviews must confirm least privilege and separation of duties, and attestations together with supporting evidence must be retained for at least two years. Administrative and other privileged accounts must be limited to authorised personnel and protected by phishing-resistant multi-factor authentication. Temporary and guest accounts must be disabled immediately when the purpose for which they were created is no longer required.

Access Management and Prohibited Persons: The API Mandate

One of the most technically specific obligations in the SRIG concerns the centralized prohibited persons system. AGLC maintains a centralized list of prohibited persons, encompassing individuals who are convicted or legally excluded under the Gaming, Liquor and Cannabis Regulation (sections 34.1 and 34.3), or who have been otherwise determined to be inadmissible. All Registered Operators must maintain an effective API connection to AGLC’s centralized information system and implement effective controls preventing any individual not cleared by AGLC’s centralized system from registering an account or logging into an existing account.

This is not a batch-update obligation. The system must respond in real time during account registration and login flows. As AGLC updates the centralized list of banned and self-excluded individuals, registered player information must be reconciled against the updated list. When a prohibited person attempts to access or remain on an iGaming site, a discrepancy report must be submitted to AGLC within 72 hours. The API connection itself must meet the security requirements specified in SRIG Subsection 5.1.6, meaning the prohibited persons API sits within the same zero-trust, MFA-protected access control framework as the rest of the gaming system architecture.

Alberta’s approach is substantially more prescriptive than Ontario’s framework under the AGCO Registrar’s Standards for Internet Gaming. In Ontario, the AGCO’s centralized self-exclusion program, BetGuard, is being developed on a directed timeline: the AGCO Registrar’s Standards note that once directed by the Registrar, operators will be required to participate in a coordinated, centralized self-exclusion program. Alberta launches with the centralized API integration as an immediate, day-one requirement, and the prohibited persons system covers both self-excluded individuals and legally excluded persons within a single API endpoint. Operators entering Alberta from Ontario should not assume their existing self-exclusion integration maps to Alberta’s centralized system without verifying the API specification published by AGLC and the data feed specifications published by AiGC.

Responsible Gambling Controls: System-Enforced, Not Policy-Stated

The SRIG frames RG controls as technical obligations enforced at the platform level, not policy commitments documented in a procedures manual. Players must be provided with the following system-enforced controls, available at registration and at any time after: deposit limits (capping the amount deposited into a player account), loss limits (restricting the amount lost, calculated as winnings less the amount spent), and time limits (restricting time spent in areas of the site where games may be played, in increments of one hour at minimum).

The cooling-off mechanism is a mandatory technical control with a defined minimum window. Where a player has previously established any internet gaming limit, a request to relax or eliminate that limit must be made only by the player and may only be implemented after a cooling-off period of at least 24 hours. The platform must enforce this delay at the system level, and a player cannot bypass the cooling-off window through customer service escalation or account settings workarounds.

“Where an internet gaming limit has been previously established by a player, a request to relax or eliminate that limit must: only be made by the player, and only be implemented after a cooling-off period of at least 24 hours.”

Players must also receive periodic reminders to review their ability to set limits and to review their account activity. The SRIG does not specify a fixed frequency for these reminders, leaving the mechanism design to the operator, but the obligation to trigger them is mandatory. There must also be a player activity time-out that automatically logs the player out or ends the session after a specified period of inactivity.

Registered Operators must have policies and a programme in place to assess and monitor player risk profiles, supporting the identification of players at moderate or high risk of harm. The platform must also maintain an effective mechanism for monitoring player behaviour in a way that proactively identifies those who may be at risk. These obligations link directly to logging requirements: records related to risk profiling and interventions, including manual adjustments to player risk scores, must be retained to demonstrate compliance with the SRIG. For a cross-jurisdictional view of how these enforceable platform-level RG controls sit within the broader Canadian and international responsible gambling landscape, the Responsible Gambling Compliance hub maps self-exclusion, deposit limit, and player monitoring obligations across all 17 regulated markets covered on this site.

Compared to Ontario, where AGCO’s Registrar’s Standards take a principles-based approach that allows operator flexibility in how RG outcomes are achieved, Alberta’s SRIG is more technically prescriptive. The cooling-off period, the specific limit types, and the system-enforcement framing are all stated as minimum requirements with defined technical characteristics. Operators building a single platform stack for both provinces should design to Alberta’s more specific requirements as their floor, then confirm that Ontario’s standards are also met within that architecture.

For teams implementing cross-provincial responsible gambling tools, the AGCO vs AGLC comparison on this site maps the structural divergences between Ontario and Alberta in detail, including RG tool requirements and the dual commercial agreement structures each market demands.

Technology Compliance Confirmation and the Control Activity Matrix

Registered Operators who run critical gaming systems must provide AGLC with an annual Technology Compliance Confirmation affirming their technology is compliant with all applicable SRIG standards and requirements. For Registered Operators, the scope of this confirmation must include the entire technology solution deployed for Alberta iGaming operations: the platform and underlying infrastructure, network devices, operating systems and databases, gaming software, and other applications.

Where a Registered Operator uses third-party registered Goods or Services Suppliers who run critical gaming systems, those third-party suppliers produce their own Technology Compliance Confirmations. The Registered Operator’s confirmation does not replicate the supplier’s scope, but it must cover the integration of those third-party systems into the operator’s platform. The integration layer is the operator’s responsibility, regardless of which supplier built the underlying component.

Pre-launch, Registered Operators must provide AGLC with a Control Activity Matrix (CAM): a summary of the operator’s processes and controls related to the iGaming site. The required controls must be in place before going live. The CAM must be independently audited to ensure controls have been designed to achieve SRIG compliance. The independent audit must be conducted by a unit or function within the operator’s organisation that was not involved in developing the CAM, such as internal audit, or by a designated external auditor. The audit results confirming compliance must be included with the CAM submission. Registered Goods or Services Suppliers providing critical gaming systems must also maintain a CAM, available to AGLC on request.

Section 5 of the SRIG requires that a recognised industry standard framework be used to manage the IT control environment to support compliance. The SRIG does not prescribe a specific framework by name, but ISO/IEC 27001 and SOC 2 are the standards most commonly referenced in comparable Canadian iGaming contexts. Operators who have already implemented these frameworks for Ontario operations will find the Alberta requirements architecturally compatible, though Alberta’s explicit data residency and key residency obligations add jurisdiction-specific layers that may require additional scope declarations. For teams navigating the ISO implementation, the article on ISO 27001 in iGaming addresses the certification errors most commonly made by compliance teams in this sector.

Source: AGLC, Standards and Requirements for Internet Gaming (SRIG), Sections 4.12, 4.16, and 5, issued January 14, 2026 and February 5, 2026, authority: Board Chair.

Pre-Launch Certification Timeline: Sequencing for July 13, 2026

The SRIG does not publish a prescriptive pre-launch certification calendar, but the sequence of mandatory pre-deployment steps creates an implicit critical path that technical teams should reverse-engineer from the July 13, 2026 go-live date.

Data centre and remote gaming server approval from AGLC must be obtained before any gaming operations begin. This requires a data residency designation, cross-border transfer assessment, and encryption key residency review, all of which require AGLC engagement and review time. Operators running multi-tenant infrastructure shared across Ontario and other jurisdictions will need to clearly delineate the Alberta-specific components presented for AGLC approval.

ATF certification submissions for all games, RNGs, and critical gaming system components must be complete and approved before deployment. For a July 13 launch, submissions relying on standard ATF review cycles need to be filed by April or May 2026 at the latest, accounting for any remediation rounds. ATFs registered with AGLC must have SRIG scope on their ISO accreditation, teams should verify this with their chosen ATF well before submission.

The CAM, together with its independent audit results, must be submitted to AGLC before going live. The API connection to AGLC’s centralized prohibited persons system must be live, tested, and verified before market access. The AiGC API data feed integration, covering the published data security standards and data requirements for APIs, must also be implemented and tested pre-launch.

Operators entering Alberta who are already registered with AGCO in Ontario should treat the Alberta technical integration as a distinct compliance project rather than an extension of their Ontario platform. The API targets are different, the data residency obligations may differ, and the ATF certification scope must explicitly cover the SRIG, not just the AGCO Registrar’s Standards. According to SBC News (May 2026), the SBC Summit Canada held in Toronto reinforced that Alberta’s market structure is attracting operators at pace, with technical integration complexity cited as one of the primary operational challenges for multi-market operators preparing for launch.

For a broader view of how the AGCO and AGLC regulatory frameworks differ at the structural level, and where the technical obligations diverge most significantly for operators running cross-provincial platforms, the AGCO vs AGLC comparison provides the operational mapping most relevant to teams managing both registrations simultaneously.

Key Resources

AGLC Standards and Requirements for Internet Gaming (SRIG), issued January 14, 2026 and February 5, 2026 (addendum), authority: Board Chair. Available at aglc.ca.

iGaming Alberta Act (Bill 48), the enabling legislation for Alberta’s private iGaming market.

Gaming, Liquor and Cannabis Act (Alberta), providing the statutory basis for AGLC registration and enforcement authority.

AGCO Registrar’s Standards for Internet Gaming, last updated May 2025, available at agco.ca. Reference standard for Ontario comparison obligations.

AGLC Standards Explorer, available at gamingcompliance.io/jurisdictions/aglc/, provides a searchable index of all SRIG standards by theme.

Matt Denney

Matt Denney

Editorial · gamingcompliance.io

Reads the primary source so you don't have to. Fifteen years inside iGaming compliance: operator, supplier, and crown-corporation lottery.

Related coverage · also tagged Technical Standards

Browse all →

Technical Standards

iGaming Data Residency and Local Hosting: Which Jurisdictions Mandate On-Soil Infrastructure

May 27 · 13 min read

Technical Standards

PAM Provider Compliance Burden: What Platform Vendors Inherit From Their Operators

May 25 · 16 min read

Technical Standards

ISO/IEC 27001 in iGaming: Why Most Compliance Teams Get It Wrong

Apr 29 · 12 min read

The Tuesday brief, every week.

One email. Every regulator change we surface, every standard we re-index, every enforcement decision we read. No marketing, no fluff.

Unsubscribe with one click. We'll never share your address.