Monitor gambling licence changes with an evidence log

A monitoring log should let another researcher answer a small question: what changed, in which official record, compared with which earlier observation? Create a stable record for one legal entity, jurisdiction, exact hostname and product. Add the authority identifier where it exists. A brand name alone is too broad to be the comparison key.

This workflow begins after the initial permission check. Use the existing licence-verification guide to establish that baseline, then use the log to track later observations. The fields and triage categories below are Atlas research choices; they are not a new regulatory reporting requirement.

For each capture, record the official URL, document title, page or row locator and the time you retrieved it, including timezone. Store a source publication or dataset date in a different field. If the authority does not publish that date, leave it unknown. Today's download does not make an old decision a new decision.

Keep the earlier capture when the next one arrives. A file hash can help establish whether your saved bytes changed, but it does not explain the legal effect of the difference. For a webpage, a menu or layout change can alter the bytes while the relevant licence fields remain identical. Record the field comparison as well as the file reference.

The UK Gambling Commission separates business, licence, trading-name and domain data, and provides individual CSV datasets as well as combined downloads. Its register defines account number as the business identifier and keeps activity dates and domain status separate. Those distinctions make a field-based comparison more useful than a search for a familiar brand.

The Commission also says businesses provide domain and trading-name information. Treat a change in one of those fields as a change in the recorded data; check the surrounding entity, activity and status evidence before making a wider permission claim. This describes the Great Britain register, not the schema of every authority.

Write the previous and current values exactly in your working log, then explain the question they raise. An altered hostname might concern a new domain, a correction or a different entity. A missing row might reflect a filter, changed coverage, an archive or a terminated permission. The first observation cannot choose among those explanations.

Assign one person or team to the unresolved question and name the next evidence required. If a decision is needed, record its identifier. If the register is inaccessible, preserve the last successful capture and the failed attempt separately. Mark the task as blocked on that source rather than marking the permission rechecked.

For a fictional example, assume a sample authority record retains the same company identifier and activity, but one hostname changes from Active to Inactive. The supported first note is that the hostname status differs between the two captures. Whether the whole licence ended remains a separate question. This example contains no real operator finding.

Publication, enactment and commencement can be different events. Australia's 2026 gambling-reform Act specifies 1 January 2027 for all schedules except Schedule 5; that schedule has a separate commencement. A monitor that notices only the Act's publication would miss this timing distinction.

New Zealand's online-casino provider guidance gives another type of trigger: from 1 December 2026 existing providers that have not applied for a licence must stop operating. Existing providers with applications under consideration may continue without advertising until a decision; this transition does not let a new applicant start operating. The application condition matters alongside the date. An event row should state the source, affected group, condition and next check, rather than a bare date labelled market open.

Report completed reviews, material changes, unresolved conflicts and blocked checks separately. A research team can finish useful work and still have an unresolved source gap. Combining these categories into one checked total hides the work that remains.

Select a review interval from the sensitivity of the record, known event dates, publication frequency and the decisions that depend on it. A weekly or monthly cadence can be a planning choice, but it is not a claim that every source changed within that interval. Reopen the relevant record sooner when a formal decision, correction or defined event arrives.

Denmark's ACR Teknik case illustrates why a publisher might keep destination checks in its workflow. The authority recorded an accepted DKK 20,000 fine after an article linked to an operator without the required Danish licence. That case does not prove a particular monitoring interval or say that every outbound link has the same result.

The CSV has fields for record scope, earlier and current captures, changed field, values, source locator, impact, owner and next action. Its first row is empty apart from NOT_ASSESSED. Complete one change record for each issue that needs review; keep identifiers stable when you later update its status.

If several teams use the log, agree who owns the current evidence record and where historical captures are retained. A notification can wake a reviewer, but only the completed evidence check can support the new conclusion. Keep the proposed content or commercial action separate until its own review is complete.

The iGaming Atlas Research Desk maintains this method. The five official sources were read on 2 November 2026 for the specific register-field, date and enforcement examples above. Recheck this method by 2 December 2026, or sooner if an example's authority changes its source or field definitions.

This page supplies a research process and a blank log. It does not operate a monitoring service, subscribe the reader to alerts, review a named operator cohort or approve a launch. A completed log still needs a conclusion matched to the exact evidence it contains.