RNG & mathematics evaluation
Statistical examination of the random source, verification of the declared return-to-player model, and review of the paytable implementation against the submitted mathematics.
GeminiCheck examines gaming and high-transaction software against the requirements of the markets our clients operate in — random number generation, payout mathematics, platform integrity, security and change control — and documents exactly what was tested, how, and what the result was.
We hold no commercial stake in the products we assess, and our findings are not conditional on the outcome a client would prefer.
Every report states the version tested, the method applied, the data collected and the deviations found — so a third party can follow the reasoning.
Each certificate carries a unique reference and verification token that anyone can check against our register at any time.
Engagements are scoped to the component under review and to the rules of the market the system is intended for. Below are the areas we work in most often.
Statistical examination of the random source, verification of the declared return-to-player model, and review of the paytable implementation against the submitted mathematics.
Wallet and session handling, bonus and jackpot logic, game-state recovery after interruption, and the behaviour of the platform at the boundaries between integrated components.
Odds ingestion and publication, bet acceptance rules, settlement and void handling, cash-out calculation, and the audit trail that links a placed bet to its final settlement.
Authenticated and unauthenticated testing of the application and its exposed infrastructure, credential and session handling, and the controls protecting administrative functions.
Ledger consistency, reconciliation between the platform and payment providers, handling of partial and failed transactions, and the completeness of the financial audit trail.
Confirmation that what is running in production matches what was certified: build identification, version control evidence, and assessment of the impact of each submitted change.
Review of live dealer operations: stream and game-state synchronisation, dealer procedures, incident handling, and the records kept for each round.
A structured gap review before a formal submission, so that defects are found and closed by the supplier rather than discovered during a regulator's review.
The same five stages apply to every engagement, whatever its size. Nothing is certified that was not tested, and nothing is tested that was not defined in the scope agreed at the start.
We agree in writing which components, versions and market requirements are in scope — and which are explicitly not.
The client provides builds, mathematics, architecture documents and access. Each artefact is recorded with a hash and a version.
Testing is carried out against the agreed scope. Observations are logged as they are made, with the evidence that supports them.
Deviations are reported with severity and reproduction steps. The client may remediate and resubmit; retests are recorded separately.
If the scope is met, a certificate is issued with a unique reference and verification token, and the record is added to our public register.
The exact build, version and configuration examined, with the hashes of the artefacts received.
The procedures applied, the tools and sample sizes used, and the environment the tests were run in.
Findings by severity, including items that passed, items that deviated, and anything that could not be tested and why.
What the certificate does not cover, and the conditions under which it ceases to apply — a changed build is a new assessment.
Every certificate we issue is listed in our public register. Search by certificate number or by the domain it covers to see the holder, the status and the dates it applies to.
Search by certificate number or domain. Results are read directly from the issuing record — nothing is generated for a document we did not issue.
Current accreditations held by the laboratory, with their registration details.
A supplier, an operator and a regulator each need something different from the same examination. Our reporting is structured so that each gets the part that concerns them.
Evidence that a product behaves as specified before it is submitted to a market, and a clear list of what must change if it does not.
Independent confirmation of what is actually running on the platform — including integrated third-party components the operator did not build.
Reports written to be read by someone who was not present during testing, and a register that lets any certificate be checked independently.
Tell us what the system is, which market it is intended for, and when you need the work completed. We will come back with a scope, a timeline and a fee.
Sign in with the credentials issued to your organisation.
Username or password is incorrect.
The portal is being prepared.