Compliance Monitoring Software for iGaming: How to Evaluate Vendor Claims Before You Sign

A compliance monitoring platform sold to you as “fully compliant with UKGC, MGA, and AGCO requirements” is a marketing claim, not a regulatory assurance. Before any contract is signed, compliance officers must apply the same scrutiny to a software vendor that regulators apply to the operator: document the obligations, verify the architecture, and confirm in writing who bears liability when the platform fails. The enforcement record shows regulators do not accept “the vendor did not flag it” as a defence.

The Liability Floor: What Every Licensing Framework States

The starting legal position is consistent across every major iGaming jurisdiction. The operator bears regulatory accountability for the conduct of every third party it contracts with, including software vendors. Under AGCO Registrar’s Standards for Internet Gaming, Standard 1.19, operators “are responsible for the actions of third parties with whom they contract for the provision of any aspect of the Operator’s business related to gaming in Ontario and must require the third party to conduct themselves in so far as they carry out activities on behalf of the operator as if they were bound by the same laws, regulations, and standards.” Standard 1.18 requires operators to contract only with reputable suppliers, and Standard 1.20 requires a maintained supplier register available to the Registrar on request.

The Malta Gaming Authority takes the same position in the MGA Gaming Authorisations and Compliance Directive (Directive 3 of 2018, Version 2, October 2021). Article 27 requires that any outsourcing agreement oblige the service provider to carry out the outsourced activities as if bound by the same regulatory instruments as the licensee, provide information to the licensee sufficient to satisfy its own regulatory obligations, and permit immediate contract termination where the MGA determines the outsourced service is in breach of regulatory instruments. Article 28(1) states explicitly that outsourcing service providers managing websites on behalf of a B2C licensee “shall be deemed to be acting for and on behalf of the licensee who shall therefore be responsible for their actions insofar as the licence issued by the Authority is concerned.”

“Outsourcing service providers that manage one or more websites and, or gaming premises pertaining to a B2C licensee, as the case may be, shall be deemed to be acting for and on behalf of the licensee who shall therefore be responsible for their actions insofar as the licence issued by the Authority is concerned.”, MGA Gaming Authorisations and Compliance Directive (Directive 3 of 2018), Article 28(1)

The AGLC Standards and Requirements for Internet Gaming (SRIG) mirrors this structure. Operators entering Alberta’s market must provide AGLC with an annual Technology Compliance Confirmation signed by the CEO or CCO. That confirmation must cover the entire technology solution, including “all affiliated GSS providers” and “third-party technology integration into the gaming site.” If a registered operator uses third-party critical gaming system suppliers, the operator’s confirmation explicitly covers the integration layer, while the supplier provides its own separate confirmation. Regulatory accountability does not transfer to the vendor’s confirmation: the operator remains responsible for ensuring the integration is compliant.

What Does “Regulatory Fit” Actually Mean for a Compliance Platform?

Compliance software vendors routinely claim multi-jurisdictional coverage. The question compliance officers must ask is not whether the platform has a configuration for a given jurisdiction but whether its output satisfies the specific, documented deliverables that regulator requires. These vary substantially by jurisdiction.

The AGCO requires operators to develop, maintain, and submit a Control Activity Matrix (CAM): a documented summary of all controls related to the gaming site, including where the operator works with third-party suppliers and platform providers, per AGCO Registrar’s Standard 1.02(4). The CAM must be independently audited before go-live and made available to the AGCO on request. A compliance monitoring platform that produces dashboards but does not structure output in a format suitable for CAM submission, and that cannot map each control to the AGCO’s six risk themes, is operationally incomplete for Ontario regardless of how it handles other jurisdictions.

The AGLC SRIG has a parallel requirement. CAMs must be independently audited to confirm that controls are designed to ensure compliance with the Standards and Requirements. The AGLC adds that the audit must be carried out by a unit not involved in developing the CAM, or by a designated external auditor. A platform that is used both to build and to evidence controls requires careful scoping to avoid the appearance that the same function designed and confirmed the same controls.

