iGaming supplier due diligence: an evidence checklist

Use this checklist when a commercial, compliance or technology team needs to examine a particular supplier arrangement. Its purpose is to collect independently checkable evidence, explain what that evidence establishes and keep unresolved questions visible.

Create a working copy for the proposed arrangement before asking for documents. Name the contracting entity, product and version, destination jurisdiction and activity. If another product, entity or distribution route changes the question, use a separate record or describe the changed scope explicitly.

The fifteen checks are an Atlas research method, not a universal list of legal obligations. Add a jurisdiction-specific requirement only when the applicable source supports it. The CSV contains suggested questions and evidence prompts, not completed findings.

Complete DD01 to DD03 before treating a supplier presentation as an answer. A trading name, parent company and contracting entity may refer to different organisations. State the relationship rather than replacing all three with one familiar brand.

Describe what each party does. Development, software supply, hosting, distribution and contracting with players can involve different evidence. Record who controls the relevant system and who has the player relationship.

Complete DD04 to DD12 using documents that can be matched to the scope defined above. Keep the source type visible. A presentation may help locate a licence or report; the underlying record is what another reviewer needs to inspect.

Store the relevant passage or page locator in the notes field alongside the source URL. If evidence is private, record its location and handling restrictions in the working copy. The public template contains no supplier records, personal information or private documents.

Complete DD13 to DD15 after identifying what is supported and what remains open. Every clarification needs a precise question, an accountable reviewer and a next action. Use the response and notes fields to describe those details; do not replace them with a confidence score.

Use the status field consistently. Suggested states are NOT_ASSESSED, EVIDENCE_COLLECTED, VERIFIED_FOR_STATED_SCOPE, CLARIFICATION_REQUIRED and NOT_APPLICABLE_WITH_REASON. A collected document has not necessarily been verified. A blank field establishes neither approval nor failure.

A verification date belongs to a completed check of the stated scope. Opening a page or planning a later review does not complete that check. For the next review, use a relevant date or trigger, such as a documented expiry, material product change or planned launch step.

The authority guidance illustrates why the questions stay separate. The Gambling Commission distinguishes software from host activities, with conditions concerning the host's software licence and player relationship. The Malta Gaming Authority describes critical gaming supply and prior approval of gaming verticals. Alderney's categories assign different operational responsibilities and separate licensing from preparation for commercial operations.

These local examples help identify what evidence to request. They do not establish whether a particular entity, product version or destination is covered. The companion guide explains the differences in more detail.

A technical assessment should identify what was assessed and its limits. Record the product version, system or process and relevant jurisdiction. Avoid assuming that a testing logo or report title covers future versions, every distribution route or all destination markets.

DD10 records a documented action; it does not turn the action into a global reputation score. Match the entity, authority, jurisdiction and act. Keep announcement, decision, effective date and procedural status separate where the source distinguishes them.

Atlas Watch dossiers can help locate the underlying materials. The SPRIBE and Booming Games dossiers are starting points for that research exercise. Before making a conclusion about either case, open the underlying act and check whether subsequent material changes the scope or status.

An incomplete supplier response is a reason for clarification. It is not, by itself, evidence of unlawful activity. Commercial preference also belongs outside the evidence conclusion.

Version 1 contains fifteen checks, DD01 to DD15. The response, primary source URL, reviewer, verification date and next review or trigger fields are empty. Every check starts at NOT_ASSESSED. Keep a separate working copy for each arrangement.

The CSV contains suggested questions, evidence prompts and a scope note. It contains no approved suppliers, completed legal assessments, scores or automatic decisions. Add requirements and supporting documents that apply to your scope, and preserve any restrictions on private evidence.

When the record is ready for review, make its conclusion as narrow as the business question. Explain which parts are supported, which need clarification and what would change the conclusion. Use the existing research enquiry below if a defined source review is needed.

The checklist and its questions are editorial recommendations. The three authority guidance pages were checked on 7 October 2026 for the limited concepts described here. This article does not review every law, technical standard, fee, supplier or market-entry condition in those jurisdictions.

The Research Desk maintains this method on a thirty-day review target, with earlier review if a cited authority changes relevant guidance or the template changes. Keep the template version separate from the dates of the evidence collected in your working copy.