Crypto casino fairness audits: reading the scope of a testing certificate

Short answer

Read a certificate as a bounded technical claim

A fairness badge is not a universal warranty. Its evidential value depends on who performed the work, who commissioned it, what exact software was examined, which requirements were applied, when the work occurred and which limitations the report records.

Begin with the original certificate or test report, not a cropped logo. Extract the laboratory name, report reference, client, product, version, digital signature or hash, test dates, jurisdiction or standard, scope, conclusion and stated limitations.

Then compare those identifiers with the live game help and operator record. A matching title alone is weak because several RTP profiles, platform integrations and builds can share artwork.

This page explains how to interpret evidence. It does not repeat RNG mathematics or long-run RTP examples, which already have separate owner pages on this site.

Document type

Certificate, report, seal and marketing badge are not interchangeable

A certificate usually summarises a conformity conclusion. A detailed report can identify test methods, samples, versions, limitations and results. A regulator register entry records a submission or authorisation under that regulator's process.

A dynamic seal may link to a laboratory-controlled record. A static image can be copied and has no independent evidential value. A casino footer saying “RNG certified” is merely a claim until the supporting record is matched.

Record the document title and reference exactly. “Randomness certificate”, “game evaluation”, “RTP verification”, “platform certification” and “security audit” indicate different objects and should not be collapsed into the word audit.

If only a promotional badge is available, the correct finding is that the underlying scope is not publicly verified—not that no testing exists and not that every product is certified.

Testing identity

Verify the laboratory through an authoritative route

The UK Gambling Commission publishes a current list of approved test houses for work required by its remote testing strategy. That list identifies named legal or trading entities and the categories for which they are approved.

Compare the exact laboratory entity, not only a familiar brand. Large testing groups operate through multiple companies and locations, while an approval may cover some categories but not others.

Accreditation and regulator approval also have scope and dates. A genuine laboratory can issue reports for different jurisdictions, so its existence does not prove that one certificate applies to the market claimed by a casino.

Navigate independently to the regulator or laboratory website. A link embedded in a questionable casino page can lead to a replica certificate or unrelated report.

Certificate holder

Match the tested client to the supplier and operator relationship

A report should name the organisation that submitted the product. This may be a game studio, remote gaming server supplier, platform company or operator.

Do not assume group companies are interchangeable. Compare legal names, addresses or registration identifiers and note whether the casino brand is merely a customer of the tested supplier.

A supplier report can legitimately support a game used by many operators, but the evidence chain must connect the tested build and integration to the live deployment. A logo in a lobby does not complete that chain.

If the report names an operator unrelated to the site making the claim, ask for the relationship and deployment identifier. Do not silently transfer certification between brands.

Object under test

Identify whether the report covers an RNG, game, platform or system

An RNG report can examine source code, statistical output, scaling and intended uses. A game report can cover mathematics, artwork, rules, theoretical RTP and the implemented software.

A platform report may address account, wallet, logging or integration controls. A security audit can examine critical systems and information-security requirements. These scopes overlap in places but are not substitutes.

Copy the exact product name, component name and supported use. An RNG suitable for one class of drawing may have limitations involving replacement, degrees of freedom, operating-system functions or mapping.

The report conclusion should be quoted with its object. “The named RNG passed the listed tests” is narrower and more accurate than “the casino is fair”.

Configuration identity

Version numbers and software signatures stop title-only matching

The UK testing procedure says RNG reports should identify the RNG version, whether it is hardware or software, a digital signature, platform supplier and platform version. Those fields bind the conclusion to a particular implementation.

GLI's submission requirements similarly state that an RNG conclusion applies to the RNG identified through software verification. If that identification changes, the earlier conclusion does not automatically remain applicable.

For a game, capture the version or game ID from live help where exposed, along with RTP, currency, channel and operator domain. Compare it with the report's game identifier and supported configuration.

If no version is visible to the reader, say that deployment matching is unresolved. Do not claim the attractive certificate simply because the title and thumbnail match.