The MGA Compliance Audit Manual (MGA/G/001, August 2018, v1) sets out the audit checks that the Authority’s own auditors apply. Check 4.1.5 specifically requires auditors to verify that “audit trails / logs of any changes performed to the regulatory data (including player data, financial data and game data) databases are kept.” Check 4.5.4 requires auditors to obtain and compare the outsourcing policy submitted to the MGA against the current version. A compliance platform that does not maintain immutable, timestamped logs of configuration changes will not satisfy what the MGA’s own audit procedure tests for.

Jurisdiction	Regulator-Required Deliverable	What the Platform Must Produce
Ontario (AGCO)	Control Activity Matrix (CAM)	Control documentation mapped to AGCO’s six risk themes, independent audit trail
Alberta (AGLC)	Annual Technology Compliance Confirmation (CEO/CCO signed)	Full technology scope including third-party integrations, change logs for the annual period
Malta (MGA)	Compliance Audit evidence (MGA/G/001)	Immutable audit trails for player, financial, and game data, outsourcing policy version control
Great Britain (UKGC)	RTS security requirements (sections 4.1, 4.3); LCCP record-keeping	ISO/IEC 27001:2022 Annex A-aligned controls, complete player account transaction logs

The Enforcement Case That Redefined Supply-Chain Accountability

The Evolution £4.75m settlement with the UKGC, following an 18-month licence review, is reported as the most consequential supply-chain compliance enforcement action in recent iGaming history. According to iGamingBusiness reporting, the UKGC found that Evolution’s AML risk assessments were outdated and that its monitoring of third-party operators was inadequate, allowing branded games to be accessed via six unlicensed casino sites operated by two third-party entities between late 2023 and late 2024. Licence suspension was considered. Evolution avoided it by implementing an action plan and cooperating fully with the regulator.

The Evolution case has two direct implications for compliance software procurement. The first is architectural: the UKGC’s finding demonstrates that passive monitoring, systems that process data presented to them without cross-referencing distribution channel status, is insufficient. Evolution’s ring-fencing technology investment was a direct response to a system that could not detect distribution to unlicensed operators. Any compliance platform an operator selects must be evaluated against the specific detection capabilities required, not just its general monitoring functionality.

The second implication is liability mapping. Evolution was the licensee. The operators who accessed the games without proper licences were third parties. The regulatory settlement fell on Evolution. Compliance officers evaluating software for their own operations should ask two questions: if this platform fails to alert us to a compliance breach that a regulator later identifies, what is our contractual position with the vendor, and what is our regulatory exposure? The answer to the regulatory question is full liability. The answer to the contractual question should be obtained from the vendor agreement before signing.

AML and KYC Module Interrogation

When a compliance platform includes AML transaction monitoring or KYC workflow modules, operators must evaluate those modules against the specific technical requirements their regulator imposes, not against a generalised FATF-aligned checklist. GLI-19 Standards for Interactive Gaming Systems (v3.0), section A.8.2, sets out the baseline AML monitoring obligations that certified interactive gaming systems must satisfy. These include a system of internal controls to assure ongoing compliance with local AML regulations, monitoring of player accounts for opening and closing in short time frames and for deposits and withdrawals without associated game play, and the capability to use “automated data processing systems to aid in assuring compliance.”

GLI-19 section A.8.2 also requires the AML system to ensure that “aggregate transactions over a defined period may require further due diligence checks and may be reportable to the relevant organization(s) if they exceed the threshold prescribed by the regulatory body.” The operative phrase is “prescribed by the regulatory body.” A platform that applies a single global threshold is not correctly configured for multi-jurisdictional operation. The AGCO enforcement action against NorthStar Gaming illustrates this precisely: according to iGamingBusiness reporting, AGCO reached an $80,000 settlement with NorthStar Gaming after the operator failed to trigger enhanced due diligence when a player exceeded the $25,000 deposit threshold specified in AGCO’s AML standards. Written policies existed. The system did not act on them.

