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

Data residency is where iGaming infrastructure compliance gets operationally expensive. Before a B2B platform supplier or multi-market operator can treat a shared global data centre as a compliant solution, it needs to know which jurisdictions treat the physical location of a server as a regulatory condition, and which treat it as an implementation detail. The answer varies sharply across the markets covered here: some demand physical hardware on domestic soil, some accept offshore hosting provided a local replication or access node exists, and others impose no location mandate at all, focusing instead on accessibility and security outcomes.

The following analysis maps the requirements jurisdiction by jurisdiction, drawing on primary regulatory texts. Operators and their B2B technology partners should consult qualified legal counsel before finalising infrastructure architecture for any specific market, as licence conditions and regulatory guidance can change and individual circumstances affect how general requirements apply.

Romania: The Strictest On-Soil Mandate in European iGaming

Romania’s framework, set out in Government Emergency Ordinance 77/2009 and its implementing norms (NORMĂ 24/02/2016), imposes the most prescriptive data localisation requirement of any major European iGaming jurisdiction. Under OUG 77/2009 Article (vi), the game server and the serverul de siguranță (safety server) must ensure the storage of all data relating to remote gambling activities, including player registration and identification, stakes placed, and winnings paid. The statute is explicit: storage must take place on the data-storage equipment, specifically the safety server, situated on Romanian territory.

“Stocarea de informații trebuie să se realizeze pe echipamentul de stocare a datelor, respectiv serverul de siguranță, situat pe teritoriul României.”

Translation: “The storage of information must be carried out on the data storage equipment, namely the safety server, located on Romanian territory.”

The safety server records automatically, in real time, all information relating to remote gambling activity on Romanian territory: player registration and identification, the geographic IP location of the player, stakes placed, winnings received, and fund transfers to player gaming and payment accounts. Separately, the system must transmit daily consolidated reports to a serverul în oglindă (mirror server) made available to the ONJN (Oficiul Național pentru Jocuri de Noroc), the national gambling regulator. Data must be stored as created for a minimum of five years from the date of collection.

An important nuance: where the operator’s central IT system is itself situated on Romanian territory, OUG 77/2009 Article (ix) provides that the operator permits ONJN direct access via the mirror server, without a separate safety server being required. Operators of EU/EEA origin hosting their central system outside Romania must establish the physically on-soil safety server arrangement and maintain a Romanian-registered permanent establishment or authorised representative with residential domicile in Romania.

For B2B platform providers, this means contracts covering Romanian market delivery must provision dedicated Romanian colocation capacity. A shared EU data centre in Frankfurt or Amsterdam does not satisfy the requirement. Providers serving multiple Romanian licensees can co-locate hardware in the same Romanian data centre, but each licensee must maintain its own distinct safety server environment.

Malta (MGA): Offshore Infrastructure Permitted, Real-Time Replication Required

The Malta Gaming Authority does not mandate that licensees host their infrastructure in Malta. The MGA’s Technical Infrastructure guidelines (December 2015, v1, document reference MGA-G-001) explicitly acknowledge that operators increasingly run multi-jurisdictional operations and that hosting has moved to cloud and international data centre environments. The MGA’s regulatory objective is not geographic control of hardware but assured, real-time regulatory access to data.

Licensees and applicants must provide the MGA with full details of their technical infrastructure, including a network schematic identifying all hardware, virtual machines, internal IP addresses, and the geographic locations and addresses of every premises where gaming systems, control systems, and regulatory data are hosted. The MGA defines regulatory data as any data the Authority may require to carry out its regulatory functions, including, but not limited to, player, financial, and game-play data.

“Access to live information becomes even more difficult when the licensee’s infrastructure is located in other jurisdictions and, or cloud environments. This limitation can be overcome through the provision of a real time replication of regulatory data, on a live replication server in Malta.”

Where the primary infrastructure sits outside Malta, the MGA’s compliance architecture requires that a live replication server be maintained in Malta, receiving real-time copies of regulatory data. The MGA’s Compliance Audit Manual (MGA/G/001, August 2018, v1) confirms this obligation in its audit checklist: auditors are required to verify that regulatory data (player data, financial data, and game data) is being replicated to servers located in Malta, confirm compliance with documented arrangements, and test replication in real time, recording latency.

For cloud deployments, the MGA requires that critical components be hosted on a private cloud environment not shared with other tenants. Virtual private cloud environments are permitted where the Authority is satisfied that the integrity and security of critical components is not at risk. Critical components are defined as RNGs, jackpot servers, and player database servers. The licensee remains accountable for compliance regardless of the hosting entity.