Time boundary

A dated test may not cover a later material change

Record issue date, testing period and any expiry or validity condition. Dates show which software state and regulatory requirements were considered.

A cosmetic change may not affect fairness, while a change to RNG, mapping, game mathematics, remote gaming server or integration can require assessment or retesting. The relevant change-control policy decides the threshold.

The UK strategy requires testing before release and addresses changes to platforms, RNGs and channels. It also expects representative integration testing where an updated RGS or RNG could affect many games.

An old certificate is not automatically invalid, but it needs a documented bridge to the current build. Look for change references, supplementary reports or a current regulator register entry.

Central question

Read every included and excluded component

The scope should state standards, requirements, product parts, environments, test techniques and supported uses. Limitations can be as important as the pass conclusion.

UK guidance says licensee and test house agree a scope sufficient to assess relevant technical standards. It lists source-code review, statistical testing, game design verification, simulation, emulation and manual testing as different activities.

Do not convert a sample into whole-catalogue coverage. If a platform change is assessed through representative games, identify the sampled generations and game types and the basis for applying results more widely.

Check exclusions: jackpots, bonus modules, live dealer components, mobile channels, third-party wallets or operator procedures may sit outside the report.

Randomness evidence

RNG testing examines implementation and output, not every business practice

The UK testing procedure describes review of RNG documentation, research into known weaknesses, source-code comparison, statistical testing of raw output and analysis of scaled or shuffled data.

A report should identify how the RNG is used and any limitations. Passing statistical tests alone does not prove that a separate game maps raw values correctly or displays the result according to its rules.

Likewise, an RNG certificate does not establish the theoretical RTP of every game connected to it. Paytable mathematics and mapping can differ even when games share a random source.

For the mathematical meaning of independent outcomes, use the site's independent RNG outcomes guide. This page stays focused on documentary scope.

Game and return evidence

Game testing joins design mathematics to implemented behaviour

UK guidance describes verification of game design, artwork, rules and theoretical RTP, followed by software testing in an environment reflecting intended live operation.

Simulation can compare actual output with expected RTP over a suitable sample; emulation can reach rare features and maximum prizes; manual play can confirm visible rules and ordinary behaviour. Each method answers a different part of the question.

A theoretical RTP finding applies to the tested configuration. If several selectable profiles exist, the report or live help must identify which profile is deployed.

The site's theoretical RTP guide explains long-run expectation. A certificate does not promise that a single session will return the published percentage.

Deployment bridge

Integration can change the evidence needed

A tested game can be delivered through a remote gaming server, platform and operator client. Where the live environment differs in a way that can affect fairness, integration testing becomes relevant.

The UK strategy specifically mentions use with a different RNG or platform and expects testing where differences can affect operation. New client channels may require interface testing even when the backend mathematics is unchanged.

Record platform supplier, version, channel and digital signature where available. A desktop certificate should not automatically be described as mobile coverage unless the report includes that channel or a documented port assessment.

Operator configuration matters too. Active RTP, stake controls and enabled features should be compared with the tested profile rather than assumed from supplier marketing.

Regulatory boundary

A test report is not an operator licence

A test house evaluates defined technical requirements. A regulator authorises named entities and activities under a jurisdiction. One process can require the other, but the documents are not equivalent.

The UK games register allows licence holders to submit game and RNG reports and maintain current game records. The obligation belongs to in-scope licence holders; it does not turn the laboratory into the operator's regulator.

Check the casino's contracting company, exact domain, licence activity and status separately. A supplier's approved report cannot establish that an unrelated site may accept New Zealand players.

Use the licence evidence guide for entity, domain, B2B/B2C and seal verification.

Another audit class

Information-security assurance does not replace game testing

A security audit can cover critical systems holding customer information, account balances, gambling history and networks, including systems that generate or process random numbers.

Its conclusion concerns security requirements and controls within the stated audit boundary. It does not by itself certify a game's paytable, theoretical RTP or outcome mapping.