For operators holding or pursuing MGA licensure, the Compliance Audit Manual at check 4.5.2 requires auditors to confirm that all critical gaming suppliers are licensed by the MGA. If an AML monitoring vendor is supplying a critical gaming function, that vendor requires an MGA Critical Gaming Supply licence. Operators must confirm their vendor’s MGA licensing status before integration, not after the auditor identifies it as a gap. For a reference-level overview of how the AML and financial compliance obligations map across FATF, FINTRAC, and FIAU frameworks, the AML Compliance hub provides the cross-jurisdictional baseline.

Technical Integration: What the Standards Require at the Architecture Level

GLI-19 v3.0, section B.5, sets out the technical requirements for third-party service provider integrations in certified interactive gaming systems. The standard requires that agreements with third-party providers covering access to, processing of, or communication with system components “shall cover all relevant security requirements.” The services, reports, and records provided by third-party service providers must be “monitored and reviewed annually or as required by the regulatory body.” When a provider changes its service or controls, the change must be managed with re-assessment of risks proportionate to the criticality of the systems involved.

Section B.5.2 of GLI-19 v3.0 requires that the security roles and responsibilities of third-party service providers be “defined and documented as required by the regulatory body.” When a compliance software vendor accesses an operator’s player data, financial data, or game data for monitoring purposes, the operator must have a documented record of what access rights were granted, to whom, and under what conditions. Section B.5.3 requires formal data processing agreements covering the subject matter, duration, nature, and purpose of processing, type of data, storage mechanism, security detail, data transfer methodology, retrieval mechanism, retention schedule, and deletion method. A vendor Data Processing Agreement that does not address all of these elements is technically incomplete under GLI-19.

Section B.5.1 of GLI-19 v3.0 imposes a network architecture requirement directly relevant to cloud-delivered compliance platforms: third-party service provider communications must use a segmented network separate from the network segments hosting player connections, and third-party service provider data must not affect player communications. The compliance monitoring platform must confirm whether its integration architecture satisfies this segmentation requirement or whether the operator’s own network configuration must implement it.

Contractual Terms Compliance Officers Must Require

MGA Directive 3 of 2018 specifies the minimum terms that outsourcing agreements must contain. Every compliance platform agreement entered into by an MGA licensee must include a provision obliging the vendor to carry out the outsourced activities as if bound by the same regulatory instruments as the licensee. The agreement must give the licensee the right to terminate immediately for just cause where the vendor is in breach of those instruments, and separately where the MGA has determined that the outsourced service is being performed in breach. These are mandatory contract terms under Article 27 of Directive 3, not optional enhancements.

For AGCO-registered operators in Ontario, Standard 1.19 requires the operator to flow down the obligation that third parties “conduct themselves in so far as they carry out activities on behalf of the operator as if they were bound by the same laws, regulations, and standards.” This contractual flow-down obligation must be reflected in the vendor agreement. An AGCO-registered operator cannot satisfy this obligation by relying on a vendor’s standard commercial terms.

Beyond the jurisdiction-specific mandated terms, compliance officers should negotiate the following provisions in every compliance platform agreement. The contract should specify the vendor’s obligation to provide regulatorily complete audit logs upon request within a defined timeframe. It should specify notice obligations when the platform configuration is changed in a way that affects the scope or coverage of compliance monitoring, mapped to the AGCO Notification Matrix or equivalent mechanism in the relevant jurisdiction. The agreement should confirm whether the vendor indemnifies the operator against regulatory penalties arising from platform failure, or whether the agreement limits vendor liability to contract damages only. In practice, most enterprise compliance software contracts cap vendor liability at the contract value, a cap that will be immaterial relative to a regulatory fine or settlement.

Does the Vendor Need to Be Registered With Your Regulator?