In practice, MGA licensees operating from outside Malta have two compliant architecture paths: retain a Malta colocation node as the primary infrastructure location, or host primary infrastructure elsewhere and maintain a Malta-based replication server receiving real-time data feeds. The second path is more common for large operators with existing EU data centre arrangements, but it requires a Malta colocation contract, network connectivity guarantees, and documented replication latency that the MGA can test during inspections. For a broader view of how MGA licence costs and obligations compare to other major jurisdictions, the UKGC vs MGA 2026 cost comparison on this site provides relevant context.

Alberta (AGLC): Pre-Approval of Every Data Centre

The AGLC’s Standards and Requirements for Internet Gaming (SRIG), issued under the Board Chair’s authority on February 5, 2026, introduces one of the most structured data residency governance requirements in North American iGaming. Section 5 (Information Technology and Security Requirements, Architecture and Infrastructure) states:

“Data centres and remote gaming servers must be approved by AGLC, including data residency designation, cross border transfer assessment, and encryption key residency review.”

Three distinct approval elements follow from this requirement. The data residency designation identifies where data is stored and processed at rest. The cross-border transfer assessment examines any flow of data across Canadian borders, a particularly relevant obligation given the prevalence of US-based cloud infrastructure used by operators entering the Canadian market. The encryption key residency review determines where cryptographic keys are held, which can be as significant a compliance consideration as data storage location itself.

The AGLC does not publish a preapproved list of compliant data centre locations. Operators and their B2B suppliers must submit their proposed architecture for AGLC review as part of the go-live process. The SRIG requires operators to provide, before launch, results from security vulnerability assessments of Alberta production infrastructure conducted by an independent and qualified security firm, alongside internal and external penetration testing results. Management responses to findings must accompany those results. This creates a pre-launch architecture review cycle with meaningful lead time requirements.

Alberta’s position stands in contrast to Ontario’s outcomes-based approach under the AGCO Registrar’s Standards, which do not specify a pre-approval mechanism for data centre locations. For a comparison of how AGCO and AGLC differ across their broader compliance frameworks, the AGCO vs AGLC analysis on this site covers the structural distinctions in detail.

Ontario (AGCO): Outcomes-Based, No Server Location Mandate

Which specific data storage jurisdiction requirement does the AGCO impose? The AGCO Registrar’s Standards for Internet Gaming, last updated May 2026, do not specify a Canadian or Ontario server location requirement for operators. The framework is explicitly standards-based and outcomes-oriented, giving operators flexibility to determine the most efficient and effective way of meeting defined regulatory objectives.

Under Standard 5.26, player information must be securely protected and its usage controlled. The requirements mandate that data collection and protection obligations for player personal information meet those set out in Ontario’s Freedom of Information and Protection of Privacy Act (FIPPA). FIPPA imposes restrictions on the transfer of personal information outside Canada in certain circumstances, and institutions subject to it must ensure equivalent protections apply where data is held or processed abroad. For operators contracting with non-Canadian cloud providers, FIPPA compliance at the contract level becomes the operative data residency mechanism.

The AGCO Standards further require that records be maintained in a secure location and in accordance with applicable policies and laws, that event data be retained to provide chronological information and logs enabling reconstruction and review, and that the gaming system be capable of providing custom and on-demand reports to the Registrar. The practical effect is that data must be accessible to the AGCO for regulatory purposes, but the mechanism for achieving that is left to the operator’s documented architecture.

Denmark (Spillemyndigheden): The SAFE System and Geographic Separation

Spillemyndigheden’s Technical Requirements for Online Casino and Betting (Tekniske krav for onlinekasino og væddemål, v2.5) impose a distinctive data architecture requirement: each licence holder must establish a data store called the SAFE, which serves as the regulatory reporting repository. Spillemyndigheden accesses the SAFE directly to download game data and carry out supervisory functions.

The SAFE must be established on a separate server, and Spillemyndigheden must have online access to the most recent 12 months of game data at all times. A further 48 months of archived game data must be stored on electronically readable media, deliverable to Spillemyndigheden within five working days on request. The licence holder is responsible for backup, and the SAFE and its backup must be geografisk adskilt (geographically separated), meaning they must not be housed in the same data centre. Where both SAFE and backup are handled virtually, this separation requirement is satisfied.

Critically, the Danish technical requirements do not mandate that the SAFE or backup be located in Denmark. The location obligations are functional: Spillemyndigheden must be able to access the SAFE in real time via FTPS over TLS 1.3. The TamperToken security system, operated by Spillemyndigheden, ensures the integrity of data held in the SAFE while at rest. For B2B suppliers serving Danish licence holders, the SAFE can be operated by a third party on the licence holder’s behalf, but the licence holder retains full responsibility for its operation at all times.

United Kingdom (UKGC): No Domestic Hosting Mandate, High Security Obligations

The UK Gambling Commission imposes no requirement that remote gambling licensees host their systems in Great Britain. The Remote Gambling and Software Technical Standards (RTS), published February 2021 and last updated October 2025, are drafted in a principles-based format that sets the key objectives without prescribing how infrastructure must be arranged geographically.