Conversely, a game certificate does not prove account security, custody segregation, withdrawal performance or resistance to every cyberattack.

When a casino advertises an ISO or security assessment beside RNG claims, separate the two records and state what each actually examined.

Separate verification method

Provably fair is not another name for a lab certificate

Stake's current overview describes provably fair as a commitment scheme combining operator and player inputs with cryptographic hashing so a player can reproduce defined results.

That method can let a user verify a specific outcome under published conversions. It does not automatically assess source-code security, every game rule, platform integration or operator conduct.

Laboratory testing, by contrast, evaluates a specified implementation against declared criteria using methods such as code review, statistical analysis, simulation and manual checks. Either method can have a narrow scope.

Use the site's provably fair verification guide for seed commitments, nonce and conversion checks. Do not use a provably fair label to fill a missing test report.

Source quality

Prefer a complete original record over a cropped certificate

Open the laboratory, regulator or supplier-controlled record. Check the URL, report reference and whether the file is complete. A screenshot can omit annexes, limitations and the signature page.

Compare hashes or digital signatures where a verification method is published. Do not upload confidential software or reports to an unknown “certificate checker”.

If the detailed report is confidential, request at least a regulator register reference, certificate summary and exact product identifiers. Note what remains inaccessible.

Save the source URL and check date. A reproducible path supports later correction if the record is withdrawn, superseded or replaced.

Language discipline

Reject blanket “fully audited” and “all games verified” wording

A single RNG report cannot establish every game's RTP or rules. One game certificate cannot cover unrelated titles. A platform assessment cannot prove all operators use the same build.

Testing also does not prove reliable withdrawals, fair bonus disputes, solvency, lawful New Zealand access or absence of future defects. Those require other evidence.

Use bounded wording: “the named report identifies version X and tests requirements Y under jurisdiction Z as of date D”. Then list unresolved deployment fields.

Do not create an editorial certification badge unless this site maintains a current, reproducible verification process. A source link and limitation statement are more honest.

Worked review

How to assess an “independently RNG certified” footer claim

First open the linked document without trusting the badge image. Record the laboratory, reference, client and issue date. Verify the lab through the regulator's approved list for the claimed jurisdiction.

Next identify whether the object is the RNG, a game, the platform or a security system. Copy version, signature, supported use and every limitation.

Open the live game's information panel and compare provider, title, version, RTP and channel. If those fields cannot be matched, report that the certificate is genuine-looking but deployment applicability is unresolved.

Finally keep licensing, provably fair verification, custody and operator conduct in their own evidence columns. Do not let one positive technical record overwrite gaps elsewhere.

Practical audit

Casino game-test certificate checklist

1. Obtain the original certificate or report reference.
2. Verify the laboratory through an authoritative list.
3. Match the exact laboratory legal entity and approved category.
4. Record the submitting client and its role.
5. Identify RNG, game, platform or security object.
6. Copy product name, version and software signature.
7. Record test dates, issue date and jurisdictional criteria.
8. Read scope, methods, exclusions and limitations.
9. Separate raw RNG tests from mapping and game tests.
10. Match theoretical RTP to the tested profile.
11. Check live platform, channel and integration identifiers.
12. Look for change-control or supplementary reports.
13. Keep operator licensing as a separate check.
14. Keep provably fair verification as a separate method.
15. Reject whole-catalogue and whole-operator claims without scope.
16. Label inaccessible or unmatched fields unresolved.

Evidence limits

A public reader may not have access to the full technical file

Some test reports are submitted privately to regulators or held by suppliers. A public certificate can still be useful, but missing annexes limit what can be concluded about methods and exceptions.

This guide uses Great Britain testing guidance as a concrete example of report composition. It does not imply that UK requirements govern a New Zealand user's chosen operator.

Regulator lists, versions and approvals change. Every claim needs a check date and should be revisited after material software or platform updates.

The result can legitimately be “scope not independently verified”. That is more precise than either declaring the casino fraudulent or repeating an unbounded fairness claim.