This question is routinely overlooked in procurement and surfaces as a compliance finding at the worst possible time. AGCO Standard 1.20 requires operators to maintain a list of all suppliers providing goods or services in relation to lottery schemes and to make that list available to the Registrar on request. The AGCO Go-Live Compliance Guide distinguishes between critical gaming system suppliers, who must hold AGCO registration, and other goods and services suppliers, for whom the obligations differ. A compliance monitoring platform that accesses live player transaction data or integrates with core gaming systems may qualify as a critical gaming system supplier, requiring independent registration and potentially ITL certification.

Under the AGLC SRIG, Goods or Services Suppliers who run critical gaming systems must have a CAM in place meeting all applicable Standards and Requirements, which must be made available to AGLC on request. AGLC’s framework specifically identifies critical gaming systems as including certified games, random number generators, and related infrastructure. Operators must assess whether a compliance monitoring platform’s integration architecture places it within or adjacent to those critical system boundaries under Alberta’s definitions.

The MGA distinguishes between Critical Gaming Suppliers, who require a B2B Critical Gaming Supply licence, and Material Gaming Suppliers, who require either a material supply certificate or case-by-case approval. The MGA Compliance Audit Manual at check 4.5.2 requires the auditor to confirm that all Critical Gaming Suppliers are MGA-licensed. Where a compliance platform performs functions that the MGA would categorise as critical gaming supply, the vendor must hold the appropriate MGA authorisation before the integration can proceed. The MGA licence requirements profile sets out the B2B and B2C licence categories and the applicable compliance contribution framework in full.

Evaluating Responsible Gambling and Self-Exclusion Integration Claims

Several compliance platforms market integrations with national self-exclusion registers as a key feature. The regulatory requirements attached to these integrations are precise, and a platform’s claim that it “supports GAMSTOP” or “integrates with BetGuard” must be verified against the specific technical obligations those registers impose. For Ontario’s iGaming framework under the AGCO registration requirements, BetGuard integration is a condition of operating in the province, and the AGCO specifies how self-exclusion data must be checked at account creation and login. A platform that performs batch checks rather than real-time checks at login does not satisfy the operational requirement even if it nominally integrates with the register.

The UKGC’s October 2025 updates to the Remote Gambling and Software Technical Standards (RTS) introduced prescriptive requirements for deposit limit tooling. Compliance officers should build implementation lead time into vendor contracts by specifying when particular RTS-required features must be live, not simply when the platform contract commences.

The intersection of responsible gambling obligations and software capability is where enforcement risk concentrates. According to SBC News reporting, QuinnBet’s UKGC settlement included findings of social responsibility failures: exceeding age-based deposit limits and failing to detect problem gambling patterns. The UKGC emphasised that operators “must ensure systems can identify harm and financial crime quickly.” A compliance platform that provides alerts but does not log whether those alerts were acted upon, by whom, and when, does not satisfy the documentation standard that a post-investigation review will require.

Multi-Jurisdiction Operations: The Configuration Governance Problem

Operators licensed in multiple jurisdictions face a specific risk with compliance platforms that manage all jurisdictions through a single configuration layer. AGCO Standard 1.02(2) requires that “substantial changes to the Operator’s control environment shall be communicated to the Registrar in a timely manner.” The AGLC SRIG imposes an equivalent requirement. If a platform update modifies how a compliance control functions, that modification triggers a notification obligation in Ontario or Alberta even if it was made solely to accommodate a regulatory change in another market.

Compliance officers operating across Canada, the UK, and Malta simultaneously should verify whether their compliance platform maintains jurisdiction-level configuration snapshots and change logs. If the vendor applies updates globally across all client configurations simultaneously, the operator may face a situation where a platform change responding to UKGC RTS amendments inadvertently alters the Ontario or Alberta configuration and triggers a notification obligation the operator is unaware has been triggered. Vendors must be asked, specifically, how they manage configuration changes, what notice they provide before changes are deployed, and what rollback capability exists if a change produces an unintended compliance effect.