The UKGC’s security requirements under RTS Section 4 are aligned with ISO/IEC 27001:2022 (the 2022 standard having replaced ISO/IEC 27001:2013 per RTS Section 4.2). The critical systems to which the security standards apply include electronic systems that record, store, process, share, transmit or retrieve sensitive customer information, systems that generate or process random numbers determining game outcomes, systems that store results or the current state of a customer’s gamble, and communications networks transmitting sensitive customer information. Where any of these systems sit, and who manages them, is a licensee-level architectural decision, provided security obligations are met and the systems are accessible for Commission purposes. For a fuller analysis of how ISO 27001 maps to UKGC and MGA obligations, the ISO 27001 in iGaming article on this site covers common implementation failures in detail.

The LCCP Standard 1.1.3 requires that remote licensees ensure third parties providing user interfaces for customer access include a contractual term that such interfaces comply with the Commission’s technical standards for remote gambling systems. This extends the UKGC’s compliance reach to B2B infrastructure suppliers without specifying their geographic location.

Comparing the Models: Three Distinct Architecture Patterns

Across these jurisdictions, three distinct infrastructure compliance models emerge.

Hard localisation applies in Romania. The safety server must be a physical device on Romanian territory. There is no cloud or replication alternative that satisfies the statutory requirement. This is a pure on-soil mandate, predating the cloud era of regulation and reflecting a legislative approach designed for an earlier technical environment. The cost consequence for B2B providers is dedicated Romanian colocation or data centre presence.

Regulated replication applies at the MGA. Infrastructure may be located anywhere that meets security and risk criteria, but when it is outside Malta, a Malta-based replication server receiving real-time regulatory data is required. The cost consequence is a Malta colocation node rather than a full primary data centre, but it still requires network connectivity investment, contractual arrangements with a Malta-based facility, and ongoing audit of replication latency.

Pre-approval with residency assessment is AGLC’s model. No fixed Canadian location is mandated, but every data centre must be declared and approved, and cross-border data transfers must pass a formal assessment. This creates a process cost rather than a fixed infrastructure cost, but the assessment cycle affects project timelines and requires architecture documentation to a level of specificity that outcomes-based frameworks do not.

Functional accessibility is the model in Denmark, Ontario, and the United Kingdom. Regulators require access to data on demand, real-time reporting capability, and security controls that meet defined standards. Where the data physically sits is the operator’s choice, subject to applicable privacy law and the general requirement to cooperate with supervisory requests.

Cross-Border Transfer Risk and Encryption Key Residency

Alberta’s SRIG Section 5 brings encryption key residency into the formal compliance scope alongside data storage location. This reflects an emerging regulatory concern: data can be physically stored in a jurisdiction but effectively inaccessible to the regulator if decryption keys are held by a third-party cloud provider in another country. AGLC’s requirement for an encryption key residency review addresses this directly. Operators using cloud key management services from US-based providers must assess whether the key custody arrangement satisfies the AGLC’s requirements.

The MGA’s Technical Infrastructure guidelines address a related risk in their cloud environment annex: information not being erased thoroughly or in a timely manner by cloud service providers following a command from the operator is identified as a distinct risk requiring mitigation. Where game and player data are stored in shared cloud environments, operators must document and test erasure procedures, not only storage location.

For operators running multi-market platforms, the practical intersection of these requirements typically produces a tiered data architecture: a primary production environment accessible globally, supplemented by jurisdiction-specific nodes in Romania (physical safety server) and Malta (real-time replication server), with AGLC-declared data centre arrangements for Alberta. Ontario and UK markets can be served from the same primary environment provided FIPPA obligations and ISO 27001-aligned controls are in place.

Key Resources

AGLC Standards and Requirements for Internet Gaming (SRIG), Section 5, issued February 5, 2026, Board Chair authority. Available via aglc.ca.

AGCO Registrar’s Standards for Internet Gaming, Standards 5.26, 5.28, last updated May 2026. Available via agco.ca.

MGA Technical Infrastructure Hosting Gaming and Control Systems, Remote Gaming, December 2015, v1 (MGA-G-001). Available via mga.org.mt.

MGA Compliance Audit Manual (MGA/G/001), August 2018, v1, Section 4.8. Available via mga.org.mt.

OUG 77/2009 (Romanian Remote Gambling Emergency Ordinance, as amended through 2023) and implementing NORMĂ 24/02/2016. Available via onj.gov.ro.

Spillemyndigheden Tekniske krav for onlinekasino og væddemål, v2.5, Sections 3.1, 3.2. Available via spillemyndigheden.dk.

UKGC Remote Gambling and Software Technical Standards (RTS), published February 2021, last updated October 2025. Available via gamblingcommission.gov.uk. For related Ontario compliance context, see the Ontario iGaming Year Three review on this site.