The MGA Directive 3 First Schedule lists the risks operators must account for in essential components where functions are outsourced. These include “loss of governance,” which covers changes to the terms and conditions of a service provider while the licensee is using its services, and “inadequate maintenance of the systems and underlying infrastructure.” A platform vendor who can modify terms, add or remove monitoring modules, or change data retention policies without operator consent creates precisely the governance-loss risk the MGA requires licensees to mitigate.

For a detailed technical framing of what auditors test for across system security and third-party integrations under the UKGC and MGA frameworks, the analysis in ISO/IEC 27001 in iGaming: Why Most Compliance Teams Get It Wrong covers the common scoping failures that also affect compliance platform architecture decisions.

Due Diligence Questions to Put to Every Vendor

The following questions should be put in writing to every compliance platform vendor during the procurement process, and the answers should be incorporated into or attached to the final agreement as representations.

Ask the vendor to identify, by name and version, the regulatory instruments their platform has been designed and tested against, and to confirm the date of the most recent review against each instrument. Ask whether the platform has been assessed by an Independent Testing Laboratory registered with any regulator the operator is subject to, and if so, to provide the assessment report. Ask how the vendor manages regulatory change: what their process is when a jurisdiction amends its technical standards, what timeline they commit to for implementing required platform changes, and what they communicate to operators about the nature and scope of those changes.

Ask the vendor to confirm their own registration status with each relevant regulator, whether they hold any MGA supply licence, whether they appear on the AGCO’s supplier register, and whether they have been subject to any regulatory investigation or enforcement action in any gaming jurisdiction. Ask them to confirm the data processing agreement terms they are prepared to accept, specifically whether they will accept the GLI-19 v3.0 section B.5.3 data processing agreement requirements as the contractual baseline.

Ask the vendor for references from operators who have been through a formal regulatory audit or compliance review while using the platform, and whether they are willing to confirm the outcome. A vendor who has operated in a jurisdiction long enough to have supported a client through a regulator-initiated review is a materially different proposition from one who has not.

Compliance officers who require legal counsel for the contractual review should engage counsel with demonstrable iGaming regulatory experience rather than general commercial contract practitioners. The mandatory MGA Directive 3 terms, the AGCO flow-down obligations, and the AGLC Technology Compliance Confirmation requirements each create specific, non-negotiable drafting requirements that general contract review will not identify. For a structural comparison of how third-party obligations interact across the AGCO and AGLC frameworks, the AGCO vs AGLC: Key Differences in Ontario and Alberta Internet Gaming Regulation analysis covers the distinctions that affect technology supplier obligations in each market.

Key Resources

AGCO Registrar’s Standards for Internet Gaming (full text, amended February 2022): Standards 1.18, 1.20 (Third Party Management) and Standard 1.02 (Sound Control Environment, including CAM requirements). Available via agco.ca.

AGCO Internet Gaming Go-Live Compliance Guide: Sections covering CAM requirements, ITL certification policy, and the AGCO Notification Matrix. Available via agco.ca.

MGA Gaming Authorisations and Compliance Directive (Directive 3 of 2018, Version 2, October 2021): Articles 25, 28 (Outsourcing) and First Schedule (risks concerning essential components). Available via mga.org.mt.

MGA Compliance Audit Manual (MGA/G/001, August 2018, v1): Sections 4.1 (System Checks) and 4.5 (Third-Party Agreements). Available via mga.org.mt.

AGLC Standards and Requirements for Internet Gaming (SRIG): Section 4 (Suppliers, including Technology Compliance Confirmation and CAM requirements) and Section 5 (Information Technology and Security Requirements). Available via aglc.ca.

GLI-19 Standards for Interactive Gaming Systems (v3.0): Section A.8.2 (AML Monitoring), Section B.5 (Third-Party Service Providers), and Section C.3.2 (Cloud Service Provider Relationship). Available via gaminglabs.com.

UKGC Remote Gambling and Software Technical Standards (RTS): Sections 4.1, 4.3 (Security requirements and critical systems). Published 2 February 2021, last updated 31 October 2025. Available via gamblingcommission.gov.uk.